Creating new My Site hosts for MOSS 2007

If you should happen to recreate your SSP or your MySite host in MOSS 2007, you may find that the wizard that helped you out the first time with properly configuring your MySites host may have flown the coop and you’re left at sea about how to proceed. I know I was.

On trying to create a new My Site (for a user that doesn’t already have one), typical error messages will tell you that Self-Service Site Creation is disabled, or that there was an error in creating your personal site. Both error messages will entreat you to contact your administrator.

Here’s the full scoop on creating a My Site host in MOSS 2007 by hand from the ground up (i.e. at Web application creation on up):

Prepare new web application to take up My Site host duties:

  1. Create a new web application (e.g. http://mossdev1:25000/)
  2. Inspect Managed Paths for the new web application. You should already have:
    1. (root) - Explicit inclusion
    2. sites - Wildcard inclusion
  3. Delete managed paths:
    1. sites - Wildcard inclusion
  4. Create managed paths:
    1. personal - Wildcard inclusion
    2. mysite - Explicit inclusion
  5. End state for managed paths should be:
    1. (root) - Explicit inclusion (thanks to imsaurabh for catching this!)
    2. personal - Wildcard inclusion
    3. mysite - Explicit inclusion
  6. Create a site collection at /mysite/ managed path. This will use a My Site Host template:
    1. Choose correct web application (e.g. http://mossdev1:25000/)
    2. Title: My Site Host (doesn’t matter, really)
    3. URL: http://mossdev1:25000/mysite (no fill-in because path is explicit in managed paths)
    4. Template: Enterprise (tab) -> My Site Host
    5. Specify primary and secondary administrators.
    6. Click OK.
  7. Create a blank site collection at the / managed path to enable self-service site creation:
    1. Choose correct web application (e.g. http://mossdev1:25000/)
    2. Title: Blank site (doesn’t matter, really)
    3. URL: http://mossdev1:25000/ (no fill-in because path is explicit in managed paths)
    4. Template: Collaboration (tab) -> Blank Site
    5. Specify primary and secondary administrators.
    6. Click OK.
  8. Enable Self-Service Management. Choose from Application Management -> Application Security.

Now that you’ve created the host, here’s how to make sure it works properly in the SSP’s My Site Settings:

  1. Navigate to My Site Settings (go to your SSP’s admin pages, it’s the 3rd link in the 1st section).
    1. For form’s sake, inspect the Preferred Search Center entry. This URL should end in /SearchCenter/Pages/.
    2. Set Personal Site Services to http://mossdev1:25000/mysite/. Note that this points to the URL for the explicit inclusion path and My Site Host Template site collection you created above.
    3. Set Personal site Location into just personal. Note that this points to the URL (after SharePoint puts context to it) for the Wildcard inclusion managed path you created above.
    4. Choose the 2nd Site Naming Format: User name (resolve conflicts by using domain_username).
    5. Enable Allow user to choose the language of their personal site.
    6. Disable My Site to support global deployments.
    7. Default Reader Site Group: NT AUTHORITY\authenticated users.

Now try to navigate to your MySite link and you should be golden. Creation should go just fine.

Good luck!

Web Part Installs on SharePoint 2003 in environments where you don’t control the Database

In a continuing series of mishaps involved with a very abstracted permissions environment where one group controls all admin rights on the server, except for the group that controls all admin rights on the Database, I discovered today that if you need to install a Web Part in SharePoint 2003, you need to do it on the Web Server(s) in question while running in the context of an account that has proper permissions (I assume at least DB Creator & Security Admin if not also System Admin) within the SQL Server where your Configuration Database lives.

What we were seeing was that the Office Web Parts installer and two MSIs for custom web parts ran. The Office Web Parts installer reported that it had installed correctly. On the other hand, the MSIs reported an install error and referred to the log which was essentially empty. (MSI Web Part Packager installer logs go in C:\Documents and Settings\\Local Settings\Temp\wppackager.log.) Some 3rd party manufacturers of Web Parts do support this issue (in comparison to Microsoft, who don’t seem to report this issue in any KB article), and suggest using stsadm to install instead.

We then tried using stsadm.exe to install (some Microsoft third party web part vendors report the unhelpful MSI install failure message, even though Microsoft doesn’t) the MSI packages, and instead got the familiar Configuration Database connectivity error that refers to KB 823287:

Cannot connect to the configuration database. For tips on troubleshooting this error, search for article 823287 in the Microsoft Knowledge Base at http://support.microsoft.com.

Here’s a link I found very helpful to help explain/troubleshoot the issue.

Unfortunately, at this client, I will now need to punt to a policy question about how to approach the install next, but hopefully in your situation you’ll be able to just use an account with the right permissions to do the install.

I have been negligent – bullet updates, but I’ll get around to the major stuff later

Since I fully expect next month to be a slow month, I should be able to catch up a little.

Anyhow:

  • I am installing the Release bits of Microsoft Office 2007. I don’t know if I’ve already plugged CCleaner but I’m doing so again. I needed it because Office 2007 Beta 2 Technical Refresh didn’t uninstall entirely cleanly. An add-on I’d installed after the original install had to be manually removed, but it didn’t show up in my Add/Remove Programs, so CCleaner was instrumental in my being able to find an uninstall the bugger so I could go ahead with the install of the Release version.
  • It turns out that the extended problems I had properly creating the Shared Service Provider portion of MOSS 2007 were due to two factors:
    • I had neglected to complete the MOSS 2007 Beta 2 TR install properly. I’ll go back to that article and add the details in, but instead of running the configuration wizard right away, I should instead have uninstalled Windows Workflow Framework from Add/Remove Programs, installed the .NET 3.0 Framework RC bits and then run the connfiguration wizard.
    • I wasn’t thinking about permissions and rights properly so was creating the app pool for the Web Application that was to support the SSP with Network Service as the ID, which of course has a different PID/GUID on each machine so wasn’t mapping to the Network Service ID on the database server (2-server setup). What I should have done was create the app pool with a domain account ID that had sufficient perms on both boxes and on the SQL Server itself. It never ceases to amaze me how my mind will just drop stuff. This stuff holds for SharePoint 2003 too and I know that cold, but I just didn’t make the leap to apply it to my knowledge of MOSS 2007. Duh.
  • So I need to blog permissions articles that have been popping up on Technet/MSDN lately.
  • I also need to update on my/my company’s progress in fixing (or trying to fix) the Full Text Search in our production deployment of SharePoint 2003. Client still not interested in calling Microsoft Product Support Services. Now it looks like it might have to do with the Cluster configuration and the FTDATA folder. If it isn’t that, not only am I, but my company is tapped out and it is totally time to stop playing political games and djust call Microsoft PSS.
  • There are some links I found to training materials that I’ll also blog (I’ve been doing research on behalf of my client’s Training department).
  • I’ll be working on customizing my company’s portal soon, and doing a little mini-app with a guy based in the Richmond office, so we’ll see how well the development/customization process on MOSS 2007 collaborates. More updates there, hopefully by next week.

Anyway, been terribly busy, too busy, perhaps, to blog, but I’ll try to return to it, because taking notes is important to me, and putting it here means I can find it whereever I have Net access, and maybe it’ll help out other folks too.

Search Link Salad

Stuff for me to remember based on current research (more about searching in WSS 2003, but am finding links related to future configurations of SPS2003 or MOSS 2007 search):

Some documents are not returned in the search results when you use the Advanced Search feature in SharePoint Portal Server 2003 to search for content that has a custom property

How to determine if Windows SharePoint Services or if FrontPage Server Extensions is in use in IIS

Speculation – Further attempted fixes to WSS 2.0 Full Text Search

So the current situation is that despite my past posts about fixes to WSS 2.0/2003 Full Text Search, both my QA and Production environments have Full Text Search enabled, but are/were only returning results for content that pre-existed the fixes.

The Full Text Index actually existed in the SQL Server Content Database (for WSS content), and the MS Search service was running properly on the SQL Server.

Reviewing the best discussion of this sort of thing that I know for steps I might have left out,  I found out that even though WSS 2.0/2003 says it’s got Full Text Search enabled, it may not in fact be enabled.

So you go to SharePoint Central Administration, then click the Windows SharePoint Services link on the left side nav bar, and then click the “Configure Full Text Services” link and even though the checkbox is already enabled, click “OK” anyway, and let the changes be applied and go check the functionality of your search against new content.

Update: This only ended up working for me in our QA environment, which is apparently different in this respect from our Production environment (still b0rked). Oh well, there may be a call to MS support in my future if I continue to be stumped.

And scarily, for me, Full Text Search started working properly, even with new content.

Server Accounts, Changing them, Permissions Issues – Followup

In my previous post (opens in new window), I said I’d let you know how it went. Turns out for various reasons we didn’t get around to testing my assertions until this morning.

It went fine. I was right about what was broken and what needed fixing. The implementation of the fix and the continued procedure to change the rest of the service accounts in the QA lab went off without a hitch, so soon, we get to do it Production too.

Database Migration breaks WSS/SQL Server Full Text Search

So here’s a little-known issue with SharePoint and Full Text Search:

On Joel Oleson’s blog (if you don’t know who this guy is and you’re in SharePoint Operations, find out quickly. Aside from Bill English [the man, his blog], he’s the other Man in SharePoint Managment/Operations – both of these guys regularly present at TechEd conventions), I found a blog entry about how, if your Full Text Search (that’s the one that works in Windows SharePoint Services, and is provided through the back-end SQL Server) isn’t working, and you migrated the database from a different server, the reason would be, possibly/probably, that you migrated the database from a different server.

Yes, I mean either with SPSBackup.exe (which should be your friend by now if you’ve been doing a lot of this and you want to keep the SharePoint Portal Search Index between migrations) or normal SQL Backup/Restore and file operations.

So anyway, there are a couple of stored procedures in the blog you should use to restore your Full Text Search. As far as I can tell, these are either SQL standard stored procedures, or, more likely, SharePoint-installed stored procedures.

Also, rather like part of my previous blog entry, the fix is essentially “turn it off, turn it on”, with some curve-balls in there if things don’t go as expected. It turned out to be thorough enough for us, so maybe it’ll be thorough enough for you.

Since I had to puzzle the blog entry out a little bit, I’ll write what I understood of how to do this here.

  1. Mr. Oleson recommends restarting your SQL Services, but we didn’t find this completely necessary.
  2. Run the following stored procedure: exec proc_DisableFullTextSearch
    1. If you get an error about there not being a Full Text Catalog, then run the following in SQL Query Analyzer and start Step 2 again:

      USE [databasename]
      sp_fulltext_database enable

      Where [databasename] is the name of the _SITE database you’re having the issue with. [But don’t actually type the [] brackets in there or your geek compatriots will laugh at you.]

  3. Run the following stored procedure: exec proc_EnableFullTextSearch

So that should be it. The procedure, as I said, is mostly just turn off, turn on again.

Full Text Search and Account Permissions

This is a more extended writeup of running Windows SharePoint Services 2003 and SQL Full Text Search on a Database box where Local Administrators (BUILTIN\Administrators) don’t have System Admin access in SQL Server 2000. (I mentioned this briefly in the Changing SharePoint Service Accounts article.)

Essentially, you’ll run up against this security policy requirement in some environments. It’s a sensible policy to make in situations/operations where the Local Administrators (of whom many are also Domain Administrators) are folks who are different from the folks who own, run and are responsible for the SQL Servers.

Part of the motivation for this separation is, of course, political. In some organizations you’ll find that folks in one team don’t want to share permissions/rights with other teams who aren’t directly responsible for the upkeep or maintenance of the bit of the sandbox they have dominion over.

The Sensible Computer Security Policy reason is the principle of Least Privileges. When the question, “Do these people/does this group need permissions to this resource?” is answered “No.”, then the principle of Least Privileges dictates that they not be given the access they don’t need. This Security Principle falls under the overall category of Risk Management. The fewer potential risks (i.e. fewer accounts sitting around waiting to be hacked that have permissions they don’t necessarily need), the fewer potential security vulnerabilities sit around waiting to be exploited by Joe Q. Attacker.

It should be noted that in the annals of computer attackers, the long-neglected account that just happens to be a local or domain administrator and just happens to have a really easy to guess password is the holy grail, and almost every computer system has at least one. So do what you can to manage your risks and reduce the number of holy grails that attackers can use to compromise your system.

Anyway, so for whatever reasons, you’ve decided that you wish to implement the policy that Local Administrators on the SQL Server are not allowed to be System Administrators (aka sa) within the SQL Server/Application itself. Note that while it appears that Microsoft “supports” this configuration, it’s not specifically allowed for in Microsoft’s relevant Knowledge Base articles, so if you do go this way, be on the lookout for potential complications. See that other article I mentioned and linked to above for an example of an unexpected consequence.

If you remove BUILTIN\Administrators from your SharePoint 2003 server’s SQL Server Logins, or remove the sa permissions from that group, you will hose up your Full Text Search in SQL Server, which of course (say it with me) will screw up your Full Text Search in your Windows SharePoint Services 2003 sites. (Because Windows SharePoint Services 2003 uses SQL Full Text Search to do its searching.)

How do you fix this?

According to KB Article 317746, if you don’t wish to add BUILTIN\Administrators back to the SQL Server Logins, you still have an out. You must:

  • Add the System Administrators Server Role to the account you are using as the Service Account for SQL Server.
  • Add the Local System account (NT AUTHORITY\System) to the SQL Server Logins.
  • Add the System Administrators Server Role to the Local System account (NT AUTHORITY\System).

You should not have to restart SQL Server after making this change. But you may also need to fix Full Text Search for other reasons, which I will elucidate in a (shortly to follow) article.

MOSS 2007 and Search

Reading the 7 Development Projects with the 2007 Microsoft Office System and Windows SharePoint Services 2007 eBook (Microsoft Press) yesterday, I was pleased to read that we’re moving off of the sometimes wildly inaccurate results-giving Full Text Search technology that SQL Server provides for Windows SharePoint Services 2003 and using the same technology the Portal is using in the SharePoint 2003 version for both Portal and WSS in 2007.

Just a little note. I’m pleased as Punch. I hope the administration/configuration has been tweaked to be a bit more intuitive, though.

Also, there appear to be a bunch of other books available to buy about 2007 these days. I should hie to a bookstore.

Changing SharePoint Service Accounts, Permissions and Troubles Found and Conquered Therein

(Note: Links to KB Articles open in new windows)

So I have a client who is security conscious enough to ask that we make SharePoint work even when the servers’ Local Administrators (members of BUILTIN\Administrators) are not members of the System Administrators Server Role in SQL Server. This is the default configuration for SQL Server – the BUILTIN\Administrators group should have a checkbox enabled next to the “System Administrators” role in the Server Roles tab of the Login properties for SQL Server.

After this helped break Full Text Search (KB Article 317746) and we fixed it, all was well and good, or so we thought.

It’s not completely obvious, but in SharePoint Portal Server 2003 running on Windows 2003 Enterprise SP1 and above (KB Article 555309), it’s required that the SharePoint Service Account be part of the servers’ (in the farm) Local Administrators. This would appear to convey the idea that SharePoint Service Accout should also be a System Administrator (role) in the SQL Server that hosts the configuration and content databases.

I believe, by running into it head first, we have corroborated this assertion.

Moving from a bad situation (where all three of our environments – Dev/Pilot, QA and Production – are running on the same service account whose password will expire in about 2 months), to a better one (we plan 2 service accounts for each environment), means we have to change the service accounts for both SQL Server services, and for SharePoint services in each environment.

(By the way: It’s actually recommended that if possible, service accounts associated with Enterprise servers like SharePoint be set with passwords that don’t expire. If your security policy requires it, you can then plan to change the password on a regular basis, but you won’t get caught out if you simply don’t have time to do it. The slightly more antagonistic policy is to make the automatic experation/reset loom over your operations people like an unassailable threat that motivates them to change the password regularly, manually, before the deadline. If you live in a more antagonistic sort of place like we do, at least have the common decency not to keep folks from changing the password early. Making the password change be required to happen on a certain day is the kind of sadism that breeds MAD IT CONSULTANTS! MAD, I TELL YOU!)

In doing so, we ran up against the problem of not having the SharePoint service account be a System Administrator in the Server Roles in SQL Server. We followed the KB Articles (SharePoint: KB Article 837813, SQL: KB Article 283811 – For SQL we actually used the SQL Enterprise Manager – it’s the easier way – try SQL Books Online for guides) for changing the service accounts, and when we got to checking the SharePoint Central Administration (to finish up the account changing process), instead of the SharePoint Central Administration, like we thought we’d get, we got a prompt to disconnect from the configuration database.

So, in a fit of troubleshooting pique, we followed the prompt and got ourselves into a deeper hole. Because at the instant that we disconnected, the server we were working on got out of synch from the rest of the server farm.

And how did we get out?

First, the primary fix is to make sure that if you’re not going to give all the Local Administrators System Administrator access in SQL Server, at least make sure that the SharePoint Service Account has System Administrator access. That’s the first thing.

Second, we need to fix the mess. If we hadn’t disconnected from the configuration database when the opportunity presented itself, restoring the System Administrator access for the service account in question would fix the whole kit and kaboodle (requiring, perhaps, closing and opening IE, or forcing a cache refresh [hold down Ctrl and click Refresh button] to see the results in IE).

Instead, since we disconnected the database at probably the worst time, the server that disconnected thinks it’s disconnected, but the rest of the farm doesn’t. Weirdly enough, the broken server acts like it thinks it’s both part and not part of the farm. I managed to get the server to the point where it serves content just fine from WSS, but SharePoint Central Administration thinks it isn’t connected to the configuration database (i.e. it’s broken).

When you try to connect to the existing configuration database, you get a weird and inappropriate error. Usually you get the error, “Unexpected error occurred.” (This error actually tells you a lot. If you google for it, you’ll find that most of the issues associated with this symptom are to do with network connectivity – this isn’t utterly bizarre – from SharePoint’s perspective, a SQL permissions error can look a lot like a network error, and whatever’s bunged up in the broken synchronization is also probably interfering and giving SharePoint weird results, which probably just go in the network bucket, because SharePoint can’t figure out where else to put it.)

Weirder still, it seems like the whole of the problem exists somewhere in the broken server’s configuration, with none of the actual problem on the working parts of the farm at all.

Why do I say this? Because the fix is really simple:

  1. Create a new configuration database with the broken server.
  2. Disconnect from the new configuration database.
  3. Connect to the old configuration database.
  4. You probably want to delete the new, unused configuration database too, but the things are pretty small, storage-wise.

If the synch error really were partly on the original configuration database and partly on the broken server, this shouldn’t fix the problem, because it would still exist in some part on the original configuration database. But in fact, this works.

Now, if, like us, you were in the middle of changing accounts for your farm, just continue on your merry way. Since you only need to make that System Administrator Server Role for the SharePoint Service Account fix once (assuming you’re only using one SQL Server in the farm), you should be good to go with the rest of the servers in the farm.

Since I should be doing this tomorrow in our QA environment (Dev’s down right now), I’ll let you know if there’s more to know, when I’ve figured it out.

Wish me luck!