If these annoyances get to you, learn how to work around them
|Executive Summary: Microsoft Office SharePoint Server (MOSS) 2007 and Windows SharePoint Services 3.0 are hugely popular collaboration platforms, but they're not without their faults. Perhaps Microsoft will fix these gaps in future versions, but until that happens, you can use these tips to work around things such as having to remember the port number when accessing SharePoint's Central Administration console, having to drill down whenever accessing the Stsadm utility, and assigning a permission level for the Check In Documents feature.|
Although Microsoft SharePoint is a powerful, transforming technology in our enterprises, it presents many administrative obstacles in configuration, management, and security. Let’s look at some common headaches that IT professionals face when implementing SharePoint Products and Technologies.
The Random Port for Central Administration
When you perform a basic installation of Windows SharePoint Services (WSS) 3.0 or Microsoft Office SharePoint Server (MOSS) 2007, the setup routine makes all configuration choices for you. Along the way, SharePoint setup selects a random port on which to publish the Central Administration website. This means that you’re forced to access Central Administration using a URL in the format http://server:port number, but you must know the port number. Remembering a random port number for one farm’s Central Administration site is painful enough. Multiply that by several farms, and you’ll quickly be checking yourself into the SharePoint funny farm.
Luckily, you can retrieve the port number by looking at the list of web applications in the Microsoft Management Console (MMC) IIS Management snap-in. You can also use the Stsadm command (stsadm.exe). To use Stsadm, open a command prompt and focus it on the BIN folder by typing
cd %CommonProgramFiles%\Microsoft SharedWeb Server Extensions\12\bin
Then type the command
stsadm o getadminport
to get the port number.
Better yet, you can set Central Administration on each of your farms to a standard port number of your choice. There are two ways to specify the port for Central Administration. The first is to perform an advanced installation instead of a basic installation. After performing an advanced installation, run the SharePoint Products and Technologies Configuration Wizard. The wizard presents the Configure SharePoint Central Administration Web Application page, where you can configure the port manually.
Alternatively, you can use Stsadm to configure the port after either a basic or advanced installation. From a command prompt focused on SharePoint’s BIN folder, type
Stsadm also takes other switches, such as -ssl, which lets you enable Secure Sockets Layer (SSL) encryption for the administration port.
The “Non-Fully Qualified” URL for Central Administration
Sometimes, the URL of a SharePoint web application isn’t what you want it to be. SharePoint Central Administration, for example, might be tied to a non-Fully Qualified Domain Name (FQDN), such as http://server01:9999. You can change the URL of Central Administration to a more accessible name, such as http://server01.contoso .com:9999. To do so, open a command prompt and type
In our example, the command would be
Drilling Down to Use Stsadm
You’ve seen several examples of using Stsadm commands in this article, and in each you’ve had to drill down to its folder in the Program Files directory. You’ll quickly get tired of doing that. To make it easier to use Stsadm, use the following method to open a special Stsadm-enabled command prompt. Open Notepad and enter the following four commands, one per line:
set path=%path%;%CommonProgramFiles%\microsoft shared web server extensions\12\bin
Save the file as “STSADM Command Prompt.bat.” Include the quotation marks, so that the file is saved as a batch file and is not given a .txt extension. Double-click the batch file, and a command prompt will open. The command prompt includes the path to Stsadm, so you can use the command without specifying its full path.
Continue to page 2
Missing Command-Line Administration Tasks
Although Stsadm lets you perform some important functions from the command line, there are several tasks it doesn’t perform. Luckily, SharePoint MVP Gary LaPointe has contributed a phenomenal set of Stsadm extensions to the community. You can find them at stsadm.blogspot.com/2007/08/stsadm-commands_09.html. At the time of this writing, he had added 41 additional capabilities to Stsadm. Among my favorites are extensions that make it easier to copy content types, lists, and security settings between sites, but with as many extensions as Gary has created, there are sure to be a handful of useful options for you.
The Lack of a Check in Documents Permission Level
When a user checks out a document, then forgets to check it in, other users can’t edit the document. This is particularly painful when the user leaves on vacation, resigns, or is terminated. Anyone who has Design (or Full Control) permissions to a library (or to the individual document) can check in the document or discard the checkout. But it’s annoying to have to escalate such a simple matter to the site administrators. Many organizations want to allow a subset of a library’s users—perhaps the managers of the team or department—to check in documents that are locked for editing.
The Override Check Out permission allows one user to check in a document checked out by another user. The same permission allows a user to discard the checkout of a document checked out by another user. This permission is part of the Design and Full Control permission levels. You can delegate this specific permission by creating a new permission level. To do so, follow these steps:
1. Open the Site Settings page.
2. Click the Advanced Permissions link.
3. On the menu bar, click Settings and choose Permission Levels.
4. Click the Add a Permission Level button.
5. Enter a descriptive name, such as Manage Check Out.
6. In the List Permissions section, select Override Check Out. Other required permissions will automatically be selected, as Figure 1 shows.
7. Click OK.
After creating the permission level, follow these steps to create a role that will be associated with the permission.
1. Open People and Groups.
2. In the menu bar, click the New button drop-down arrow, then choose New Group.
3. Enter a group name, such as Document Check Out Managers.
4. If you want the group to have this permission for all lists and libraries in the site, select the permission in the Give Group Permission to this Site box. If you want to assign the group permissions to one or more specific lists or libraries, then clear all permissions.
5. Click OK.
Finally, you can give the role permission to the site or to one or more specific document libraries (or lists). To assign the group Override Check Out permission to the entire site, select the permission in step 4, above. To assign the group permission to one document library, open the permissions for the library, add the group (click the New button and choose Add Users), and select the permission level, as Figure 2 shows.
When you assign the role to a site or library, that site or library may be inheriting permissions from its parent—the default security model in SharePoint. You’ll have to break inheritance before you can assign a new permission at that level. To do so, click the Actions button and choose Edit Permissions.
SharePoint—both WSS and MOSS—are enormous products, so the list of annoyances is also enormous. We may have just scratched the surface in this article, but each week the To The SharePoint newsletter addresses solutions to annoyances, best practices, and insight into SharePoint technologies. You can subscribe to the newsletter at www.officesharepointpro.com.