Today when we tired to deploy a feature to a SharePoint Farm that had been around for some years, we ran into the very famous "Object reference not set to an instance of an object error". We tried both "STSADM" as well as PowerShell and the result was still the same. This error occurred only when we tried to "Activate" the solution and not when we tried to "Add the solution" to SharePoint. Since it was an old farm, our intial guess was that the error could be due to "Access Permissions". Hence we checked the Event Viewer and stumbled upon the details of the error:
To solve the error, we provided the required privileges for the Account (logged into the server and used to deploy the feature), to "SharePoint_Config" database. When we tried to do it again, it worked perfectly fine and was able to activate the feature as well. It would have really saved us time, if Microsoft would have given a better error message than the infamous "object reference error.."
1,829 total views, no views today
For those migrating from SharePoint 2010, we would at times be wondering as to where the dll's (custom .net code) embedded in features are placed in the server, when deployed through visual studio or powershell. Typically they either would be in the GAC or in the local bin directory of the website. However, SharePoint 2013 servers (typically deployed over 64-bit platform), have now taken advantage of the .net 4.0 framework features, which in plain terms means that the dll's would be placed under C:\Windows\Microsoft.NET\assembly\GAC_MSIL folder.
976 total views, no views today
Recently I got into a situation where I had to restart one of the servers from my local machine (to which I had connected through VPN). To do to that:
1. Open a command prompt and type the below command:
shutdown /[r|s] /m \\ComputerName /c "Comment" /d [u|p] <xx>:<yy> and then press ENTER.
For E.g., shutdown /r /m \\<server name> /c "Put in your Comments/Reason for restart" /d 10:11
2,192 total views, no views today