Alexander’s Blog

Microsoft has published a 30-page white paper that provides information and guidelines for building scripts that can automate the installation of Office SharePoint Server 2007, the configuration of servers, and the creation and joining of farms. Code samples that you can copy and customize to match your farm and configuration are included.

The script will help you setup and configure the prerequisites, install the SharePoint Server, configure the services, and create and configure the sites.

WARNING! This white paper was last updated in 2008. I should warn you that the script that creates service accounts does not include the proper domain and groups right that are necessary. Read my blog about the service accounts that are necessary to properly install MOSS 2007 and then modify your script accordingly.

Download the white paper here.

The Microsoft SharePoint Administration Toolkit contains functionality to help manage Microsoft Office SharePoint Server (MOSS) 2007 and Windows SharePoint Services (WSS) version 3.0. This toolkit contains the ability to diagnose performance issues, perform bulk operations on site collections, an Stsadm operation to update alert e-mails after the URL for a Web application has been changed, and a User Profile Replication Engine tool.

The supported operating systems include Windows Server 2003, Windows Server 2008, Windows Vista and Windows XP. You must have MOSS 2007 or WSS 3.0 installed on your computer. Microsoft recommends that version 1.0 and 2.0 of the SharePoint Administration Toolkit be uninstalled first before you install version 3.0 of the SharePoint Administration Toolkit.

Here are the download links:

Microsoft SharePoint Administration Toolkit v3.0 x64

Microsoft SharePoint Administration Toolkit v3.0 x86

SharePoint Permission Reporting Tool

Included in the SharePoint Administration Toolkit from Microsoft is the Permission Reporting Tool, which provides various components to help better understand how security is being derived and applied across and within sites, lists and item. The tool includes three components - the Compare Permissions Sets function, the Check Effective Permissions function and the Broken Inheritance Reports function. Here’s a video on TechNet that will show you how to use the Permission Reporting Tool.

I am glad someone is looking out for Site Administrators. There is a lot of focus on resources for Network and SharePoint Administrators, for obvious reasons, but it’s important to also keep the Site Administrators in mind. I’ve noticed that my colleague Sharee English is often talking and blogging about Site Administrators. She recently posted a blog that lists training resources for SharePoint Site Administrators. Here’s a quote from her blog.

“Site Administrators have the largest burden when it comes to SharePoint. They are responsible for managing permissions, creating lists and libraries, and maintaining metadata. Most site administrators have never done any of these things before and may not even know what some of these things mean. Luckily there are so many resources available.”

Click here for more details and links to the resources that she has listed.

End users are so glad to see Windows 7 released, an operating system that works so much better than Windows Vista. The developers, system administrators,  and Microsoft Certified Trainers are not too happy to find out that Microsoft doesn’t support Microsoft Virtual PC 2007 in Windows 7 and even though there are ways to install it (see my blog post “How to Install Microsoft Virtual PC 2007 on Windows 7″), you cannot install a 64-bit guest operating system in Virtual PC 2007.  Yes, although Virtual PC 2007 can be installed on a 64-bit host operating system, you cannot run any 64-bit guest operating system in Virtual PC 2007.

Unfortunately, SharePoint Server 2010 can only be installed on a 64-bit computer. Which means, if you are a developer, trainer, or a tester interested in testing SharePoint Server 2010 in a Virtual Machine, you can’t, You have to go buy a 64-bit computer just to test SharePoint Server 2010, or look for non-Microsoft solutions. For some people it may not be a big deal to look for non-Microsoft solutions but for people like me who teach, consult, support, test, and write about Microsoft technologies and products, it sure makes our jobs difficult.

Luckily, CodeProject has an interesting solution that allows running SharePoint 2010 on a Windows 7 x64 computer simply by modifying the config.xml file located at C:\Program Files (x86)\MSECache\oserver2010. Here’s how.

- Go to C:\Program Files (x86)\MSECache\oserver2010
- Go to the Files folder
- Go to the Setup folder
- Open config.xml
- Add the following line before the closing </configuration> tag

<Setting Id=”AllowWindowsClientInstall” Value=”True”/>

Click here to read the details on CodeProject’s Web site. Before you get started, I encourage you to read this post from MCT Michael Pisarek who explains the steps and gives you some nice tips.

For security reasons, it is best to ensure that the service accounts used with Microsoft Office SharePoint Server (MOSS) 2007 run with only the minimum permissions necessary. This is referred to as the principle of least privilege.

Microsoft recommends two general rules that you should apply to all your MOSS 2007 service accounts:
- Use separate domain user accounts for services with different security requirements.
- Do not use domain user accounts with the local administrator or domain administrator privileges to run any services.

Microsoft suggests in one of its white paper that you can use a single service account with administrative privileges to install MOSS 2007 and when everything is working perfectly then you can go back and assign the services with different accounts with minimum permissions. Here’s the exact quote from Microsoft:

To reduce troubleshooting time, you can install an Office SharePoint Server 2007 server farm by using a single service account with administrative privileges. When you are sure that everything works correctly, you can then assign the services to different accounts with minimum permissions.

However, I am totally against this recommendation. On paper this may sound like a good idea but in the real world this can potentially become a nightmare. It’s bad enough that you need so many different accounts to run SharePoint, once you start messing with the service accounts you may end up running around in circles and troubleshooting can become very difficult.

If you must change service accounts and passwords, then check out my blog from December 2008: How to Change Service Accounts and Service Passwords in MOSS 2007 & WSS 3.0.

Here’s a table of Minimum Permissions Required for MOSS 2007 Service Accounts. The information is based on a Microsoft TechNet document. If you are interested in only the necessary SharePoint service accounts then check out Sharee’s blog Necessary SharePoint Service Accounts. She uses her vast SharePoint knowledge to explain things in more detail. There are so many lists out there that document MOSS accounts necessary to install SharePoint properly and some of them are really convoluted. Because Sharee has done tons of successful  installations at our clients based on the table that she has put together, I’ve created a table of accounts based on her table and then I also put together a script that creates all the accounts in an OU called Service Accounts. I have tested the script and it works great. Make sure you check out her blog because she has additional valuable information that I have not included in this post.

Table of Necessary MOSS Accounts (based on Sharee’s recommendation)

Here’s a table of necessary MOSS 2007 accounts. This is a fancy version of Sharee’s table. The table includes the purpose of each account, and its group, domain and SQL rights. You can use your own naming convention. I started my accounts with SP (for SharePoint….or SeattlePro) so I can recognize them as the accounts that were created by me, rather than the system.

WARNING! Although standard Active Directory accounts can have spaces and can be longer than 20 characters, I suggest you limit your account names to 20 characters because the Pre-Windows 2000 login names are limited to 20 characters in WS08 and can’t have spaces. You may not run into any issues in the near future if you don’t follow my advice but I think it is better to be safe than sorry.

Script to Create Necessary MOSS Accounts

To create all the above necessary accounts and the OU, you can download the script here. The results will look like this. This script adds all the necessary permissions required for the accounts in the description so you can easily verify that you have the permissions set properly.

WARNING! Make sure you change the password in the script to match with the password that you want to use for your service accounts.

Troubleshooting Tip

You may encounter a problem when you try to give the service accounts permission to impersonate a client after authentication. On your WS08 Domain Controller you can start Group Policy Management Console, go to Group Policy Objects, right-click Default Domain Controllers Policy and select Edit. In the Group Policy Management Editor, go to Computer Configuration, Policies, Windows Settings, Security Settings, Local Policies, User Rights Assignment and double-click Impersonate a client after authentication. Check the box Define these policy settings. If you simply add the service accounts you created and then click Apply or OK you won’t get anywhere. Notice that the warning at the bottom is telling you that you need to add the Administrators and the SERVICE account.

It may not be obvious but what that means is that you need to literally add the Administrators and SERVICE account as shown below in the screenshot and then when you click Apply the warning message will disappear and you will be able to click OK to proceed.