A situation cropped up today where a custom Site Template was created by saving a site as a template which was then used and subsequently deactivated and then deleted. Simple enough except that SharePoint insisted that the template was still there and presented it as a choice when creating new sites even though it didn’t exist and would fail if someone clicked on it.
I could have simply gone into Site Settings – Page Layouts and Site Templates and hidden it there but that raises other problems as well as adds ongoing maintenance as it means all new templates would have to be explicitly added in order to be visible. However, even if I did that Click to read the full post
SharePoint admins occasionally have write PowerShell scripts to regularly extract some type of summary data from the SharePoint farm and then write that out to a file, usually in CSV format since PowerShell handles those so well. This is great for admins because we can just log onto the box and open the file to read the data, but what about the rest of the SharePoint team that also needs that data? Click to read the full post
As a SharePoint administrator, I end up either writing a lot of PowerShell scripts or copying existing scripts and modifying them to fit a new need. With all of these scripts comes the need to share them with other admins outside of the command line and in such a way that allows them to be easily Click to read the full post
One of the more annoying quirks with dealing with SharePoint is that once you develop a solution that requires custom code, all dependencies are then tied to the Strong Name of the compiled DLL. That strong name also includes the version number, usually 184.108.40.206, and cannot be changed without breaking all existing references. This is a good thing from a compatibility perspective but it does make it rather complicated to figure out exactly which version of a DLL is in use.
You can open up the WSP and then use the timestamps and take a guess at the version but it is not always reliable. Click to read the full post
With SharePoint 2010, the usage of the Management Shell is pretty much mandatory. However, most corporations have a policy that says something along the lines of “Do not log in with Service Accounts” with the “or else” being implied. Unfortunately, the 2010 Management Shell usually only works properly when logged in as one of the system accounts (usually the setup or farm/admin account). This means that you are left with either logging into the server as the Service Account or using the shift-right-click trick on the Management Shell link and entering the farm account information there – every time.
If your company is anything like mine, the passwords for those service accounts are often an utterly bizarre and random combination of letters, numbers, symbols and stargate coordinates. This also means that you have to go digging for that password every time that you need to use the management shell because remembering such a twisted concoction is not really an option.
There is another way that I’ve found that is better than both of the above options. Simply create a batch file (really!) and enter the commands below and then save it somewhere where you can remember it – or, better yet, create a shortcut to it on your desktop.
This will start the management shell but will run it as the service account (be sure to replace ‘myDomain\ServiceAccountName’ with your service account info). Best of all, the /savecred option makes it so that you only have to enter the password the very first time you run the batch file which means no more digging around for it. (Note: the credentials are encrypted and tied to your ID on that machine so if someone else logs on and clicks the same batch file, they will be prompted for the password)
Simple and quick, and it still lets me log into the SharePoint server with my normal admin account.
Update 12/4/2012: Corrected a typo and moved the code to Gist on GitHub.
When you work with SharePoint, you end up working a lot with both GUIDs and with PowerShell. Strangely enough, the two together don’t seem to be needed very much but eventually their paths cross. GUIDs in PowerShell are amazingly simple to create but the web is chock full of misinformation and insanely complicated suggestions. I’ve even seen some folks recommend passing parameters to New-Object!
So, just for the sake of clarity, here is how to create GUIDs in PowerShell. It really doesn’t get much simpler than this!
# Create an empty GUID
$Id = [GUID]::Empty
# Create a new GUID
$Id = [GUID]::NewGuid()
# Create a GUID with a value
$Id = [GUID]("b2e92f11-7f65-41d1-acec-ba051b418bdf")
There’s nothing to it but some people choose to make this so complicated.
Update – 5/31/13 – I discovered a way to make it even simpler!