2/4/2010As a SharePoint consultant I get to see a lot of things about SharePoint that bug people. This blog post is dedicated to one of those SharePoint annoyances, a GUID at the end of the Central Admin content database.
If you do a regular, wizard driven configuration of SharePoint Central Admin is created. This is the part after the bits are installed, but before SharePoint is configured. The Configuration Wizard runs and if it's a new farm it sets up the farm. Part of that setup is creating the Central Admin web app, and its content database. Web apps in SharePoint can have many content databases. When you add a content database to SharePoint it checks to see if the database exists. If it does, then SharePoint adds the existing database to your web app. If the database doesn't exist, SharePoint creates it, then adds it to the web app. This is important when the configuration wizard creates the Central Admin web app. If SharePoint used a well-known name for the Central Admin content database, like "Admin_Content" then if that database already existed, the existing one would get mounted. This could happen since a SQL instance can hold the databases for many SharePoint farms. To keep this from happening the configuration wizard throws a random GUID at the end of the database name. For some folks, having a GUID in a database name really cheeses them off. To prevent this, you can script the configuration of your farm with a daunting combination of psconfig.exe and stsadm.exe commands. It's not for the faint of heart. Until recently when a customer took exception to the GUIDed database names I was able to tell give them the explanation you just read, explain to them that no other databases will be GUIDed against their well, and we move on.
Recently a customer voiced that same concern, and we had the same talk. Unfortunately they had some 3rd party software that didn't like the GUID in the database name. All my sweet talking was no good. I was forced to find a solution. It took a couple of minutes, then it occurred to me, Central Admin is just a site collection, so I can handle it like any other site collection. I ended up creating a 2nd content database for Central Admin and giving it a more reasonable name. Then I used STSADM's mergecontentdbs operations to move the Central Admin site collection to the new content database. Then we were free to dismount the GUIDed database in Central Admin and delete it in SQL. That made for a happy customer. Below are the steps I took. There's not a man, woman or child alive that doesn't like screenshots. So I've added lots of them to show what I did.
Here's where we start:
Here's how it looks in Central Admin:
First step was to add a new content database to move the site collection to.
Here's the next step
Now we have two content databases:
Next is a screenshot of the next few things I did on the Command Prompt to move the site collection. The line outlined in red is the actual command that moves the site collection.
I used "stsadm –o mergecontentdbs" with the full move option.
Now I can go into Central Admin and delete the GUIDed database. Central Admin will look like this:
There is one final, satisfying step left:
(And the crowd goes wild!)
Hope that helps clean up some SQL instances.
tk 1/7/2010This blog post is the heartwarming tale of two warring factions putting their differences aside and working together for a common good. That's right, devs and admins, hand in hand, figuring out this beast we both love called SharePoint.
A couple of days ago I got an IM from a buddy of mine, Dan Attis. Like many of us he's been playing with SharePoint 2010 pretty heavily and that day he had poked it pretty hard and it didn't like it very much. It decided not to work anymore. Dan didn't want to rebuild his VM. Heck, he didn't even want to reinstall SharePoint. So his question to me was essentially, "Is there any way for me to reset SharePoint, without reinstalling it?" Now, keep in mind this was a test dev VM he was working on, it wasn't a production environment of any kind. Because of that I figured I had some latitude. The first thing that came to mind was just creating a new ConfigDB. That resets SharePoint. It's a pretty extreme measure though. I almost felt dirty suggesting it. I told Dan to run the SharePoint Config Wizard and remove the server from the farm. Then run the SharePoint Config Wizard again and instead of connecting it to an existing farm, create a new one. The important step is to give the new ConfigDB a different name than the old one. The server will now essentially be reset with a fresh version of SharePoint. Dan walked through the steps and it did exactly what he wanted. Now he was free to do whatever horrible, torturous things that devs do to SharePoint. Another dev/admin cooperation success story.
Here are screenshots of what it looks like:
The normal config wizard welcome screen.
This is the old, bad farm information. Make sure when you rerun the wizard you use a different name for your ConfigDB than what is listed here.
Click yes, this is exactly what you want to do.
That's all there is to it. The SharePoint binaries are still installed, but it's no longer configured. If you go into IIS you'll notice all your SharePoint related sites have been removed.
Now rerun the Config Wizard and create a new farm.
Click Next.
Click "Create a new server farm."
On the next screen input your farm information. Make sure your Database name is different than what your old ConfigDB was.
You'll have to set up a new farm passphrase, since this is a new farm.
You'll also need to set up Central Admin, since the previous Central Admin instance was removed when the server was removed from your old farm.
That's all there is to it. Look over your settings and hit Next.
Now, fairly quickly you'll have a fresh new SharePoint farm to use, or abuse if you're a dev like Dan.
tk 1/4/2010In the last week I've had two separate incidents where KB973917 was installed on a server and it either prevented a formerly working SharePoint farm from working, or it prevented a clean machine from getting SharePoint installed. I wanted to add a blog post to the chorus of blog posts already out there on this, to make it easier for folks to find.
The first problem I encountered was a MOSS farm running on 64 bit Windows 2003 server. It had been happily running for months. Now all of a sudden whenever someone tried to hit it with a web browser they were met with an "Internal Server Error" and the Application Pool would crash with "Unknown error." The app pool would restart, but would crash again as soon as someone hit it. This was with all web apps, including Central Admin. To make things more confusing, SharePoint itself seemed to be fine. I could use STSADM to do anything STSADM does and it worked great. I could enumerate sites and webs, anything. IIS seemed to be broken, not SharePoint. I asked the customer what they had changed, and they answered, "Nothing." J In their defense, it had been over two weeks since they had applied any patches. Our friend KB973917 was in that list though. I had seen something go across Twitter about a patch breaking SharePoint, but I hadn't paid much attention. I looked through all the patches that had been installed in the last round and started searching on Bing for "<patch> SharePoint." Searching for "KB973917 SharePoint" yielded me a bunch of hits with titles that suggested this might be what I was looking for. Particularly KB2009746 hit the nail on the head and described exactly what I was seeing. Contrary to what the KB said, I did uninstall the evil KB973917, and that alone didn't fix the issue. When I reinstalled SP2 for Windows Server 2003 though IIS started working again, and therefore SharePoint was happy. I probably could have just reinstalled SP2 and been fine.
Today I stumbled onto another problem that was caused by KB973917. I had a fresh build of Windows Server 2008 and I was blessing it with an install of MOSS 2007. SP2 for MOSS was built in. The install went very quickly until it got to the "Applying Updates" part where it installs the patches that are slipstreamed. This went very, very slow. After 35 minutes it crashed, giving me the "Windows is looking for a solution" message box. This was odd. I had heard of something similar to this (though not identical) before, and it was caused by the security on the box being very tight and SharePoint not being able to write to places in the file system and Registry that it needed to. I removed all GPOs that had been pushed down, and disabled UAC and tried again. Same failure. There were no clues in the event log. The SharePoint installer log was very little help, it really only showed this:
Executing command path: 'C:\Program Files (x86)\Common Files\Microsoft Shared\SERVER12\Server Setup Controller\wrapinst.exe', args: 'timeout=2950 MsiPath=msxml\msxml6.msi'
Error: Command: 'C:\Program Files (x86)\Common Files\Microsoft Shared\SERVER12\Server Setup Controller\wrapinst.exe' failed to return after 600000 milliseconds Type: CommandFailed.
Error: Command: 'C:\Program Files (x86)\Common Files\Microsoft Shared\SERVER12\Server Setup Controller\wrapinst.exe' failed to return after 600000 milliseconds Type: CommandFailed.
Error: Command: 'C:\Program Files (x86)\Common Files\Microsoft Shared\SERVER12\Server Setup Controller\wrapinst.exe' failed to return after 600000 milliseconds Type: CommandFailed.
Catalyst execution finished: 01/04/2010 12:10:32. Return code: 30008. Exception caught: CommandFailed.
PERF: TickCount=4334578 Name=RunSetup Description=End function
There was my 35 minutes, 600000 milliseconds (10 minutes) at a time. I did some searching and nothing really jumped out. At this point I wondered if something was wrong with the machine, so we jumped over to another machine and tried to install. Same problem. Three attempts, three failures. I tried a few more things to no avail. Almost as a joke I suggested to the customer to uninstall the evil KB973917 and install SP2 for Windows Server 2008. I suggested that only because it seemed the last part of the SharePoint install was trying to configure IIS on the box, and KB973917 broke IIS on the Windows 2003 box I had seen the week before. We did it and SharePoint installed successfully. Another SharePoint casualty of the much maligned KB973917.
I don't completely understand why this patch is wreaking such havoc on IIS and SharePoint. I want to get this post out in case anyone else is having weird problems and can't quite seem to stitch it all together. I've wasted too many hours on this bugger myself, hopefully I can save you folks an hour or two. J
tk 12/31/2009MOSS 2007 allows you to import profiles from a user store to populate user information in SharePoint. 90% of the time this is an import from Active Directory (AD). While AD is used to store users, it's also used to store other non-user resources like conference rooms and projectors. These are things that you want to have calendars so you can schedule them. That's a good use of technology. However, depending on how your AD is laid out your users and resources end up together in the same Organizational Unit (OU). Unlike chocolate and peanut butter, users and resources aren't always great together if you're using SharePoint profile import. You don't necessarily want all your conference rooms cluttering up your SharePoint profiles. There's good news and bad news about that. The good news is that you can tweak your profile import with LDAP query strings. The bad news is that there are only three people in the whole world that understand LDAP queries. The worse news is that I'm not one of them.
When this comes up there's normally much searching of Bing, gnashing of teeth and swearing when LDAP queries need to be tweaked to fix profile imports on MOSS. It's always a horrible experience for consultant and customer alike. This came up again a couple of weeks ago. A customer had a SharePoint environment that was importing a lot of non-user resources and they wanted it to stop. They had a separate AD team at their company so they couldn't just move the resources into another OU or give them a custom attribute or something easy to search on. I was tasked with finding an LDAP query string that would rid them of all their non-user resources without any help from their AD team. A task nearly impossible for humans. I did find a way…
While trying to figure out how best to accomplish this I asked a buddy of mine, Jason, who deals with AD a lot. I'd link to his blog, but he hates blogs. Probably because he rarely has anything intelligent to post (not that that stops me). So here's your shoutout, Jason. Anyway, as I was whining about my lot in life, Jason came up with probably the only smart thing I've ever heard him say, "Why don't you use ADUC to create your LDAP query strings?"
"ADUC" is the Active Directory Users and Computers snap-in used to manage users and computers in your AD. Unbeknownst to me, ADUC has a search function that creates these cursed LDAP query strings with a GUI. More importantly, after you've perfectly crafted your LDAP search string, you can copy it out and paste it right into SharePoint. As an added bonus, ADUC gives you immediate results on your search, so you don't have to run a profile import in SharePoint every time to see if it worked. It worked like a champ for the customer, so I thought I'd outline it all here.
Here's the before picture:
You can see we've got some users here and a whole lot of conference rooms. Here's what our SharePoint profile import settings look like:
We're just importing the whole domain, which is why we're getting all the extra garbage in our imports. Normally we'd set our "Import profile data from" setting to "Custom Source", cross our fingers and hope for the best. We're going to do that, but with a better plan. To start, we'll open up ADUC and start whittling down the results until we get what we want. Normally ADUC is installed only on Domain Controllers (DC) but it can be loaded on any server or workstation version of Windows by installing the Server Admin tools. Let's fire up ADUC and see what our users look like:
I added some extra columns to the Users view to see what information I had to work with. I ended up going with the Job Title column, as all the real users had that populated. Now I just need an LDAP query that says "Only show me objects that have Job Title" populated. No problem for ADUC. Here's a breakdown of how I created the query:
I right clicked on Saved Queries and picked New Query. Then I named it "Only users" and clicked "Define Query." On the next box I clicked "Users, contacts…" from the Find dropdown., then I clicked the Advanced tab. Then I used the Field dropdown to pick a Field and the appropriate Condition and Value that I want. In the screenshot I defined a condition where I only get objects that have a Job Title present. When you click OK the New Query box will show you the query that was created for you. It looks like this:
The Query string at the bottom is what we'll use, if it gives us the results we want. When we hit the final OK box we'll see the results of the query we generated:
As you can see we now are only getting users, which is what we wanted. Now go back in to that query (via Edit) and copy out the Query string. It should look like this:
(&(&(|(&(objectCategory=person)(objectSid=*)(!samAccountType:1.2.840.113556.1.4.804:=3))(&(objectCategory=person)(!objectSid=*))(&(objectCategory=group)(groupType:1.2.840.113556.1.4.804:=14)))(objectCategory=user)(objectClass=user)(title=*)))
That's quite a mouthful. Now we'll paste this in to SharePoint. Go back into your Profile Import settings and select "Custom Source." Then go edit the Content Source, we need to change the User Filter. Paste our new query into there:
Then go back in and run a Full Import of your profiles. Here's what it should look like:
Looks like we pulled it off.
In your organization your query will likely need different formatting to match how your users and resources are configured in AD, but now you have a tool to quickly and easily build these queries and try them out.
Hope that helps,
tk 12/27/2009In this week's show we cover all my excuses for my two week absense. Then I talk a bit about my trip to India. Then I finish up with some actual technical talk about a SQL Transaction log I had trouble getting under control, and how to use Remote Blob Store (RBS) with SharePoint 2010. As usual, the chatroom was unruly.
MP3 File (Subscribe)
WMV File (Subscribe)
Running Time: 34:18
12/20/2009In my daily perusing of SharePoint blogs a couple of weeks ago I saw a blog post on Jie Li's blog on how to install Remote Blob Store (RBS) on SharePoint 2010. Imagine my excitement! I was under the impression that using RBS was going to be something we were mortals would not be able to use, but here it was. Why was I so excited? Well, with SharePoint 2003 all content had to go in content databases, no exceptions. As people started putting more content, and larger content into SharePoint the question became pretty common, "Can I store my large files outside of SQL?" The answer was always no. Storing files outside of SQL became the holy grail of SharePoint content storage. It would let you take advantage of all the reasons you used SharePoint; metadata, web presentation, workflows, etc. It also let you use storage that was much cheaper than SQL storage normally is. When SharePoint 2007 came out the answer to that question remained the same, "All content must be stored in SQL, no exceptions." However, after a hotfix the support for External Blob Storage (EBS) was added to SharePoint. This was almost what we needed. The hooks were there in SharePoint, but there was no way to actually use them. It was handled much like how SharePoint handles antivirus software. There were hooks into SharePoint for it, but the functionality itself didn't exist in the product. That part had to be handled by third parties or ISVs. Not a lot of ISVs jumped on this, as the interface exposed to them wasn't great, and it wasn't clear what the upgrade path would look like. Again, storing large files outside of SQL seemed just out of reach for the average SharePoint administrator, until now…
That brings me back to Jie's post. I knew that SharePoint 2010 would ship with RBS support, but I wasn't sure what RBS products we'd be able to use. Jie's post not only showed how RBS could be used, but provided an actual RBS provider. That's was pure gold. The RBS provider Jie linked to uses SQL 2008's Filestream support. That works for me. The rest of this blog post is how I installed RBS and got it working.
Again, everything I've done here is based on Jie's blog post and the links inside. Only a couple of things are things I had to figure out myself.
I already had a VM with Windows 2008 R2, in a domain. It had SQL 2008 R2 with the November CTP on it. It also had SharePoint Beta 2 (build 14.0.4536.1000) installed on it, and I had been using it a while. There were several content databases defined with a few site collections. The first thing I had to do was enable Filestream in SQL 2008 R2. I used these instructions on MSDN. Once I had the instructions, it went very smoothly. The only snag I had was I initially ran it as the wrong user. In my VM, SQL is running as contoso\administrator. SharePoint is all running as contoso\sp_farm and that's the account I logged in as normally. That account did not have the permissions to enable Filestream. After I ran it all as Administrator it worked. Now came the fun part, RBS…
In preparation for RBS I created a new Content Database for it to use, since RBS is scoped at the content database level. I used Window PowerShell to do it, since that's what the cool kids are using.
The command I used was New-SPContentDatabase –name WSS_Content_Blob –WebApplication http://shaerpoint –MaxSiteCount 1 –WarningSiteCount 0
Next I went into SQL Management Studio, as contoso\sp_farm, and ran a few TSQL commands to configure my new database for RBS. Here are the commands I used:
Here's the text:
use [WSS_Content_Blob]
if
not
exists
(select * from
sys.symmetric_keys
where name =
N'##MS_DatabaseMasterKey##')create
master
key
encryption
by
password = N'Admin Key Password !2#4'
use [WSS_Content_Blob]
if
not
exists
(select groupname from
sysfilegroups
where groupname=N'RBSFilestreamProvider')alter
database [WSS_Content_Blob]
add filegroup RBSFilestreamProvider contains
filestream
use [WSS_Content_Blob]
alter
database [WSS_Content_Blob] add
file (name = RBSFilestreamFile, filename
=
'c:\Blobstore')
to filegroup RBSFilestreamProvider
I was following the directions from this MSDN post, but I had to make a couple of changes. First, I had to make sure I had the correct database name, WSS_Content_Blob, everywhere necessary. Second, I manually created c:\Blobshare before running the TSQL commands. That was a mistake. SQL needs to make it on its own when you run the third command. Deleting c:\Blobstore fixed that and the command ran successfully.
Next step was to install the RBS bits on the SharePoint servers. (Download RBS_X64.msi) In my case it was pretty simple because SQL and SharePoint were on the same machine, and I only had a single SharePoint server. Here's the command I used to install the RBS bits:
Text:
msiexec /qn /lvx* rbs_install_log.txt /i RBS_X64.msi TRUSTSERVERCERTIFICATE=true FILEGROUP=PRIMARY DBNAME="WSS_Content_Blob" DBINSTANCE="sharepoint" FILESTREAMFILEGROUP=RBSFilestreamProvider FILESTREAMSTORENAME=FilestreamProvider_1
This install seemed to happen immediately. However it kicked off an msiexec service that ran for a couple of minutes. I had to watch it in Task Manager to see when it was finished. I was also monitoring the rbs_install_log.txt file to see when the process was finished. I was looking for the phrase "Installation completed successfully."
If I would have had more SharePoint servers I would have had to install that on all of them, or SharePoint would have been very unhappy.
You can double-check the database was changed correctly if the rbs tables appear in it. That will look like this in SQL Management Studio:
The last step, before feeling the glory that is RBS, is to go back to our old friend, Windows PowerShell and enable RBS on our content database from a SharePoint perspective. Here's what the PowerShell looked like:
Here's one place I had to deviate from the MSDN article. It says the first line should be $cdb = Get-SPContentDatabase –WebApplication http://sitename
That didn't work for me. I suspect the person writing that article had a web application with a single content database, so that command would only return one SPContentDatabase. The web application I was testing this on had three content databases, so $cdb had a collection of SPContentDatabases, which doesn't work for the next line. Reading through the PowerShell it looks pretty clear that $cdb should contain a single SPContentDatabase object. I went through the RBS install three times and had the same behavior each time.
The last step was to test RBS and upload a file and see where it ends up. The rbs_install_log.txt was 1.2 MB and a good candidate for the test. I created a site collection (with PowerShell of course) and uploaded that text file. To see if RBS worked, I navigated the c:\blobstore directory to see if my file was there. Here's what I found:
Looks like it was successful. I went through this three times and it worked every time. I tried various sizes of files and various operations on those files. I added versions, deleted them, added metadata, indexed and searched for them. It all worked just fine.
I hope this blog post inspires some of you to install RBS and play with it yourself. I do have another blog post planned where I go a little more in depth with what I found in RBS.
Have fun,
tk 12/10/2009Visual Upgrade is capability in SharePoint 2010 that allows you to view upgraded sites as they looked in SharePoint until you are ready to view them in their full SharePoint 2010 glory. Your reasons for this might be user education, or the need to update customizations you have. The Visual Upgrade is scoped at the web level, so all the pages in a web can be rendered as SharePoint 2007 or as SharePoint 2010. There are a few ways to control this. The easiest way is inside of the UI itself, and that is probably how Site Collection administrators will control how webs are rendered. Another option is Windows PowerShell. PowerShell is a great way to take care of this if you have to work with a lot of webs. It has looping capabilities that make this very easy. One scenario were you might want to do this is what a Database Attach upgrade. In this situation you have a SharePoint 2007 (SP2 or later) content database that you attach to an existing SharePoint 2010 farm. While you can force the SharePoint 2010 on the content of this content database when you attach it, that gives you less flexibility. If you choose to preserve the SharePoint 2007 UI you'll need to switch it to the SharePoint 2010 interface eventually. The PowerShell script below will take a Content Database name and determine all the Site Collections in that db. It will then walk through all the webs in those Site Collections and set them to the SharePoint 2010 interface. Let's take a look at it:
$db = Get-SPContentDatabase WSS_Content_SharePoint_2007
$db.Sites | Get-SPWeb -limit all | ForEach-Object {$_.UIversion = 4; $_.UIVersionConfigurationEnabled = $false; $_.update()}
The first line creates a variable, $db, and assigns it an object that represents the content database. Once we have that object, we can use the Sites property to get a list of all the site collections stored in it. Using pipes, we pipe the Site Collection objects through Get-SPWeb to get each web (SPWeb) for each site (SPSite). Once we get the web, we can set the UIversion property of that web to the version we want displayed. Setting the value to 4 gives us the SharePoint 2010 interface. If you want the SharePoint 2007 interface, set UIversion to 3. The next part, $_.UIVersionConfigurationEnabled = $false removes the "Visual Upgrade" option from the Site Actions dropdown. This keeps users from going in and setting the UI back to the SharePoint 2007 interface. Finally we need to execute $_.update() to write our changes to the web.
That's all there is to it. Now all the webs in that upgraded Content Database are using the SharePoint 2010 interface.
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  |
|
|
|
Ever wonder what a SharePoint smarty does in his free time? We write blog entries and books. One of the books I was fortunate enough to work has hit the shelves. You can pick up Real World SharePoint 2007: Indispensable Experiences From 16 MOSS and WSS MVPs on Amazon . The book is filled with all kinds of great information on a wide variety of SharePoint aspects. There's something in there for admins, developers and even end users. As is in the Wrox tradition, all of our pictures appear on the cover. Here's what to look for:
Click for a full size picture
If you buy books at brick and mortar stores, please ask them to carry it. My baby's gotta eat!
After you grab the book head over to the Wrox forums or post here and let me know what you think.
tk |
|
|