8/29/2010A couple of months ago Randy Drisgill asked me if there was a way to use the mighty PowerShell to set a web's master page in SharePoint 2010. Not being a branding guy I hadn't tried it before. Heck, I'm not even sure what a master page is, but for Randy I dug into it.
The master page setting is scoped at the web level, so the first thing I did was use Get-SPWeb to get a variable for the web I want to change. There are two properties that control the master page settings; MasterUrl and CustomMasterUrl. The former controls the master page used to render the System pages (the ones that start with /_layouts) and the latter controls the master page used to render the content pages. This picture helps explain it better:
To alter those settings for a publishing site at http://sharepoint, use the following PowerShell script:
$web = Get-SPWeb http://sharepoint
$web.CustomMasterUrl = "/_catalogs/masterpage/nightandday.master"
$web.MasterUrl = "/_catalogs/masterpage/nightandday.master"
$web.Update()
This changes the master page for both settings and content to nightandday.master. Since we're doing this with PowerShell it's easy to loop through a group of webs and set their master pages to whatever you like. I haven't found a way in PowerShell to set the "inherent system master page from parent" property for a web. If anyone knows how to do that, drop me a line.
Hope this helps,
tk 8/26/2010
Before they get away from me I want to start listing the builds of SharePoint 2010. Hopefully I'll keep it up to date. J
To see which build your farm is, go to Central Administration > System Settings > Manage servers in your farm (/_admin/FarmServers.aspx)
Or using Windows PowerShell: (get-spfarm).buildversion
To see which build your products are, go to Central Administration > Upgrade and Migration > Check Product and patch installation status. (/_admin/PatchStatus.aspx)
To see which build your databases are, go to Central Administration > Upgrade and Migration > Review database status (/_admin/DatabaseStatus.aspx)
|
Build |
Release |
Component |
Download Link |
|
14.0.4763.1000 |
RTM |
All components |
Download |
|
14.0.4762.1000 |
RTM |
Farm Build Version |
|
| |
|
|
|
|
14.0.5114.5003 |
June 2010 CU |
Microsoft SharePoint Foundation 2010 Core |
KB2028568 |
|
14.0.5114.5003 |
June 2010 CU |
Microsoft Shared Components |
KB2281364 |
|
14.0.5114.5003 |
June 2010 CU |
Microsoft SharePoint Portal |
KB983497 |
|
14.0.5114.5003 |
June 2010 CU |
Microsoft User Profiles |
|
14.0.5114.5003 |
June 2010 CU |
Microsoft Search Server 2010 Core |
|
14.0.5114.5003 |
June 2010 CU |
Microsoft Web Analytics Web Front End Components |
KB2204024 |
| |
|
|
|
|
14.0.5123.5000 |
August 2010 CU |
Microsoft SharePoint Foundation 2010 Core |
KB2266423 |
|
14.0.5123.5000 |
August 2010 CU |
Microsoft Search Server 2010 Core |
KB2276339 |
|
14.0.5123.5000 |
August 2010 CU |
Microsoft User Profiles |
|
|
14.0.5123.5000 |
August 2010 CU |
Microsoft SharePoint Portal |
|
tk 8/24/2010In the continuing saga of the User Profile Service (UPS) kicking my butt, I have a heartwarming tale of one victory I can claim. It involves Event ID 6801 "Invalid URI: A port was expected because of there is a colon (':') present but the port could not be parsed." and me besting the User Profile Service. Don't believe me? Well, here's my tale…
It was the best of times; it was the worst of times. I was getting a handle on the UPS, but it threw another error at me. A customer contacted us. The UPS refused to sync on their farm. It had never worked. I looked in the Application log and saw a string of Event ID 6801s and 6803s. The 6801s included the text "Invalid URI: A port was expected because of there is a colon (':') present but the port could not be parsed." The 6803s were just saying that portion of the sync failed. A normal profile sync has 10 steps. Some pull from AD, some from SharePoint, some push, and so on. The initial AD import step, DS_DELTAIMPORT was working. The rest were failing.
Unlike a lot of error messages, this one was helpful. I wasn't sure where this broken URI was, or why it didn't have a port, but it was something. After going through the Windows logs and the trace logs, my next step was the fire up the miisclient.exe in the C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell directory. This let me watch each step as it happened. I could see the failures going through. After doing some research on the error, and comparing a working system to the broken system, I figured out the difference. Central Admin on the working system was on a nonstandard port, 1026. On the broken system, Central Admin was using https on the common port, 443.
Armed with this information I went back to miisclient.exe. I clicked "Management Agents" in the toolbar and opened the properties for the SharePoint agent. It's the one of type "Extensible Connectivity." This is how Forefront Identity Manager (FIM, the software behind the User Profile Sync) connects to SharePoint.
Once in the properties I clicked "Configure Connection Information" on the left to get the connection information. On the bottom, in the "Connect To:" box was the key.
This screenshot is from the working system. Notice my connection string has a colon and a port number. I looked at the broken system and it did not have a colon or a port, since it was running on the standard https port. The fix was to change direct://centraladmin/_vti… to https://centraladmin:443/_vti... After I did that, I started a full profile sync. All 10 steps completed successfully.
The moral of this story is that the UPS will not work if your Central Admin default zone URL does not have a colon and a port number in it. The fix is to specify the color and port in the connection setting in miisclient.exe.
tk 8/20/2010Anyone that I've talked to about SharePoint 2010 knows I like MySites. I think everyone should have a MySite. My cat has two. Unfortunately not everyone agrees with me. About once a week I get asked, "How do I disable MySites? I'm a big meanie." I figured it was time to put this into a blog post, so I don't have to fight back tears every time I have to explain how to do this. I'm tearing up now as I type this.
First, go into Central Administration and click Manage service applications
Then click your User Profile Service Application and click Manage
In the management screen, click Manage User Permissions
You'll get a window that looks like this:
By default all authenticated users have permission to "Create Personal Site." To keep people from creating them, remove that permission for both authenticated users entries. Users will no longer be able to create MySites. At this point you can add users or domain groups to the top of the screen and give that group permission to create personal sites. The recommendation I usually give it to create an AD group for people that can have personal sites. Then as you decide to give users permission to create personal sites, you drop them into that group.
This can be done in PowerShell, too (I think). I'll figure it out and blog it later.
tk 8/17/2010This question came up a couple of times today, so I thought I'd address it in a blog post. The question goes something like this; "Why does SharePoint put %*&@ing GUIDs at the end of its databases? Argh!!!" This is a very good question, and has a very good answer.
Before we go any further, let me be clear. I'm not defending the practice, I'm just explaining it. J
What causes it?
So, why does SharePoint do this? Well, it's important to keep in mind that the only databases that have GUIDs at the end of them, are ones that SharePoint has to name itself. If you, as the admin, get to name a database, it won't have a GUID, unless you choose to put one there yourself. SharePoint puts GUIDs on those databases for two reasons:
- A SQL instance can contain databases from multiple SharePoint farms.
- To SharePoint, creating a database and mounting an existing database are the same thing (in most cases).
The combination of those two facts is why SharePoint throws GUIDs at the end. It doesn't know if that SQL instance already has database named "User Profile Service Application_SyncDB" from another SharePoint farm. Or, maybe that database is there and it was created manually by your DBA with specific settings. To prevent itself from mounting some other User Profile Service Application_SyncDB by accident (since mounting and creating are the same) it throws a GUID at the end to guarantee the database name is unique. Here is what it looks like in SharePoint Server 2010.
The databases in the red circles have GUIDs at the end, and were created by the Configuration Wizard (PSConfig or The Gray Wizard) and the Farm Configuration Wizard (The White Wizard) in Central Administration. Not only do they have GUIDs at the end, but to add insult to injury, some of the GUIDs have dashes (blue circles) and some do not (green circles). This is significant because in TSQL, the dash character (-) is a comment character. If you or your DBA has any scripts to work on your databases (like back them up), it's quite possible that they do not escape that dash, and the script will fail since there is no database named "SharePoint_AdminContent_978a91dc." That particular issue really cheeses off DBAs. That's okay, they normally deserve it, the big meanies.
How can we prevent it?
This is the part of the blog post that makes it all worthwhile. How can we fix or prevent these cursed GUID-riddled databases? There are a variety of techniques, but basically it all comes down to this; don't use Wizards, create the databases yourself. What does this mean? For one, it means don't let the Configuration Wizard (The Gray Wizard) create your farm. Instead use New-SPConfigurationDatabase to build your farm. That allows you to specify a name for the Admin Content database. If you miss that step, you can use the tip I outline in my blog post Get the GUID out of SharePoint databases to fix it after the fact. After your farm is provisioned, don't use the Farm Configuration Wizard (still The White Wizard) to build it. Instead create all of your Service Applications with Windows PowerShell or in Central Administration. That gives you control over their database names. If your farm is already created, you may have to delete the associated Service Applications and rebuild them correctly. Some might let you rename the database, though I haven't tried that personally. With Search you can create new Crawler and Property Store components and delete the ones with the GUID infested database. You'll need to run a full crawl afterwards.
The moral of the story though, is those GUIDs are there because we let SharePoint do all the hard work. If we do the hard work instead, we can prevent those ugly GUIDs from sullying up our SQL instance.
tk In tonight's netcast why you should go to SharePoint Saturday events, yet another way the User Profile Service will fail, a fix for Office Web Applications that won't cooperate, and my feelings on Remote Blob Store (RBS).
MP3 File (Subscribe)
WMV File (Subscribe)
Duration 44:09
8/15/2010
This episode I talk up the recent SharePoint 2010 patch and all the fun I had with an in-place upgrade. In this week's PowerShell tip of the week I show how to use PowerShell to add users to a SharePoint group. I also kick out the entire chat room for giggles.
MP3 File (Subscribe)
WMV File (Subscribe)
Duration 37:17
8/3/2010One of my coworkers, John Ross, recently asked me if it was possible to create a new Site Collection in SharePoint 2010 and use a custom site template for it. I'm usually more of a server and infrastructure guy, but this made me curious. In SharePoint 2007 site (really web) templates were saved as .STP files. Those STP files could be in the site collection gallery, or the farm gallery. If it was in the farm gallery then it was available at site collection creation. In SharePoint 2010 site (really web) templates are stored as user solutions in the site collection solution store as WSP files. Those WSP files don't upload at the farm level (at least not that I've been able to find). So how does one create a new site collection with a custom template? Stick around, we're going to find out. J
The first thing to keep in mind is that site collections don't have templates, webs do. When a new site collection is created there is a template picker. That doesn't apply a template to the site collection itself, but to the rootweb of that site collection. When the site collection is created, the rootweb is also created. That is where the template is applied. Knowing that, we can figure out a solution. We know that the site collection gets created, with or without a template. If the site collection is created, then so is its solution gallery. If we upload our WSP to that solution gallery, then it's available to us when we create the rootweb. That's how we create a site collection with a custom template. Here's the blow-by-blow on how to do it.
First we'll save out our site (really web) template. Start by going to the site you want to save as a template. Then go to Site Actions > Site Settings. It will look like this:
When you click "Save site as template" you see this screen (though it won't be filled out, you have to do that)
If things go well, you'll get this screen. Click the link to go to the Solution Gallery.
That should take you to this page:
Click the name of the template you created. You'll be greated with this dialog to save it to your local file system:
Now go into Central Administration and create the Site Collection (Application Management > Create site collections) you want to apply this template to. On the creation page go to the custom template page like below:
The secret sauce is not selecting a template for the rootweb. When the site collection is created, you'll be given a link to it. When you click it you'll be taken to the template picker page, if you hit it as one of the site collection administrators. At the bottom is a link to your newly created site collection's solution gallery.
Upload the template solution here:
Don't forget to activate it.
When you're back to the solution gallery use the breadcrumb to get back to the rootweb of the Site Collection:
That will take you back to the template picker page. Now on the Custom tab we have our template.
That's all there is to it.
tk |
|
|
|
|
|
My latest book has been released. I present... Inside SharePoint Administration. Shane Young, Steve Caravajal and I packed every trick and tip we know into this little number. You can order it from Amazon, or wherever you buy books.
Enjoy,
tk
|
|
|
|
|
1
- 10  |
|
|
|