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.

Click here to see the complete report.

Chapter 20: Multi-Tenancy (Written by Gary)

Cross-Farm Services

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!!!

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)

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.

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

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.InputClaimType

  New-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

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

}

}

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()

#———————————————————————————–

• 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()