Add-PsSnapin Microsoft.SharePoint.PowerShell

Get-SPWebApplication | Get-SPSite -limit all  | foreach {
    $FilePath = \\">\\">\\<ServerName>\<ShareName>\;
    $ext = $_.Url.Replace("http://", "").Replace("https://", "").Replace("/","-").Replace(":","-") +".bak";
    write-host $ext
    Backup-SPSite -Identity $_.Url -Path $FilePath$ext -Force
}

Check out Todd’s blog, he has a lot of good info, including similar script to backup webs.

We ended up modifying 3 different parameters:

• ImportConnAsyncTimeout
• FIMWebClientTimeOut
• LdapConnectionTimeout

Don’t quote me on this, but this is my understanding of what each of the three values control:

ImportConnAsynctimeout: This timeout is when you click the Populate button on the editdsserver.aspx page, and SharePoint enumerates the domains/OU’s and then presents them on the page.  the default time out value is 30 seconds.

FIMWebClientTimeOut: After selecting what you plan to sync, and clicking the OK button on the editdsserver.aspx page, SharePoint then goes into the FIM service and create/edits the management agent.  The default timeout for this is ~16.6 minutes, due to large OU structures and the amount of data that is collected.

LdapConnectionTimeout: This is the timeout for the actual Directory Connection, the default for this is 30 seconds.

Below I’ve provided the powershell commands utilized to actually modify the parameters:

ImportConnAsyncTimeout:

$upaAppProxy = Get-SPServiceApplicationProxy | ? {$_.name -like ‘User Profile Service Proxy’}

$upaAppProxy.ImportConnAsyncTimeout = 60 //This value is in seconds

$upaAppProxy.Update()

FIMWebClientTimeOut:

$upaApp = Get-SPServiceApplication | ? {$_.name -like ‘User Profile Service’}

$upaApp. FIMWebClientTimeOut = 300000 //This value is in milliseconds

$upaApp.Update()

LdapConnectionTimeout:

$upaAppProxy = Get-SPServiceApplicationProxy | ? {$_.name -like ‘User Profile Service Proxy’}

$upaAppProxy.LdapConnectionTimeout = 60 //This value is in seconds

$upaAppProxy.Update()

Like many others, I’ve run into countless problems getting the profile sync service to function properly.  This is a high level overview of what I’ve found that worked, and was repeatable.

SQL Server

• Install SQL 2008 R2 on SQL Server
  • Database Engine Services
    • Full-Text Search
  • Analysis Services
  • Management Tools – Basic
    • Management Tools – Complete
  • SQL Client Connectivity SDK

• Set appropriate Permissions:
  • Log on as a service – SQL Service Accounts
  • Access this computer from the network – SQL Service Accounts
  • SQL Permissions for Setup User Account
    • Security Admin
    • Dbcreator

SharePoint Server

• Fully Patch Server (OS Only) via Windows Update
• Set appropriate Permissions:
  • Access this computer from the network – Authenticated Users
  • Local Administrators Group – Setup User Account, and Farm Service Account
  • Log on as a service – SharePoint Farm Service Account

• Install SharePoint 2010 PreReq’s
• Run the MoveIIS7Root script (http://www.thesanitypoint.com/archive/2010/06/29/sharepoint-2010-and-the-c-drive.aspx)
• Install KB976127 (ADO.NET Data Services Update for .NET Framework 3.5 SP1 for Windows 2008 R2)
• Install KB976462 if applicable
• Install SharePoint 2010
• Run the "SharePoint Products Configuration Wizard" (while logged into the SharePoint server with the Setup User Account)
  • When Prompted for an account to connect to SQL with, this is the FARM service account, not the Setup User Account

• Create necessary SharePoint accounts (in SharePoint) will need the access this computer from the network local security policy
  • Application Pool Root
  • Application Pool MYSP
  • Content Access Account
  • Shared Services 1
  • Profile Sync

• Create the root Web Application sp2010.mydomain.com:10000 or whatever
  • Create the root site collection
  • Modify IIS binding to listen on specific IPv4 Address
    • 1 – Hostheader – IP – randomport
    • 2 – hostheader – IP – Port 443
  • Modify Alternate Access Mapping
    • Default – Port 433
    • Custom – Random Port

• Start the ‘User Profile Service’
• Create MySite Host Web Application/root site collection (My Site Host)
  • Create a ‘Managed Path’ named ‘Personal’ on the MySite host Web Application
  • Create MySite Host as root site collection
  • Modify IIS binding to listen on specific IPv4 Address
    • 1 – Hostheader – IP – randomport
    • 2 – hostheader – IP – Port 443
  • Modify Alternate Access Mapping
    • Default – Port 443
    • Custom – Random Port

• Start "Managed Metadata Service" on one of the SharePoint Farm servers.
• Create new Managed Metadata Service
• Create User Profile Service Application
  • Use the Profile Sync account for the associated application pool

• Start ‘User Profile Synchronization Service" from the Services on Server list
  • Monitor the Timer Job Status for ‘ProfileSynchronizationSetupJob’ this is one of most likely steps that will FAIL, if it takes longer than 30-45 seconds to run the job, chances are it is working. Wait till this is complete before proceeding.
    • Once the timer job disappears verify that the ‘User Profile Synchronization Service’ is now started.
  • Once finished do an iisreset /noforce

• Create a new ‘Profile Synchronization Connection’
  • If you cannot access the ‘Manage Profile Service’ applet, try rebooting, sometimes the FIM services don’t respond properly after starting the ‘User Profile Synchronization Service’.
  • Use the Profile Sync account when creating the profile synchronization connection
  • The Profile Sync account will require ‘Replicate Directory Changes’ at the root of the domain.

Run a profile Sync to verify profile sync is working (can take several hours)

• To monitor the progress, and assist trouble shooting any sync issues at this point you can use the miisclient located at <Install Directory>\Microsoft Office Servers\14.0\Synchronization Service\UIShell\

If everything is working at this point, you can proceed with building out the rest of the farm.

• Configure alternate access mappings/IIS 443 settings for Central Admin, the Root Web App, and the MYSP Web App.

Step by Step Profile Sync info:

http://technet.microsoft.com/en-us/library/ee721049.aspx

The following blogs were extremely helpful in getting the Profile Sync service functional. I’d like to thank both Jie Li, and Francois Pienaar for posting.

http://blogs.msdn.com/b/opal/archive/2009/11/19/user-profile-sync-setup-in-sharepoint-server-2010-beta.aspx

http://technicallead.wordpress.com/2010/03/08/user-profile-sync-setup-in-sharepoint-2010-beta/

Below I’ve outlined at a minimum what is required to setup Kerberos authentication for SharePoint 2010.  Ensure you replace everything surrounded by <> with the appropriate variable. With any luck I didn’t miss anything.

CORE

1. Configure DNS for each Load Balanced Web Application
2. Configure each Web Application to run under a unique Application Pool Identity.
3. Set the appropriate SPN’s on the service accounts as so:
   1. SetSPN -S HTTP/<NSN>:<Port> <Domain\FSA>
   2. SetSPN -S HTTP/<NSN>:<Port> <DOMAIN\FSA>
   3. SetSPN -S HTTP/<URL1NBN> <DOMAIN\AppPl1A>
   4. SetSPN -S HTTP/<URL1> <DOMAIN\AppPl1A>
   5. SetSPN -S HTTP/<URL1>:<Port> <DOMAIN\AppPl1A>
   6. SetSPN -S HTTP/<URL2NBN> <DOMAIN\AppPl2A>
   7. SetSPN -S HTTP/<URL2> <DOMAIN\AppPl2A>
   8. SetSPN -S HTTP/<URL2>:<Port> <DOMAIN\AppPl2A>

SQL Server (DB)

1. SetSPN -S MSSQLSVC/<SQLSrvNBN>:<Port> <DOMAIN\SQLSvc>
2. SetSPN -S MSSQLSVC/<SQLSrv>:<Port> <DOMAIN\SQLSvc>

SQL Analysis Services

1. SetSPN -S MSOLAPSvc.3/<SQLSrvNBN> <DOMAIN\SQLASSvc>
2. SetSPN -S MSOLAPSvc.3/<SQLSrv> <DOMAIN\SQLASSvc>

SQL Reporting Services

1. SetSPN -S HTTP/<SQLRptSrvNBN> <DOMAIN\SQLRSSvc>
2. SetSPN -S HTTP/<SQLRptSrv> <DOMAIN\SQLRSSvc>

Trust for Delegation

Configure Trust for Delegation for the service accounts and computer objects for all servers, and service accounts that you’ve set service principal names for.

IIS Config (Borrowed from Saurabh Sing)

In IIS 7/7.5 you have to also modify the applicationhost.config file (found at %systemroot%\system32\inetsrv\config\) to enable Kernel mode authentication, and to enable the application pool’s Identity, by adding the following: “useKernelMode="true" useAppPoolCredentials="true"” to the security portion of the applicationhost.config file as so:

<system.webServer>

   <security>

      <authentication>

         <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" />

      </authentication>

   </security>

</system.webServer>

Configure SRS to answer via SSL

modify the rsreportserver.config with the following:

<Add Key="SecureConnectionLevel" Value="2"/>

<UrlRoot>https://<FQDNofReportServerCertificate>/ReportServer</UrlRoot>

<ReportServerUrl>https://<FQDNofReportServer>/ReportServer</ReportServerUrl>

http://blogs.msdn.com/b/mariae/archive/2007/12/12/ssl-configuration-and-reporting-services.aspx

Configure SRS to use Kerberos

Ensure the following exists in the rsreportserver.config file:

<Authentication>

<AuthenticationTypes>

<RSWindowsNegotiate />

<RSWindowsKerberos />

<RSWindowsNTLM />

</AuthenticationTypes>

<RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel>

<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>

<EnableAuthPersistence>true</EnableAuthPersistence>

</Authentication>

http://msdn.microsoft.com/en-us/library/cc281253.aspx

SharePoint: Trusting non Public Certificate Authority

I had to do the following to get SharePoint to connect to SQL Reporting Services via SSL when using an untrusted Certificate Authority.  Keep in mind, just because the server trusts the authority, SharePoint DOES NOT!

Add-PSSnapin Microsoft.SharePoint.PowerShell

$rootca = New-Object System.Security.Cryptography.x509Certificates.x509Certificate2(“d:\Admins\Certs\CACertClass3.cer”)

New-SPTrustedRootAuthority –Name “CACert Class 3 Root” –Certificate $rootca

http://blogs.technet.com/b/blairb/archive/2010/08/18/using-ssl-with-sharepoint-2010-send-to-connections.aspx

Key

<NSN> = Netbios Server Name

<Port> = TCP port used for the service

<URL1NBN> NetBios name for the first Web Application

<URL1> = FQDN for the first Web Application

<URL2NBN> NetBios name for the second Web Application (such as My Sites)

<URL2> = FQDN for the second Web Application (such as My Sites)

<FSA> = Farm Service Account

<AppPl1A> = Application Pool account for Web Application 1

<AppPl2A> = Application Pool account for Web Application 2

<SQLSvc> = SQL DB Engine Service Account

<SQLASSvc> = SQL Analysis Service Account

<SQLRSSvc> = SQL Reporting Service Account

<SQLSrv> = SQL Server FQDN

<SQLSrvNBN> = SQL Server Netbios Name

<SQLRptSrv> = SQL Reporting Server FQDN

<SQLRptSrvNBN> = SQL Reporting Server NetBIOS Name

Basically what we discovered was with most stsadm commands there is an option -hostheaderwebapplicationurl, which does not exist for stsadm -addcontentdb.

After opening a ticket with Microsoft, we did the following to resolve our database sync problems.

1. stsadm -o sync deleteolddatabases 1

2. Restarted the timer service on all servers in the farm.

So anyway, if you go the other route of:

stsadm -o preparetomove

stsadm-o deltecontentdb

stsadm -o addcontentdb

And you have host based site collections residing in their own database you will have no means of reattaching them.  I spent several hours in a support call with Microsoft in the middle of the night trying to get these reattached, and ultimately had to rebuild the affected sites, and restore from backup.

#Generates a list of all site collections across all Web Applications,
#and outputing them into an array

$sitepath = New-Object System.Collections.ArrayList
$output=stsadm -o enumzoneurls
$x=[xml]$output
$x.ZoneUrls.Collection|
foreach-object -process {$y=stsadm -o enumsites -url $_.Default;$sites=[xml]$y;$sites.Sites.Site}|
foreach-object -Process {$sitepath=$sitepath + $_.Url}
$sitepath | Write-Output

#Define Output file, and labels

$filename = AllSiteUsers.csv
Write-Output “Site Collection,Title,Group,UserID,Email Address” | Out-File $filename -Append

#Loops through all site collections generating a list of Site Owners

[System.Reflection.Assembly]::LoadWithPartialName(”Microsoft.SharePoint”)
foreach ($object in $sitepath) {
$site=new-object Microsoft.SharePoint.SPSite($object)
$web=$site.Rootweb
$groups = $web.groups | ? {$_.Name -match “^.*Owners” }
foreach($group in $groups)
{
foreach($user in $group.users)
{
Write-Output “$($object),$web,$($group.Name),$user,$($user.Email)” | Out-File $filename -Append
$user
}
}}

#Converts the csv ouput to XML

Import-Csv AllSiteUsers.csv | Export-Clixml AllSiteUsers.xml

Basically all you need to do is create a batch file that calls your Powershell script and schedule the batch file.  Your batch file should contain something similar to the following:

powershell -command "& 'MyScript.ps1' "

######################################################################
#Assumptions:
#-Running on machine with WSS/MOSS
#-C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN in path
######################################################################

function get-webpage([string]$url,[System.Net.NetworkCredential]$cred=$null)
{
$wc = new-object net.webclient
if($cred -eq $null)
{
$cred = [System.Net.CredentialCache]::DefaultCredentials;
}
$wc.credentials = $cred;
return $wc.DownloadString($url);
}

#This passes in the default credentials needed.  If you need specific stuff you can use something else to
#elevate basically the permissions.  Or run this task as a user that has a Policy above all the Web Applications
#with the correct permissions
$cred = [System.Net.CredentialCache]::DefaultCredentials;
#$cred = new-object System.Net.NetworkCredential(“username”,”password”,”machinename”)

[xml]$x=stsadm -o enumzoneurls
foreach ($zone in $x.ZoneUrls.Collection) {
[xml]$sites=stsadm -o enumsites -url $zone.Default;
foreach ($site in $sites.Sites.Site) {
write-host $site.Url;
$html=get-webpage -url $site.Url -cred $cred;
}
}

The first thing we discovered is that if you use a random port when creating your Web Application you will receive the following error every time you try to create a host header site collection:

“The port specified for the new host header site does not match any known bindings in the specified Web Application.  The new site will not be accessible if the Web Application is not extended to an IIS Web Site serving this port.”

This being said the host header site collection works, but if you try to restore content to it you receive the same error.  What I found was that if you create your web application as http://site.myurl.com:443 and then change the alternate access mapping setting the default to https://site.myurl.com and intranet as http://site.myurl.com:443 you can create any number of host header based site collections error free.

Once your web application is created, creating the host header based site collection is quite simple, you just run the following:

Create Site

stsadm -o createsite -url https://hosted1.myurl.com -ownerlogin DOMAIN\username -owneremail username@myurl.com -sitetemplate STS#1 -hostheaderwebapplicationurl https://site.myurl.com

Create Site in New DB

stsadm -o createsiteinnewdb -url https://hosted1.myurl.com -ownerlogin DOMAIN\username -owneremail username@myurl.com -sitetemplate STS#1 -hostheaderwebapplicationurl https://site.myurl.com -databaseserver sqlsrv.mydomain.com -databasename WSS_Content-HHSite1

Note: you can use either -hostheaderwebapplication or -hhurl for the switch, both work, but currently (with SP1 installed) if you do a stsadm -help createsite it comes back with -hostheaderwebapplicationurl as the switch.

Once the site collection has been created, you now need to setup the SSL host header.  This is rather simple as well, you just open a command prompt and navigate to C:\inetpub\adminscripts (or wherever you’ve placed your inetpub directory) and run the following command:

adsutil.vbs set /w3svc/[identifier]/SecureBindings [IP address]:443:[host header name]

So in example above of having the web app as site.myurl.com and the hosted site as being hosted1.myurl.com. you’d run the following:

adsutil.vbs set /w3svc/123456789/SecureBindings 192.168.1.10:443:site.myurl.com 192.168.1.10:443:hosted1.myurl.com

Note: You seperate each host header with a space.

You also need to ensure that you have a wildcard cert applied to IIS vserver that will cover all Host based site collections that you’re hosting on the associated web application.

Before you can successfully backup and restore via the catastrophic backup/restore method you must ensure that your Alternate Access Mapping for the Default is set to the http://url:randomport, as seen below.

Note: This is required if you have multiple Web App’s utilizing SSL, but seems to work fine without doing this if you only have a single Web App.

Backup the IIS Metabase

Logon to the each of the WFE’s as the Farm Admin/Setup User account and run the following command to backup the IIS metabase:

iisback.vbs /backup /e <PASSWORD>

Catastrophic Farm Backup

Now we’re ready to perform the catastrophic farm backup. You can do this one of two ways, either via STSADM as so: stsadm.exe –o backup –directory <UNC Path> -backup full (example stsadm.exe –o backup –directory \\ServerName\ShareName -backupmethod full)

Or you can perform the backup via Central Admin’s Operations tab as shown below:

Insure to check ‘Farm’ which should highlight and check everything, and then click ‘Continue to Backup Options’.

Select ‘Full’, and then enter the UNC path of your backup location and click ‘OK’.

Remove SharePoint Servers from the Farm

Once the backup is completed, you are ready to remove all the servers from the farm, remove each server one at a time, removing the server that hosts Central Admin last via the ‘SharePoint Products and Technologies Configuration’ wizard.

Create a New SharePoint Farm

1. Starting with whatever server will host Central Admin, create a new farm using the ‘SharePoint Products and Technologies Configuration’ wizard. During the setup make sure you name the SharePoint Config database something different, because when you attempt to restore the entire farm, it will not allow you to overwrite and existing database. Also, choose the same port for Central Admin as you used previously for http access.

2. Add all remaining servers to the farm one at a time.

Now that all servers are in the farm, there are few steps you must complete prior to restoring the farm backup. The following services must be started on the appropriate servers, Excel Calculations Services, Office SharePoint Server Search, and Windows SharePoint Services Search.

1. Start Excel Calculations Services.

2. Start Office SharePoint Server Search, like so:

3. Now you need to start the Windows SharePoint Services Search like so:

Note: You need to use a different name for the Search Database than what was used previously.

4. You may now start any other services on which ever servers you would like, but it is not needed at this point. These three must be completed in order run the restore.

Restore From Farm Backup

You can either restore via stsadm with the following command:

stsadm.exe –o restore –directory <UNC Path> -restoremethod new

Ex: stsadm.exe –o restore –directory \\ServerName\ShareName -restoremethod new

Or if you’re restoring to a new database server/instance:

Stsadm –o restore –directory <UNC Path> -restoremethod new –newdatabaseserver <servername>

Ex: stsadm.exe –o restore –directory \\ServerName\ShareName -restoremethod new -newdatabaseserver mysqlserver.mydomain.com

You can also use Central Admin, which I highly recommend if you’re restoring to a new database server/instance, simply because you can verify every setting before continuing, as you’ll see below.

1. From the Operations tab of Central Admin, select ‘Restore from Backup’.

2. Enter the UNC path to the backup, and click ‘OK’.

3. Select the backup that you’d like to use, and then click ‘Continue Restore Process’.

4. Check ‘Farm’, which should check and highlight everything, and then click ‘Continue Restore Process’.

5. From this screen, you define the Login name and passwords for all of the Application Pools, as well as Web App URL’s, Database Server, database name, and db directory. There are three sections to this screen.

a. The fist, make sure that ‘Farm’ is selected, and that ‘New Configuration’ is selected.

b. The next section can be quite long depending on how many application pools you have. Here you need to verify the username and password for each application pool, like so.

c. Finally, you need to verify all URL’s, database server names, database names, and database file locations, and make any necessary changes.

6. Once you’re comfortable that all the information is correct click ‘OK’, and wait for the restore to complete.

Once the restore completes successfully there are a couple additional tasks you have to complete manually before your SharePoint farm will be ready for user access.

1. Set all of your Alternate Access Mappings. The restore only restores the Default mapping, so if you had any additional mappings you will have to manually add them like so:

2. Now you need to configure which IP address each IIS vserver will listen on, as well as add the necessary Cert if the site will use SSL.

3. Finally, for all sites that use SSL you will have to run the following command:

adsutil.vbs set /w3svc/[identifier]/SecureBindings “[IP Address]:443:[host header name]“

example: adsutil.vbs set /w3svc/1234567890/SecureBindings “192.168.1.10:443:wa1.mydomain.com”

At this point your farm should be completely functional.