Here is an interesting little quirk. I was recently setting up some installation scripts which would roll in a Site Definition, then tried to create a Site Collection from the newly installed Site Definition. And no matter what I tried, PowerShell would not see the newly installed Site Definition.
If I looked at the list of available Site Templates in the UI, the new Site Template was there and I could create it.
Thanks to Steve Clement on this one, as it seems there is some odd kind of caching going on. The Powershell context only sees the SharePoint site template list at the point at which the object is created, which means our new site template does not appear.
Steve has a solution involving a new PowerShell plug-in which effectively recycles the SharePoint context. I’ll have a play with that in a while, but for now, I split the process into two separate scripts, one which installs the solutions and the other which creates the Site Collection.
So, want to install a Site Template via PowerShell and create a Site Collection base don it in one single script? Out of the box, it seems, you can’t.
I’ve mentioned before that I am doing a complex migration from MOSS 2007 to SharePoint 2010 and I came across an absolute doozy of an issue over the last couple of days. I doubt anyone else will come across this, but it worth noting, if not just for my sanity, but also in case it crops up somewhere else.
The source 2007 site was a publishing site with a heavily customised Master Page. The Master Page containing some controls in it for navigation and so on – unfortunately the source code for these controls were written in Visual Studio 2005 and deployed, well, somehow. I rebuilt the controls in VS2010 and a nice WSP for deployment.
There remains the problem of getting it to work in the new environment. The old control would not work, giving the SharePoint Screen of Death. No problem, I don’t need it anyway. I copied the old 2007 Master Page, uploaded it into 2010 and worked on it with SharePoint Designer to run the new control. All is hunky dory.
Until we come to roll out. Plan was to do a migration via Attach Database, then put my new Master Page into the system, flip over to it and all is well.
The migration goes OK, the site pops up with the expected Master Page error, I go into SPD to upload the new custom MP, check it in, requires Approval so open the page in the browser and…
Error. The Approval page still uses the old, failing, MP.
I can change the MP using the GUI but I can’t flip it to the new Master page because it hasn’t been Approved and I can’t Approve it because that relies on a Master Page that fails.
OK, so off to Powershell I go and Approve the page in the back end. Back to the Change Master Page page and my custom MP either does not appear in the dropdown or gives me a warning that it is set for SharePoint v4 (2010) and not the v3 (2007) UI that we are keeping.
The problem is this. If you upload a Master Page to the Master Page Gallery, the UI Version is automatically set to v4 – SharePoint 2010. This is a problem if you are using the v3 GUI – either the new MP will not appear for selection and if it does, it is set to v4. You can’t change this because your Master Page is faulty and you can’t get to the List through the browser. The value is not available in SPD to change.
After a lot of faffing, the solution I found is this.
1. Using Powershell, change the MasterPage Url to default.master (or something other than your current MP, but still v3).
2. Go into the Master Page Gallery and edit the new custom Master Page item you added and set the UI Version to 3 (not both 3 and 4, but 3).
3. Back into Powershell and change the MasterPage Url to your new custom Master Page.
It will all work now.
The key fact to take away is that by default in SharePoint 2010, any Master Page uploaded to the Gallery is set to v4 even if your site is running as v3.