Add-PSSnapin microsoft.sharepoint.powershell

$SizeLog = "D:\temp\SPSiteSize.csv"

############################################################

$CurrentDate = Get-Date -format d

$WebApps = Get-SPWebApplication

foreach($WebApp in $WebApps)

{

$Sites = Get-SPSite -WebApplication $WebApp -Limit All

foreach($Site in $Sites)

{

$SizeInKB = $Site.Usage.Storage

$SizeInGB = $SizeInKB/1024/1024/1024

$SizeInGB = [math]::Round($SizeInGB,2)

$CSVOutput = $Site.RootWeb.Title + "*" + $Site.URL + "*" + $Site.ContentDatabase.Name + "*" + $SizeInGB + "*" + $CurrentDate

$CSVOutput | Out-File $SizeLog -Append

}

}

$Site.Dispose()

#Identify the account to change
$Account = "contoso\svcSPExcel"
$ManagedAccount = Get-SPManagedAccount $Account

#Generate the Random Password
$rand = New-Object System.Random
#Generate a new 20 character password
$pwd = ""
1..20 | ForEach { $pwd = $pwd + [char]$rand.next(33,127) }

#Set the Password as a secure string
$securePassword = ConvertTo-SecureString -String $pwd -AsPlainText -Force

#Log the Change prior to the change
$Text = "SharePoint Managed Account Password Changed for: " + $Account + " to " + $pwd
Add-Content c:\temp\PasswordChanges.log $Text
#Reset the Password
Set-SPManagedAccount -Identity $ManagedAccount –Password $securePassword -Confirm:$false
#Repeat lines 1-18 for each managed account you want to change.

As for the script used to provision search, see this post.

Add-PSSnapin Microsoft.SharePoint.PowerShell

#Setup Site String Variables

$Site = "http://intranet.contoso.com/sites/Proj/"

$SiteName = "Project1"

$site1 = $site + $SiteName

#Specify the site to redirect to

$Site1Redirect = "http://intranet.contoso.com/PM/Projects/Project1"

#create the old site in the new environment to redirect from

new-spweb -url $site1 -Template "CMSPublishing#0" -Name $SiteName

#Create Redirect Page

$s1 = get-spweb $site1

#Finds the appropriate page layout

$pubWeb = [Microsoft.SharePoint.Publishing.PublishingWeb]::GetPublishingWeb($s1)

$pl = $pubWeb.GetAvailablePageLayouts() | Where { $_.Name -eq “redirectpagelayout.aspx”}

#Create New Page

$newPage = $pubWeb.AddPublishingPage("Redirect.aspx", $pl) #filename need end with .aspx extension

$newPage.Update()

#Get the docs from the Pages library and store in variable

$list = $s1.lists["Pages"]

$items = $list.items

#Go through all items and update the redirect page to point to the proper

foreach($item in $items)

{

#If the "Name" column value equals "Redirect.aspx"

if($item["Name"] -eq "Redirect.aspx")

{

#Change the value of the "Redirect URL" column

$item["Redirect URL"] = $Site1Redirect

#Update the item

$item.Update()

}

}

#Check the file in and publish it

$newPage.CheckIn(“Created by PowerShell”);

$newPage.ListItem.File.Publish("")

#Configure Redirect Page as Home Page for each site

$HomeDL = $s1.RootFolder

$HomeDL.WelcomePage = "Pages/Redirect.aspx"

$HomeDL.update()

This particular code is designed for a standard 3 tier farm
that has an Application, Web and Database server.  The idea of the code is to put most of the
Search roles on the Application server. 
The roles going on the Web server are related to the Query Role and
Index. 

Script:

#Setup Variables - Assume 2 Servers (App & Web)

#Assume 3 Accounts (Content Access, Admin, Query)

#### Note - You should setup the Index Location prior to
running these commands and ensure it is an empty folder

#### Note - If you setup diag logging prior to running
script, ensure you give dbo permissions to the account you run this under

write-host 0. Setting up some initial variables.

$AppSvr = "SPApp2013"

$WebSvr = "SPWeb2013"

$CAAcct = "campbushnell\svcSPSearchCA"

$password = "ZAQ!2wsx"

$CAAcctPW = ConvertTo-SecureString -String $password
-AsPlainText -Force

$AdminAcct = "campbushnell\svcSPSearchA"

$QueryAcct = "campbushnell\svcSPSearchQ"

$SSAName = "EnterpriseSearch"

$SSIAppSvr = get-SPServiceInstance -server $AppSvr |
?{$_.TypeName -eq "SharePoint Server Search"}

$SSIWebSvr = get-SPServiceInstance -server $WebSvr |
?{$_.TypeName -eq "SharePoint Server Search"}

$IndexLocation = "C:\SPIndexLocation"

$err = $null

#Start Services for SSI

write-host 1. Start Services search services for Each Server

Start-SPEnterpriseSearchServiceInstance -Identity $SSIAppSvr

Start-SPEnterpriseSearchServiceInstance -Identity $SSIWebSvr

#Create Application Pools

write-host 2. Create a Application Pools

$AdminAppPool = new-SPServiceApplicationPool -name
$SSAName"-AdminAppPool" -account $AdminAcct 

$QueryAppPool = new-SPServiceApplicationPool -name
$SSAName"-QueryAppPool" -account $QueryAcct

#Create Search Service Application

write-host 3. Create the SearchApplication and set it to a
variable

$SearchApp = New-SPEnterpriseSearchServiceApplication -Name
$SSAName -applicationpool $AdminAppPool -databasename
$SSAName"_AdminDB"

#Create Search Service Application Proxy

write-host 4. Create search service application proxy

$SSAProxy = new-spenterprisesearchserviceapplicationproxy
-name $SSAName"ApplicationProxy" -SearchApplication $SearchApp

#Clone Search Topology (this is empty by default)

write-host 5. Clone Search Topology

$SearchTopology = $SearchApp.ActiveTopology.Clone()

#Provision Search Administration Component

write-host 6. Provision Search Admin Component.

New-SPEnterpriseSearchAdminComponent -SearchServiceInstance
$SSIAppSvr -SearchTopology $SearchTopology

#Provision New Search Content Processing Component

write-host 7. Create New Search Content Processing Component

New-SPEnterpriseSearchContentProcessingComponent
-SearchServiceInstance $SSIAppSvr -SearchTopology $SearchTopology

#Provision New Search Analytics Processing Component

write-host 8. Create New Search Analytics Processing
Component

New-SPEnterpriseSearchAnalyticsProcessingComponent
-SearchServiceInstance $SSIAppSvr -SearchTopology $SearchTopology

#Provision New Search Crawl Component

write-host 9. Create New Search Crawl Component

New-SPEnterpriseSearchCrawlComponent -SearchServiceInstance
$SSIAppSvr -SearchTopology $SearchTopology

#Provision New Search Index Component

write-host 10. Create New Search Index Component

New-SPEnterpriseSearchIndexComponent -SearchServiceInstance
$SSIWebSvr -SearchTopology $SearchTopology -RootDirectory $IndexLocation

#Provison New Query Processing Component

write-host 11. Create New Query Processing Component

New-SPEnterpriseSearchQueryProcessingComponent
-SearchServiceInstance $SSIWebSvr -SearchTopology $SearchTopology

#Activate Topology Changes

write-host 12. Activate Topology

$SearchTopology.Activate()

#Setup default Content Access Account

write-host 13. Set the default content access account

Set-SPEnterpriseSearchServiceApplication –Identity
$SearchApp -ApplicationPool $QueryAppPool -DefaultContentAccessAccountName
$CAAcct -DefaultContentAccessAccountPassword $CAAcctPW

Write-host "Your search application $SSAName is now
ready"

One last note with this script, it is designed for smaller
farms and if a large search farm is being created more configuration will be
required to ensure you get the performance you are looking for.

To setup the DNS forward lookup zone and wildcard CNAME alias I followed the TechNet article I already referenced but in case you are following this post instead of that I’ll quickly rehash it.  First, open DNS then right click Forward Lookup Zone and click New Zone.  When going through the wizard click Next to start it then select Primary Zone and click Next.  Then choose if it is at the Forest or the Domain, in my case it doesn’t matter so I chose Domain and then click Next.  Next you will provide a name for your zone (CampBushnellApps.lcl – This will become the $AppDomain variable in the script below).  Once that’s done I use the defaults through the rest of the wizard and click Finish to create. 

Now I can create the wildcard CNAME alias.  To do so I select the newly created forward lookup zone and right click and select new Alias (CNAME).  In the New Resource Record window I type * for the Alias Name and the WFE FQDN for the FQDN field (in this case SPWeb2013.campbushnell.lcl).  If I wanted to use a load balanced URL (DNS A Record) instead I could do that instead of pointing directly at the WFE.  This can work great for abstracting the server name or in the case that I have multiple WFEs.   

Now that the DNS side of the house is configured, I run my script…  (The first section of the scripts I write I always setup my variables for use in the script which is great for multiple farms)

#Create Variables

write-host 0. Setup Variables

$AMAcct = Get-SPManagedAccount "campbushnell\svcSPApps" #App Management Service Account

$SSAcct = Get-SPManagedAccount "campbushnell\svcSPSubscript" #Subscription Settings Service Account

$SubServiceName = "Subscription Settings Service"

$AppServiceName = "App Management Service"

$SubDBName = "SubscriptionSettingsServiceDB"

$AppDBName = "AppServiceDB"

$AppSvr = "SPApp2013"

$AppDomain = "CampBushnellApps.lcl"

$AppPrefix = "apps"

#Start the Subscription Settings Service and App Management Service

write-host 1. Subscription Settings Service and App Management Service

$SubServiceInstance = get-SPServiceInstance -server $AppSvr | ?{$_.TypeName -eq "Microsoft SharePoint Foundation Subscription Settings Service"}

Start-SPServiceInstance -Identity $SubServiceInstance

$AppServiceInstance = get-SPServiceInstance -server $AppSvr | ?{$_.TypeName -eq "App Management Service"}

Start-SPServiceInstance -Identity $AppServiceInstance

#Create Subscription Settings Service App Pool

write-host 2. Configure Subscription Settings Service App Pool

$appPoolSubSvc = New-SPServiceApplicationPool -Name $SubServiceName-"AppPool" -Account $SSAcct

#Create Subscription Settings Service App

write-host 3. Configure Subscription Settings Service App

$appSubSvc = New-SPSubscriptionSettingsServiceApplication –ApplicationPool $appPoolSubSvc –Name $SubServiceName –DatabaseName $SubDBName

#Create Subscription Settings Service App Proxy

write-host 4. Configure Subscription Settings Service App Proxy

$proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy –ServiceApplication $appSubSvc

#Create App Management Service App Pool

write-host 5. Configure App Management Service App Pool

$appPoolAppSvc = New-SPServiceApplicationPool -Name $AppServiceName-"AppPool" -Account $AMAcct

#Create App Management Service App

write-host 6. Configure App Management Service App

$appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolAppSvc -Name $AppServiceName -DatabaseName $AppDBName

#Create App Management Service App Proxy

write-host 7. Configure App Management Service App Proxy

$proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc

#Configure App URLs

write-host 8. Configure App URLs

Set-SPAppDomain $AppDomain

Set-SPAppSiteSubscriptionName -Name $AppPrefix -Confirm:$false

On occasion I have had step 8 of my script fail because SharePoint is still provisioning the service application and cannot setup the URLs.  In those cases I simply manually setup the required variables and rerun the two lines of code for step 8.  Once that is created I should be able to open Central Admin and access the Apps section.  In this area I am going to verify my App Domain and App Prefix are set to my variables by selecting Configure App URLs. 

After I have verified that I go configure my App Catalog for the web application by selecting Manage App Catalog.  Because it is new I have to create one for the web application.  The process is much like creating a new site collection. 

After that there is one more step to take to allow my web application to access apps from the SharePoint store, I need to activate the Apps that require accessible internet facing endpoints feature.  To do so I browse to Application Management à Manage Web Applications à select my web application and select Manage Features in the ribbon.  Then I activate the feature.

At this point I am able to add apps from the SharePoint store to a SharePoint page!!!  But when I go and test the app on the page it bombs with “page cannot be displayed” error messages in the web part!  What gives!?!  Well after some Fiddler traces I found 404 errors.

As it turns out the default website is picking up the app and trying to respond for it rather than redirecting to a SharePoint web application.  First I attempted to fix this by disabling the default web site in IIS on my WFE.  Not the fix so I re-enabled it (not because it is doing anything but because I like to keep things as close to out of the box as I can, especially for testing purposes).  So instead I change the binding on my web application to pick up anything on port 80 (which is what my site is using).  When I test again I get prompted for credentials so I put them in and continue to get prompted.  

What is with the prompting for credentials?  I quickly test again and this time my Fiddler trace shows me 401 errors.  First I wonder if it is a loopback issue so I disabled loopback and after my first prompt it accepts my credentials and my app works! 

To disable loopback if you aren’t familiar, open the registry and go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA and create a new DWORD (32-bit) Value with a name of DisableLoopbackCheck and set the value to 1.  Restart the server after the change to ensure it takes effect.  Reference article KB 896861

But I know that prompting credentials on page load isn’t going to fly in the real world so how can I fix it?  Well, to be honest it so simple I almost didn’t try it… all I did was add the App Domain (*.CampBushnell.lcl) to my trusted sites and configured trusted sites to pass credentials.  (I would recommend that be part of a group policy rather than setup on individual computers)  I did take the Loopback out again and found that it still kept prompting for credentials so it definitely is part of the fix here.

As an aside in case you are using Kerberos with your web application… I spent several hours working through issues with this while using a Kerberos web application and found consistent prompting that neither of the above solutions resolved.  In fact, the only way I have found around it so far for a web application using Kerberos is to setup a separate web application that is NTLM and setup the IIS binding to it rather than the Kerberos based web application.  I still needed to trust the domain and forward credentials but after I did that the prompting issue stopped.  

First, I will assume that SharePoint 2013 is installed and for the purposes of my test environment I have set a domain controller, a SQL 2012 server, and two SharePoint 2013 servers (Application and Web). 

So the first step I will suggest taking is to install SQL 2012 SP1 on the SQL server as well as the patch from KB 2793634.  Without doing this step SharePoint will not show the SQL Reporting Services Service Application when you try to create it in Central Admin and it will not initialize the service in SharePoint.  If you have already run into that step because you installed SSRS on SharePoint first, don’t worry; install SP1 for SQL 2012 and the patch on the SQL server and on your SharePoint servers (Yes, I did say your SharePoint servers – When you put SSRS in your farm they have SQL bits on them).

Once you have installed the patches I typically install SSRS on my SharePoint servers next.  In the case of this small three server farm the Application server (SPApp2013) will become the server where I plan to run the SSRS engine but the Web server (SPWeb2013) will also get the SSRS add-in installed on it.  If I was running more servers in the farm I would need to install the add-in there as well and if I was wanting to have a load balanced SSRS service application I would install the SSRS engine on another server as well.  When installing SSRS engine from the SQL Server 2012 media (my preferred method) select the following features:

• Reporting Services – SharePoint
• Reporting Services Add-in for SharePoint Products
• Management Tools – Basic & Complete

These three are the for the application server.  Again, for the web server you only need the middle bullet above (Reporting Services Add-in).  Once SSRS is installed and patched on your servers you should see the option in Central Admin to setup the service application.  If you don’t see this option open the SharePoint Management Shell and run the following:

• Install-SPRSService
• Install-SPRSServiceProxy
• get-spserviceinstance -all |where {$_.TypeName -like "SQL Server Reporting*"} | Start-SPServiceInstance

Then try to create the service application again.  From there the service application creates like any other service application, however; because I haven’t mentioned it yet, another assumption I had is that each service application has its own application pool and own service account associated with it.  Once it is a security best practice but will also be important for constrained delegation.  In the case of this environment I used the following service accounts for service applications:

I haven’t touched Claims to Windows Token Service yet, but it is coming, and yes, required.  Once I have the service application up and running I like to go make sure my service is started on the application server.  To do this go to System Settings à Manage Services on Server.  If it isn’t started, start it on the application server.  Next I need to go change the authentication method it will use from NTLM to Kerberos so we can use pass through authentication (otherwise known as the double hop issue).  To do this I need to make changes to RSReportServer.config file.

• File is located in C:\Program Files\common files\Microsoft Shared\Web Server Extentions\15\Web Services\Reporting
• Change AuthenticationTypes  from RSWindowsNTLM to RSWindowsNegotiate
• Save the file
• IIS Reset on all servers

So the last step for SSRS (and should be done for the Excel and PerformancePoint as well) is to give the service account permissions to the databases in the web applications.  I also need to give permissions to other locations such as SSAS cubes or SQL databases you will be accessing, but that’s a bit out of scope for this discussion.  Run the following to give the permissions:

• $w = Get-SPWebApplication -Identity http://dragonlair              
• $w.GrantAccessToProcessIdentity("campbushnell\svcSQLSSRS")

So now that SSRS is done I can move on to Claims to Windows Token Service (C2WTS).  There are a couple things to do before getting started… Permissions and local security policy (so if I have a group policy in place that overrides what is changed it can cause issues – SharePoint is “special” so I typically try to set it up without a group policy and then enforce/lock down after).  On SPApp2013 I add the C2WTS to the local administrators group where PerformancePoint is running and grant the account the following permissions in the local security policy:

• Act as part of the operating system
• Impersonate a client after authentication
• Log on as a service

Next I need to add the WPS_WPG Windows Group to the c2wtshost.exe.config file.  The file is located \Program Files\Windows Identity Foundation\v3.5\c2wtshost.exe.config

Once I do that I go to the services running in Windows and set the Claims to Windows Token Service to Automatic.  Don’t start it here because SharePoint will just stop it as SharePoint services are really controlled from timer jobs and the settings in the configuration database.   Instead, I navigate to Manger Services on Server in Central Admin and start the service on SPApp2013.  Once it is started an IIS reset or server reboot is required. 

Next I move on to the Service Principle Names (SPNs) and Delegations.  Because I want to pass credentials through SharePoint/SSRS to the data source I need to make the web application Kerberos as well.  Before I make the change in SharePoint I need to have the SPNs and Delegations in place or the web application will not allow access.  Earlier I mapped out the Services I need to setup Kerberos for and the service accounts I will use.  The syntax for the SPNs (2008 or greater domain controllers) is:  SetSPN –S ServiceClass/Host:Port Domain\ServiceAccount.  So for this environment I setup (don’t forget to also do FQDN):

• Setspn -S HTTP/dragonlair Campbushnell\svcSPWADragon
• Setspn -S HTTP/dragonlair.campbushnell.lcl Campbushnell\svcSPWADragon
• Setspn -S MSSQLSvc/SQL2012:1433 Campbushnell\svcSQLEng
• Setspn -S MSSQLSvc/SQL2012.campbushnell.lcl:1433 Campbushnell\svcSQLEng
• Setspn -S MSSQLSvc/SPSQL:1433 Campbushnell\svcSQLEng
• Setspn -S MSSQLSvc/SPSQL.campbushnell.lcl:1433 Campbushnell\svcSQLEng
• Setspn -S SP/C2WTS Campbushnell\svc_SPC2WTS
• Setspn -S SP/SSRS Campbushnell\svcSQLSSRS
• Setspn -S SP/PPS Campbushnell\svcSPPerfPnt
• Setspn -S SP/Excel Campbushnell\svcSPExcel

Once the SPNs are in place I can access the delegations tab for the service accounts.  I generally like to map it out first so it looks like:

Notice there is a lack of OLAP or other database server in this example.  In non-test environments often connecting to an OLAP cube or other database server is done.  For those instances I just add the appropriate SPNs and add the applicable delegations.  In Active Directory the delegations look as like the picture for all the service accounts listed in the table above. 

After Kerberos is setup from the Active Directory side I have to setup the web application to use Kerberos rather than NTLM.  To do so I navigate to Manage Web Applications in Central Admin, select the web application then Authentication Providers from the ribbon.  The dialog to choose the zone appears and I select default.  Then scroll down to Claims Authentication Types and change the Integrated Windows Authentication to Negotiate (Kerberos).  IIS Reset is always a good step on all SharePoint servers at this point.  Then I test to ensure I can still get into my web application.  If not, I did something incorrect with Kerberos and need to troubleshoot it. 

Once all of that is done I can start my testing to ensure SSRS can pass my credentials to the database server and bring a report back and render it to me as a user.  The first step to that is ensuring I have read access to the database.  I change that at the SQL Server database that I am trying to access in this case but that will be more defined in real world scenarios.  After that I will start Report Builder (for testing purposes I do that on SPApp2013) to create a SSRS report and data source which I will upload into a document library in SharePoint.  Below shows the location of report builder in case you are testing the same way. 

Once I create the report I save it to a SharePoint document library where the Report Server Integration feature is enabled.  Typically I don’t open the report to test if Kerberos is passing credentials, but that is a way as long as you are sure the report works properly.  I usually go into the data source (Manage Data Sources) for the report and click Test connection.  If it comes back with a Test Successful message I am good and the report should work without an issue.