This will be the first of a series focusing on those areas of storage that are commonly overlooked when planning storage for Microsoft SharePoint Products and Technologies. In this post we’ll look at the native Recycle Bin in Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 to understand its fundamental aspects and impacts on storage.
The Recycle Bin enables end-users to easily recover content deleted within a site collection and is configured in two separate and unique stages referred to as the 1st and 2nd stage each with its own configuration properties.
The 1st stage Recycle Bin is configured using a numeric representation that defines the duration an item can exist in the Recycle Bin (SPWebApplication.RecycleBinRetentionPeriod Property), the default value of this property is 30 days; while the assumption is often made that this number is unique to the 1st stage Recycle Bin, conversely it applies to both the 1st and 2nd stage Recycle Bins and is based on the initial delete date of the content.
The 2nd stage Recycle Bin is configured on a percentage of quota value or more specifically a quota allocation (SPWebApplication.RecycleBinRetentionPeriod Property) as opposed to a duration as with the 1st stage Recycle Bin. This quota is configured to 50% of the live site quota by default, for example, a Web application with a default quota template of 1 gigabyte applied to a site collection can potentially result in a site collection consuming up to 1.5 gigabytes in a content database or more so, a Web application can be 50% larger than planned. Though the 2nd stage Recycle Bin can be disabled entirely, you should carefully consider the recovery costs that can arise when content is requested for recovery – many organizations choose to increase the duration an item can exist in the 1st stage as a mitigation strategy.
Windows SharePoint Services 3.0 uses an automated cleanup service based on the initial delete date of a specific item and applies to both the 1st and 2nd stage Recycle Bins enabled as a Timer Job (see illustration).
Controlling the size of the 2nd stage Recycle Bin is an essential practice to managing storage for a site collection. The automated cleanup service will purge both the 1st and 2nd stage Recycle Bins when the initial delete date for a specific item or collection of items has reached its configured duration. Reducing the storage allocation for the 2nd stage Recycle Bin to purge items as the configured quota is reached on a more frequent basis can provide for the better management of storage; however, again may increase recovery costs where content becomes necessary to be restored from a conventional backup resource.
After several months of work, we’re pleased to announce publication of a new whitepaper: Upgrading SharePoint Portal Server 2003 Customizations to SharePoint Server 2007. To view the whitepaper visit: http://msdn2.microsoft.com/en-us/library/bb954662.aspx or http://blogs.msdn.com/joelo/archive/2007/11/06/upgrade-customization-articles-posted.aspx for additional details.
Moving site collections between domains is not a common operation, but occurs frequently enough to provide some prescriptive guidance.
SharePoint maintains the security identifiers of user accounts as opposed to just usernames, as a result, when restoring a site collection to a farm in a domain other than that where the original source site collection was located, those usernames are no longer recognized regardless as to whether or not those usernames were recreated in the target domain. STSADM provides an operation suited to address this potential issue in the migrateuser operation which will effectively resolve the security identifiers of the users.
Migrating User Accounts
STSADM -o migrateuser migrates a user account in Microsoft Windows SharePoint Services 3.0 to a new user name and binary identifier (security identifier).
stsadm -o migrateuser
-oldlogin specifies the credentials of the source account (account to be migrated) and -newlogin the target account or destination credentials of the new account replacing the source account. When specifying the -ignoresidhistory argument the security identifier history of the destination user is checked to determine and match the name of the old user or otherwise the meta data is ignored.
Internet Information Services 7.0 Application Pool Modes introduces changes in how application pools are managed and process requests that involve managed resources. In Internet Information Services 6.0 worker process isolation mode and in Internet Information Services 5.0, isolation modes are set at the server level. The result is that both isolation modes cannot be run simultaneously. In Internet Information Services 7.0 modes are set at the application pool level allowing applications to be run simultaneously on the same server in application pools with differing process modes (Integrated and ISAPI (Classic). Integrated application pool mode leverages the integrated request-processing architecture of Internet Information Services and ASP.NET, by calling native and managed modules to process portions of a given request and subsequently generating the response; however, SharePoint Products and Technologies is limited to the use of the classic or ISAPI application pool mode for its application pools handling requests as in Internet Information Services 6.0 worker process isolation mode; in this scenario the separation of Internet Information Services and ASP.NET in classic application mode or managed pipeline mode results in the duplication of some processing steps to include authentication and authorization. SharePoint Portal Server 2003 and Windows SharePoint Services 2.0 used stsfltr.dll to provide request intercept functionality, in Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 a .NET 2.0-based HttpModule replaces the ISAPI filter; however, the platform remains metabase bound limiting Windows Server 2008 to using the Classic managed pipeline mode or ISAPI application pool mode, when configuring Internet Information Services 7.0 application pools for use with SharePoint Products and Technologies it is important to understand these limitations.
Determining Application Pool Mode
When introducing the Windows Server 2008 server machine where Windows SharePoint Services 3.0/Microsoft Office SharePoint Server 2007 has been installed to an existing server farm, your application pools will be configured to use the Classic managed pipeline mode or otherwise, ISAPI application pool mode (see illustration) and/or when provisioning Web applications on a new or existing server farm.
To determine the application pool mode for a Web application in Windows Server 2008, open Internet Information Services 7.0 and navigate to the Application Pools node. The Application Pools node provides a list of available application pools, state, .NET Framework version, and managed pipeline mode including additional information about the credentials running on the application pool.
Slipstream is a common term used at Microsoft to define the merging of patches or updates into the original installation sources of a program.
What are the benefits of slipstreaming….
Creating a slipstream image reduces the operational overhead required to introduce a specific build of software to include Windows SharePoint Services 3.0 and/or Microsoft Office SharePoint Server 2007 into an environment. For example, if an organization has standardized on a specific set of updates and/or patches that will be applied in a given configuration, these updates and/or patches can be included in the original installation sources and subsequently installed with the source application. Slipstreaming a Windows SharePoint Services 3.0 and/or Microsoft Office SharePoint Server 2007 is a simple process providing you have access to the original and update sources…
Example (Windows SharePoint Services 3.0 + KB941422):
To install a specific Windows SharePoint Services 3.0 build such as 12.0.6039 which is the build number associated with KB941422:
- Download Windows SharePoint Services 3.0 to C:TEMP on a Web front-end server
- Open a Command Prompt and navigate to C:TEMP
- Enter C:TEMPSharePoint.exe /extract:C:WSS and depress Enter
- The contents of SharePoint.exe will be extracted to C:WSS
- Download Windows SharePoint Services 3.0 KB941422 to C:TEMP on a Web front-end server
- Open a Command Prompt and navigate to C:TEMP
- Enter C:TEMPwss-kb941422-fullfile-x64-glb.exe /extract:C:WSSUpdates and depress Enter
- The contents of wss-kb941422-fullfile-x64-glb.exe will be extracted to C:WSSUpdates
When setup.exe is executed from C:WSS, Windows SharePoint Services 3.0 (RTM – build 12.0.4518) will be installed and KB941422 applied during the installation process. The end result is an installation of Windows SharePoint Services 3.0 build 12.0.6039 without the requirement of installing KB941422 separately and the requirement of running the SharePoint Products and Technologies Configuration Wizard to upgrade binaries on each server machine in the server farm.