2011 in review
The WordPress.com stats helper monkeys prepared a 2011 annual report for this blog.
Here’s an excerpt:
The concert hall at the Syndey Opera House holds 2,700 people. This blog was viewed about 55,000 times in 2011. If it were a concert at Sydney Opera House, it would take about 20 sold-out performances for that many people to see it.
Now on TechNet …
It is always exciting to me to see my work published on official sites like TechNet. Over the past few months, a chapter from the book I co-authored with Gary Lapointe has been posted and one of the presentations I gave at TechED 2011. I am currently working on a couple others and will update this as they are completed.
Chapter 20: Multi-Tenancy (Written by Gary)
My SharePoint Conference 2011 Sessions
We have just recently put another SharePoint Conference behind us. Like many of you, I made the trip out to Anaheim, CA. This was my first SharePoint conference and I was fortunate to have been selected to deliver two sessions:
SPC367: Managing LOB Data with BCS & SharePoint Search
SPC385: Service Application Federation with SharePoint 2010
Most of my demos are typically done on my 16 GB laptop, but after the demo gods frowned on me at SharePoint Saturday the Conference in Washington DC, I knew I needed to change the way I demoed my sessions. I ended up taking my sessions to the cloud. I ended up trusting both of my sessions to Rackspace and came armed with a 4G wireless internet adapter just in case the Convention Center lost my internet. My first session was delivered right after the Keynote and had over 700 people in it. The session required 3 servers:
- SPC-AD – 4 GB, hosted Active Directory
- SPC-SQL – 8 GB, hosted SQL Server 2008 R2 and SharePoint Designer
- SPC-Services – 8 GB, hosted SharePoint 2010
During this session, I created an External Content Type using SharePoint Designer 2010 and provisioned BCS, Enterprise Search, and Secure Store. The goal of the demos was to take data from an SQL Database (AdventureWorks) and surface it in Search results. While the demo wasn’t as smooth as I would have hoped, it was ultimately successful and my evaluations were great!

My second session required a little more horsepower:
- SPC-AD – 4 GB, hosted Active Directory
- SPC-SQL – 8 GB, hosted SQL Server 2008 R2 and SharePoint Designer
- SPC-Services – 8 GB, hosted SharePoint 2010 (Publishing Farm)
- SPC-SP – 8 GB, hosted SharePoint 2010 (Consumer Farm)
During this session, I created two SharePoint Farms from scratch. There were no service accounts or SharePoint databases. I used PowerShell to create the farms, the accounts, and all of the services that can be federated:
- Managed Metadata
- Web Analytics
- Business Connectivity Services
- Enterprise Search
- Secure Store
- User Profile Application with Sync
I needed peak performance or I was going to suffer a catastrophic demo. Fortunately for me and the attendees who came to my session, Rackspace delivered again. The demo went perfect and my session made the top 20 of the entire show. It was a great conference!
I have found that Rackspace offers a stable service and I basically just bet my future speaking engagements on it. Thank you Rackspace!!!
Automating SharePoint 2010
After a long break from blogging, Automating SharePoint 2010 with Windows PowerShell 2.0 is now complete and is scheduled to hit your local bookstore on June 28th, 2011.
Back Cover …
With SharePoint 2010′s PowerShell cmdlets, you can automate or manipulate almost every aspect of the SharePoint platform. Learn how to take full advantage of all this timesaving technology with the tips and techniques in this practical guide. Packed with step-by-step instructions, real-world examples, and best practice recommendations, this book gets you thoroughly up to speed on Windows PowerShell 2.0 features and SharePoint’s PowerShell implementation, saving you time and effort on tasks you do every day. Coverage includes:
- Understanding what you need to know about Windows PowerShell syntax, structure, and usage
- How to automate every aspect of a SharePoint 2010 installation, upgrade, and deployment
- Managing Web Applications, Site Collections, security, and Solution Packages
- How to automatically provision and configure virtually every Service Application
- Backing up, restoring, and optimizing the performance of your SharePoint environment
- Advanced topics such as remote administration and multi-tenancy
- Creating custom cmdlets, type extensions, and views to make you even more productive (available as downloadable PDF)
Configuring Cross-Farm Services in SharePoint 2010
Microsoft has made a number of investments in how SharePoint provides and consumes services. In SharePoint 2010, we had a number of services available to us in what was known as the Shared Service Provider (SSP). While the SSP was a great step forward from what we had in SharePoint 2003, it did offer several challenges. The primary issue with the 2007 architecture was that it was an all or nothing sort of configuration. Web apps were tied to a specific SSP and could not consume services in a selective manner. If the SSP had both Search and Excel Service configured, any SharePoint Web application that consumed Enterprise Search, also had access to Excel Services. The SSP architecture wasn’t extensible either, meaning that we couldn’t create our own services using the same SSP infrastructure. Finally, and most importantly, at least for the sake of this topic, configuring services cross-farm in SharePoint 2007 was difficult.
The new SharePoint 2010 Service Architecture has addressed all of these issues.
To make sure that the information provided is useful to everyone, we will start with the Service Application architecture and build our way up to the cross-farm or Federated Services available to us in SharePoint 2010.
To download the entire whitepaper, check out Federated Services .
Download the PowerShell Scripts.
Claims Based Authentication: Made Simple – Part 2
We will now expand on what we covered in Part 1 by connecting two farms together via ADFS 2.0. Both of the farms that will be referenced in this article were built using the same steps of Part 1. While it is not critical that you have both farms configured this way, it is strongly encouraged.
For the sake of this demonstration, one of these environments will be the internal farm (LABS); the other will be a partnering company (Contoso). The configuration of the external farm will be very similar to what we have done already. The internal farm (LABS) is where we will begin to focus our efforts.

Verify Intra-Server Communications
You can configure SharePoint to trust an external farm the same way as we trusted our internal farm. This configuration will build the trust between the two ADFS 2.0 servers; therefore, eliminating any configurations on our SharePoint 2010 Server. Before you spend any time actually configuring these steps, verify that all of your servers can communicate. I recommend trying the following:
From Contoso-ADFS, Ping Labs-ADFS.Labs.com
From Labs-ADFS, Ping Contoso-ADFS.Labs.com
You may need to configure conditional forwarding in DNS to ensure your servers can communicate correctly. If they cannot, your attempts will not be successful.
Configure the External AD FS 2.0 Server
The role of the external AD FS 2.0 server will be played by the Contoso farm. This farm will provide a cast of characters (Mighty Mouse and Mickey Mouse) that will need access to the Labs SharePoint environment. We can do this in a number of ways. The first is to configure SharePoint to trust this external AD FS configuration, much like we did in the first post. Another way is to set up a trust between the AD FS 2.0 server inside LABS.com with the AD FS 2.0 server inside Contoso.com.
The configuration portion of the external AD FS 2.0 server will start under the ‘Trust Relationships’ node inside the AD FS 2.0 Management console. The users that we need to provide to Labs.com reside inside Active Directory, so there shouldn’t be anything to do for the ‘Claims Provider Trusts’.
The Relying Party Trusts (RP) is the destination of the augmented claim. Because we are setting up an AD FS 2.0 to AD FS 2.0 configuration, our new RP will point towards the AD FS 2.0 server inside Labs.com and not the SharePoint site. If you built your Contoso farm similar to the first post, you will end up with two RPs once everything is configured. Start the wizard to add a RP.
Select Data Source
Enter data about the relying party manually
Specify Display Name
LABS AD FS 2.0
Choose Profile
AD FS 2.0 profile
Configure URL
Enable support for the WS-Federation Passive protocol
https://labs-adfs.labs.com/adfs/ls/
Configure Identifiers
Remove ‘https://labs-adfs.labs.com/adfs/ls/’
Add ‘http://labs-adfs.labs.com/adfs/services/trust’
Choose Issuance Authorization Rules
Permit all users to access this relying party
Finish
Check Open the Edit Claim Rules…
Choose Rule Type
Send LDAP Attributes as Claims
Configure Claim Rules
Rule Name: LDAP-Email
Attribute Store: Active Directory
Mapping: E-mail-Address to E-Mail Address
Configure the Internal AD FS 2.0 Server
Select Data Source
Enter claims provider trust data manually
Specify Display Name
Contoso ADFS Server
Choose Profile
AD FS 2.0 profile
Configure URL
Check ‘Enable support for the WS-Federation Passive protocol’
Url: https://contoso-adfs.contoso.com/adfs/ls/
Configure Identifier
http://contoso-adfs.contoso.com/adfs/services/trust
Configure Certificates
Add the ADFS Signing – Contoso-ADFS.contoso.com certificate from the Contoso AD FS Certificate Store (adfssts.contoso.com)
Finish
Ensure Check for ‘Open the Edit Claim Rules …”
Add Rule
Click the ‘Add Rule’ button
Choose Rule Type
Pass Through or Filter an Incoming Claim
Configure Claim Rule
Name: Pass-Through LDAP-Email
Incoming claim type: E-Mail Address
Add Rule
Click the ‘Add Rule’ button
Choose Rule Type
Send LDAP Attributes as Claims
Configure Claim Rule
Claim rule name: LDAP-Email
Attribute Store: Active Directory
Mapping: E-Mail-Addresses -> E-Mail Address
Relying Party Trusts
Select the RP for SharePoint and click ‘Edit Claim Rules…’
Click ‘Add Rule’
Choose Rule Type
Pass Through or Filter an Incoming Claim
Configure Claim Rule
Claim rule name: Pass-Through LDAP-Email
Incoming claim type: E-Mail Address
Pass through all claim values
Contoso ADFS Certificates

Browse LABS site with Contoso User

Claims Based Authentication: Made Simple
In less than 9 days, I will be attending Rotation 6 of the SharePoint Microsoft Certified Master’s program. I built this post as a “cheat sheet” to help me remember some of the key areas on claims configuration. This post is in multi parts. Part one is a guided step through on configuring CBA inside your farm. Part two will add an external farm’s ADFS server to the rotation.
My lab environment is broken down into three farms. For the purpose of this article, only two are necessary. Both of these farms are consuming services from another farm, but that is an entirely different story. Here, we will focus on getting Kerberos up and running and then setting up CBA.
Many of the blog posts that I have seen are great as far as setting up the ADFS wizards or giving you the PowerShell scripts you need to get Claims working, but those solutions only appear to work on a single server. Each farm has three servers: Domain Controller, SharePoint and SQL, and an ADFS 2.0 server. I have combined the SQL and SharePoint 2010 server together only because of the lack of resources. My lap top has 16 gigs of RAM and I have 3 farms running at all times. By combining SQL Server 2008 R2 and SharePoint 2010, I put my most resource intensive servers together and give them 3.5 Gigs of RAM. The other two servers are starved down to 512 K. This seems to work great for tinkering and testing to see how things work.
I have included the server names along with their IPs. While it is not important that your environment be set up exactly like mine, I would encourage you to stick to the script as much as possible for your first or second run. I have gone through these steps three times to ensure that you will have success in implementing your environment. There may be a step or two here that may be unnecessary, and as I find those, I will remove them.
This first part is broken up into 6 parts: Account Set Up, Creating a Claims Aware SharePoint Site, Creating a Site Collection, SSL Certificates, ADFS 2.0, and Configuring SharePoint to use Claims. To keep this post small and easier to read, I have left out many of the screen shots and have only kept in the main options. The intent is not to explain how and why Claims Based Authentication works, I focus on more how to help get it set up so that you can either get your first environment up and running or debug your current situation. My previous post on Claims goes through many of the wizards, but I have found that going through it step by step, I ended up with missing certificates and did not set up Kerberos delegation. Without Kerberos delegation, these steps will return at Not Authorized – HTTP Error 401. The request resource requires user authentication.
With that, let’s get into it.

Account Set Up
- Create a new service account (labs\adfsservice)
- Create a new service account (labs\spcontent)
- SetSPN -A http/labs-adfs.labs.com labs\adfsservice
- SetSPN -A http/intranet.labs.com labs\spcontent
-
Modify the properties of both accounts (adfsservice & spcontent)
- Trust this user for delegation to any service (Kerberos only)
-
Modify the properties of the Labs-ADFS & Labs-SPS computers
- Trust this computer for any delegation to any service (Kerberos only)
- On Labs-DC (DNS Server), add a Host A Record (intranet.labs.com) pointing to Labs-SPS
- Make sure all of your users who will access the system have email addresses!!!!
Create a Claims aware web application using SharePoint 2010
- Add labs\spcontent as a managed account in SharePoint
- Authentication – Claims Based Authentication
- Port – 443
- Host Header – intranet.labs.com
- Allow Anonymous – Yes
- Use Secure Sockets Layer (SSL) – Yes
- Integrated Windows Authentication – Negotiate (Kerberos)
-
Application Pool
- Application Pool Name – SharePoint Content
- Configurable – LABS\spcontent
- Database Name – LABS_Content_Intranet
Create a Site Collection
- Title – LABS Intranet
- Enterprise Wiki
- User Name(s) – Labs\Administrator & Labs\Fred
SSL Certificate
- Download and Install SSLDiag.exe – Version 1.1 (x64)
- Open up Internet Information Services (IIS) Manager
- Click Sites, make note of the ID for SharePoint – intranet.labs.com443 (1771713514)
- Open command window (cmd) and enter “CD c:\Program Files (x86)\IIS Resources\SSLDiag”
- SSLDiag /selfssl /N:CN=intranet.labs.com /K:1024 /V:730 /S:1771713514 – Hit Enter
- You can verify that you now have a SSL certificate by checking the bindings of your site
- Visit your site and verify it works – https://intranet.labs.com
- Verify the Security Logs have your account signing in as Kerberos
ADFS 2.0
- Install the correct version for your OS
-
Open Internet Information Services (IIS) Manager
- Create a Self-Signed Certificate using the wizard
- Friendly name labs-adfs.labs.com
-
Server Configuration Wizard
- Create a new Federation Service
- New federation server farm
- Labs-adfs.labs.com
- Service account: labs\adfsservice
-
Let Wizard complete configuration
- Ignore Configure service settings warming
-
Add a Trusted Relying Party (RP)
- Enter data about the relying party manually
- Display Name – Labs SharePoint Server
- AD FS 2.0 Profile
- Enable support for the WS-Federation Passive protocol
- https://intranet.labs.com/_trust/
-
Relying party trust identifier
- Add – urn:LABS-SPS:adfs
- Remove – https://intranet.labs.com/_trust/
- Permit all user to access this relying party
- Keep the check box for ‘Open the Edit Claim Rules…”
-
Edit Claim Rules for Labs SharePoint Server
- Add Rule
- Send LDAP Attributes as Claims
-
Claim Rule
- Name: Email Address
- Attribute Store: Active Directory
- LDAP Attribute: E-Mail-Addresses
- Outgoing Claim Type: E-Mail Address
-
Export the STS Certificate for use on the SharePoint Server
- Open the ‘Certificates’ node in the AD FS 2.0 Management Console
- View the Token-Signing Certificate
- Install the Certificate
- Copy To File …
- DER encoded binary X.509 (.CER)
- Save – C:\Certs\adfssts.labs.com
- Install the Token-Decrypting Certificate
Configure SharePoint to Use the Claim
- Open PowerShell Window
- Copy adfssts.labs.com to local machine
- Import certificate into the ‘Trusted Root Certification Authorities’
-
Add the PowerShell script highlighted below
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“c:\Certs\adfssts.labs.com.cer”)
$map1 = New-SPClaimTypeMapping “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName “EmailAddress” -SameAsIncoming
$realm = “urn:” + $env:ComputerName + “:adfs”
$signinurl = “https://labs-adfs.labs.com/adfs/ls/”
$ap = New-SPTrustedIdentityTokenIssuer -Name “ADFS 2.0″ -Description “ADFS 2.0 Federated Server” -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimTypeNew-SPTrustedRootAuthority “Labs ADFS Token Signing Trusted Root Authority” -Certificate $cert
- Inside Central Administration, click Security, Manage trust, and verify “Labs ADFS…” is there
- Specify Authentication Providers, Default, Check Trusted Identity Provider, Check ADFS 2.0
- Log in using Windows Authentication and add a Claims users
- Close your browser
- Sign-In as a CBA user

SharePoint and the Various Application Pools
I am in the midst of co-authoring a SharePoint administration via PowerShell book with Gary Lapointe.
Automating Microsoft SharePoint 2010 Administration with Windows PowerShell 2.0
ISBN 978-0-470-93920-8
While researching application pools in SharePoint, I discovered some interesting information that I would like to share. When I discovered these, I searched for documentation on-line and could not find anything to support my findings. I then reached out to Spence Harbar who was instrumental in helping to remove the confusion I had around this topic.
SharePoint 2010 has introduced two new “types” of application pools, but before we dive into what these types are, let’s introduce what application pools are and why they are important.
Types of Application Pools
With the release of SharePoint 2010, Microsoft has released two distinct types of application pools. The first is used to host content web applications. The second is used to host service application endpoints. Before we examine these two types, let’s look at the IIS Web Application Pool.
IIS Web Application Pools
Application Pools in IIS 7 can run in one of two modes: integrated mode and classic mode. The web server will process the request differently based on the selected mode. In integrated mode, IIS will use the new request-processing pipelines of IIS and ASP.NET. If classic mode is selected, the server will route requests the same way it did in IIS 6.0; through Aspnet_isapi. For more information on this, check out Managing Application Pools in IIS 7.0.
You can create a new application pool by using the WebAdministration module. This method is very similar to how Central Administration creates an application pool by using the IIS admin tools. SharePoint 2010 differs from SharePoint 2007 in the fact that 2010 uses integrated mode as opposed to classic mode. You will see evidence of this in the $appPool output when you examine the ‘managedPipelineMode’ property.
Notice in this example that we are using the New-WebAppPool cmdlet to create the application pool. If you intend to create an application pool to host a content web application, you should the New-SPWebApplication cmdlet discuss in the next section.
# Import the IIS Cmdlets
Import-Module WebAdministration
# Set the variables
$name = “IISWebAppPool”
# Call the cmdlets
$appPool = New-WebAppPool $name
$appPool|Select *
PSPath : WebAdministration::\\SHARED-SPS\AppPools\ IISWebWebAppPool
PSParentPath : WebAdministration::\\SHARED-SPS\AppPools
PSChildName : IISWebWebAppPool
PSDrive : IIS
PSProvider : WebAdministration
PSIsContainer : True
name : IISWebAppPool
queueLength : 1000
autoStart : True
enable32BitAppOnWin64 : False
managedRuntimeVersion : v2.0
managedRuntimeLoader : webengine4.dll
enableConfigurationOverride : True
managedPipelineMode : Integrated
CLRConfigFile :
passAnonymousToken : True
startMode : OnDemand
state : Started
applicationPoolSid : S-1-5-82-1517038176-2514250230-1636255725-1940432224-2879398816
processModel : Microsoft.IIs.PowerShell.Framework.ConfigurationElement
recycling : Microsoft.IIs.PowerShell.Framework.ConfigurationElement
failure : Microsoft.IIs.PowerShell.Framework.ConfigurationElement
cpu : Microsoft.IIs.PowerShell.Framework.ConfigurationElement
workerProcesses : Microsoft.IIs.PowerShell.Framework.ConfigurationElement
ItemXPath : /system.applicationHost/applicationPools/add[@name='IISWebAppPool']
Attributes : {name, queueLength, autoStart, enable32BitAppOnWin64…}
ChildElements : {processModel, recycling, failure, cpu…}
ElementTagName : add
Methods : {Start, Stop, Recycle}
Schema : Microsoft.IIs.PowerShell.Framework.ConfigurationElementSchema
While this application pool can be used by SharePoint, if you need to create a new application pool to be used with a particular web application, then you should use the New-SPWebApplication cmdlet as shown in the next section.
Creating Application Pools for SharePoint Content Web Applications
With the release of SharePoint 2010 came a very large set of cmdlets for administrating it. One of those commands is the New-SPWebApplication cmdlet that we demonstrate below. One of the benefits of this cmdlet is that it gives you the opportunity to create a new application pool with the content web application. Once the web application is creates, I output the ApplicationPool property so that you can examine its contents. Note the type. You will see that this application pool inherits from the Microsoft.SharePoint.Administration.SPApplicationPool Class. This is important to keep in mind as in the next section; you will find that the application pools used to host the Service Application end points uses an entirely different class for its application pools.
# Set the variables
$siteName = “PowerShell for SharePoint”
$port = 80
$hostHeader = “lab.ps4sp.com”
$url = “http://lab.ps4sp.com”
$appPoolName = “MyNewSPAppPool”
$managedAccount = “Shared\spservice”
$dbServer = “Shared-SPS”
$dbName = “PS4SP_SP2010_LAB_ContentDB”
$allowAnonymous = $true
$authenticationMethod = “NTLM”
$ssl = $false
# Create the web application
$webApp = New-SPWebApplication -Name $siteName `
-Port $port `
-HostHeader $hostHeader `
-URL $url `
-ApplicationPool $appPoolName `
-ApplicationPoolAccount (Get-SPManagedAccount “$managedAccount”) `
-DatabaseName $dbName `
-DatabaseServer $dbServer `
-AllowAnonymousAccess: $allowAnonymous `
-AuthenticationMethod $authenticationMethod `
-SecureSocketsLayer:$ssl
#Get details of application pool
$webApp.ApplicationPool
CurrentIdentityType : SpecificUser
CurrentSecurityIdentifier : S-1-5-21-1164618842-3663998900-3839706364-1107
ManagedAccount : SPManagedAccount Name=managed-account-S-1-5-21-1164618842-3663998900-3839706364-1107
ProcessAccount : S-1-5-21-1164618842-3663998900-3839706364-1107
Username : SHARED\spservice
Password :
SecurePassword :
IsCredentialUpdateEnabled : True
IsCredentialDeploymentEnabled : True
Name : Microsoft.IIs.PowerShell.Framework.ConfigurationElement
TypeName : Microsoft.SharePoint.Administration.SPApplicationPool
DisplayName : Microsoft.IIs.PowerShell.Framework.ConfigurationElement
Id : 1f6c2276-2404-4f1b-8997-fb802198c3f7
Status : Online
Parent : SPWebService
Version : 16027
Properties : {}
Farm : SPFarm Name=Shared_SP2010_Config
UpgradedPersistedProperties : {}
So now you may be wondering why I introduced the IIS Web Application Pools section, if you can use the New-SPWebApplication cmdlet to create your application pools. The simple fact is that as of the time of this writing, Microsoft hasn’t yet provided use with a set of cmdlets to manage these application pools, so if you would like to start, stop, restart, or remove them, then you would do so as if they were the IIS Web application pools.
# Import the IIS Cmdlets
Import-Module WebAdministration
# Set the variables
$name = “MyNewSPAppPool”
# Restart the Applicaiton Pool
Restart-WebAppPool -Name $name
# Check the state
Get-WebAppPoolState $name
# Turn it Off
Stop-WebAppPool -Name $name
# Check the state
Get-WebAppPoolState $name
# Turn it back on
Start-WebAppPool -Name $name
# Check the state
Get-WebAppPoolState $name
Value
——————–
Started
Stopped
Started
Service Application End-Point Application Pools
Now that we have discovered the first type of application pool, we now introduce the second. With the beta release of SharePoint 2010, Microsoft released a series of cmdlets that managed application pools that hosted service application end-points: New-SPIisWebServiceApplicationPool, Get-SPIisWebServiceApplicationPool, Set-SPIisWebServiceApplicationPool, and Remove-SPIisWebServiceApplicationPool. Some time prior to RTM, these cmdlets were renamed to New-SPServiceApplicationPool, Get-SPServiceApplicationPool, Set-SPServiceApplicationPool, and Remove-SPServiceApplicationPool.
It is important to know that the application pools managed by these cmdlets are not intended for content web applications. In fact, through Central Administration, you cannot create a content web application that is hosted by a SPIisWebServiceApplicationPool (SPServiceApplicationPool). While this is possible to do in PowerShell, it is not supported!!!
To show some of the property difference between the standard application pools and those created to host the service application end-points, we create an application pool using the New-SPServiceApplicationPool below. Notice the class type for the application pools is Microsoft.SharePoint.Administration.SPIisWebServiceApplicationPool.
# Set the variable
$spName = “SharePoint Portal App Pool”
$managedAccount = “Shared\spservice”
# Create a new Application Pool using the SharePoint cmdlet
$appPool = New-SPServiceApplicationPool -Name $spName -Account (Get-SPManagedAccount “$managedAccount”)
# Write Output to screen
$appPool|select *
ProcessAccountName : SHARED\spservice
Name : SharePoint Portal App Pool
ProcessAccount : S-1-5-21-1164618842-3663998900-3839706364-1107
TypeName : Microsoft.SharePoint.Administration.SPIisWebServiceApplicationPool
DisplayName : SharePoint Portal App Pool
Id : 7045ac1f-a612-4ad9-8a66-60243587eaf5
Status : Online
Parent : SPIisWebServiceSettings Name=SharePoint Web Services
Version : 12027
Properties : {}
Farm : SPFarm Name=Shared_SP2010_Config
UpgradedPersistedProperties : {}
Get a List of Application Pools Using PowerShell
To further show the difference between these two types, we examine the output from the Get-SPServiceApplicationPool cmdet. Notice that in your environment, you will only get back application pools that can host service application end-points.
Get-SPServiceApplicationPool
Name ProcessAccountName
———————————
SecurityTokenServiceApplicationPool Shared\sqlservice
SharePoint Web Services Default Shared\SPService
SharePoint Web Services System Shared\sqlservice
To find the application pools associated with content web applications, use the Get-SPWebApplication cmdlet.
foreach($i in Get-SPWebApplication)
{
$i.ApplicationPool|Format-Table -Property Name,UserName
}
Name Username
—————————
SharedAppPool Shared\SPService
SharedPubsAppPool Shared\SPService
.NET Reflector – Decompiled Code
[Guid("B8369089-08AD-4978-B1CB-C597B5E90F64"), SharePointPermission(SecurityAction.InheritanceDemand, ObjectModel=true), SharePointPermission(SecurityAction.LinkDemand, ObjectModel=true)]
public class SPApplicationPool : SPProcessIdentity
{
// Methods
public SPApplicationPool();
public SPApplicationPool(string name, SPWebService service);
protected internal virtual void OnPasswordChange(SPManagedAccount.EventType eventType);
public override void Provision();
internal void ProvisionInternal(SecureString sstrPassword);
internal void Recycle();
public override void Unprovision();
public void UnprovisionGlobally();
public override void Update();
public virtual void UpdateCredentials(string formerUsername);
}
[Guid("F9338406-BA5D-456B-8502-E9E195DDC328"), SharePointPermission(SecurityAction.LinkDemand, ObjectModel=true), SharePointPermission(SecurityAction.InheritanceDemand, ObjectModel=true)]
public sealed class SPIisWebServiceApplicationPool : SPPersistedObject
{
// Fields
private const string DefaultSystemApplicationPoolName = “SharePoint Web Services System”;
private bool m_IdentityChanged;
[Persisted]
private IdentityType m_IdentityType;
[Persisted]
private SPManagedAccount m_ManagedAccount;
[Persisted]
private SPIisWebServiceApplicationPoolOptions m_Options;
private static readonly object s_SynchronizationLock;
// Methods
static SPIisWebServiceApplicationPool();
public SPIisWebServiceApplicationPool();
private SPIisWebServiceApplicationPool(string name, SPIisWebServiceSettings parent, IdentityType identityType, SPManagedAccount managedAccount, SPIisWebServiceApplicationPoolOptions options);
internal void BeginProvision(SPIisWebServiceApplicationPoolProvisioningOptions options);
internal static SPIisWebServiceApplicationPool Create(SPFarm farm, string name, SPProcessAccount processAccount);
private static SPIisWebServiceApplicationPool Create(SPFarm farm, string name, SPProcessAccount processAccount, SPIisWebServiceApplicationPoolOptions options);
internal static SPIisWebServiceApplicationPool EnsureSecurityTokenServiceDefault();
internal static SPIisWebServiceApplicationPool EnsureSystemDefault();
internal static SPIisWebServiceApplicationPool GetInstance(SPFarm farm, string name);
public SecurityIdentifier GetSecurityIdentifier();
internal void ProvisionLocal();
internal void ProvisionLocal(SPIisWebServiceApplicationPoolProvisioningOptions options);
private void RaiseProcessIdentityChangedEvent();
internal void UnprovisionLocal();
public override void Update();
internal void UpdateDependentApplications();
public static SPIisWebServiceApplicationPool UpgradeFromProcessIdentity(SPProcessIdentity processIdentity, string name);
// Properties
internal IdentityType CurrentIdentityType { get; }
internal string IisObjectName { get; }
internal SPManagedAccount ManagedAccount { get; }
public string Name { get; }
public SPProcessAccount ProcessAccount { get; set; }
// Nested Types
[Flags]
private enum SPIisWebServiceApplicationPoolOptions
{
None,
UseObjectNameAsIisObjectName
}
}
SharePoint 2010 and the Site Directory
You may have noticed that Central Administration offers you a screen to configure a master Site Directory in SharePoint 2010, but it does not give you the ability to create a site based off of this template through the UI. It appears that this functionality has been removed and is only available under the covers to support SharePoint 2007 upgrades that had this template included.

Once again…. PowerShell comes to the rescue. You can create a Site Directory using the following code snippet.
#———————————————————————————–
# Set the variables
$siteURL = “http://lab.ps4sp.com/sites/directory”
$owner = “PS4SPShannon”
$secondOwner = “PS4SPAdministrator”
$template = “SPSSITES#0″
$description = “This site directory was built using PowerShell.”
$name = “Site Directory”
# Create the Site Directory
New-SPSite $siteURL -OwnerAlias $owner -SecondaryOwnerAlias $secondOwner -name $name -Template $template -Description $description
#———————————————————————————–
Once you have your site directory created, you can then use PowerShell to configure your master Site Directory with the following code snippet.
#———————————————————————————–
# Set Site URL
$siteURL = “http://lab.ps4sp.com/sites/directory”
# Site Directory Requirements can be one of the following:
# SiteDirectoryCatsOptional, OneSiteDirectoryCatMandatory, or AllSiteDirectoryCatMandatory
$requirements = “AllSiteDirectoryCatMandatory”
#Enforce Listings?
$enforce = $true
# Need to get site and web IDs
$site = get-SPSite $siteURL
$web = get-SPWeb $siteURL
# Get the farm
$farm = get-SPFarm
# Get the Site Directory fromn the Portal Service
$ps = $farm.Services | where {$_.GetType().Name -eq “PortalService”}
$ps.MasterSiteDirectoryLocation = $siteURL
$ps.MasterSiteDirectorySiteId = $site.ID
$ps.MasterSiteDirectoryWebId = $web.ID
$ps.EnforceNewListingForSites = $enforce
$ps.SiteDirectoryEntryRequirements = $requirements
$ps.Update()
$site.Dispose()
$web.Dispose()
#———————————————————————————–
Configuring Content Deployment Settings
SharePoint 2010 provides many new cmdlets that let you interact and configure content deployment settings. These new cmdlets include the following:
- New-SPContentDeploymentJob
- Start-SPContentDeploymentJob
- Get-SPContentDeploymentPath
- Set-SPContentDeploymentPath
- Remove-SPContentDeploymentPath
- Set-SPContentDeploymentJob
- Get-SPContentDeploymentJob
- Remove-SPContentDeploymentJob
You can read up on content deployment and these cmdlet here. The cmdlet that you will find are related to Content Deployment Paths and Jobs. While these work very well and are easy to use, they are only part of the story. To fully configure Content Deployment, you need to set the ‘Accept Content Deployment Jobs’. SharePoint does not give you a cmdlet for these properties.

The code snippet below provides settings for content deployment within the same farm. If you wish to deploy content to another SharePoint farm, modify the ExportWebServer property below.
# Set the variables
$acceptJobs = $true
$secureConnection = $false
$tempFolder = “C:ProgramDataContentDeployment”
$ImportWebServer = “PS-SPS”
$exportWebServer = “PS-SPS”
$reportsPerJob = 20
$pollingInterval = 10
$fileMaxSize = 10
$blockMultiple = $true
# Get an instance of the ContentDeploymentConfiguration object and set the properties
$cs =[Microsoft.SharePoint.Publishing.Administration.ContentDeploymentConfiguration]::GetInstance()
$cs.AcceptIncomingJobs = $acceptJobs
$cs.RequiresSecureConnection = $secureConnection
$cs.TemporaryFolder = $tempFolder
$cs.ImportWebServer = $importWebServer
$cs.ExportWebServer = $exportWebServer
$cs.DefaultReportsPerJob = $reportsPerJob
$cs.RemotePollingINterval = $pllingInterval
$cs.FileMaxSize = $fileMaxSize
$cs.BlockMultipleJobsPerPath = $blockMultiple
$cs.Update()

