SharePoint 2013: how to add and remove web application pools

Introduction

This posting integrates postings and comments by  Brendan Griffin and Henrik Tønnessen and consolidates my notes on this topic. It assumes that the account you will be using for the new web application pool identity is a managed account.

Add a new web application pool and assign to web application

1. Review
1. Log into a SharePoint 2013 server using the SharePoint Setup User Administrator account (eg, spAdmin). This is the same account that you (should have) used to perform the initial farm installation and configuration.

   This is important in that the changes you will be making will be to the farm configuration database; and, by default, only this account has the privileges necessary to make such changes.

2. Launch an elevated SharePoint Management shell.
3. Execute the following commands, making appropriate revisions:

   ([Microsoft.SharePoint.Administration.SPWebService]::ContentService).ApplicationPools | Sort-Object Name | Select-Object Name, ID, UserName, Status, parent | Format-Table -Auto

2. Create
1. Now, using the same management shell, execute the next few commands to create the new pool:

   $WebAppURL = "[Your site URL]"
   $NewAppPoolName = "[NameOfNewAppPool]"
   $NewAppPoolIdentity = "[IdentityOfnewAppPool]"
   $Password = Read-Host -Prompt "Enter the service account password: " -AsSecureString
   $Service = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
   $NewAppPool = New-Object Microsoft.SharePoint.Administration.SPApplicationPool($NewAppPoolName,$Service)
   $NewAppPool.CurrentIdentityType = "SpecificUser"
   $NewAppPool.Username = $NewAppPoolUserName
   $NewAppPool.SetPassword($Password)
   $NewAppPool.Provision()
   $NewAppPool.Update($true)
   $NewAppPool.Deploy()
   

   The new application pool will be available immediately.
3. Verify
1. Log into one of the farm WFEs hosting the web application using any administrator account.
2. Launch IIS Manager.
3. In the Connections tree, expand Application Pools.

Remove an existing web application pool

1. Review
1. Log into a SharePoint 2013 server using the SharePoint Setup User Administrator account (eg, spAdmin). This is the same account that you (should have) used to perform the initial farm installation and configuration.

   This is important in that the changes you will be making will be to the farm configuration database; and, by default, only this account has the privileges necessary to make such changes.

2. Launch an elevated SharePoint Management shell.
3. Execute the following commands, making appropriate revisions:

   ([Microsoft.SharePoint.Administration.SPWebService]::ContentService).ApplicationPools | Sort-Object Name | Select-Object Name, ID, UserName, Status, parent | Format-Table -Auto
   

4. Identity the name of the web application pool you want to remove.
5. Copy this name.
2. Remove
1. Now, using the same management shell, execute the following command to remove the web application pool.

   $apppool = [Microsoft.SharePoint.Administration.SPWebService]::ContentService.ApplicationPools | where {$_.Name -eq "[name of web application pool]"}
   $apppool.UnProvisionGlobally()
   

   This executes as a job and will take a minute or two to complete.
3. Verify
1. Log into one of the farm WFEs hosting the web application using any administrator account.
2. Launch IIS Manager.
3. In the Connections tree, expand Application Pools.

References

• Direct
• Initial deployment administrative and service accounts in SharePoint 2013
• Account permissions and security settings in SharePoint 2013
• SharePoint 2013: Service Account Configurations and Permissions
• Create a SharePoint Application Pool using PowerShell
• Delete a SharePoint Web Application Pool
• Title Application pools recycle when memory limits are exceeded. ???
• General
• Windows PowerShell for SharePoint 2013 reference
• New-Object
• Microsoft.SharePoint.Administration namespace
• SPApplicationPool constructor (String, SPWebService)

Notes

• The new web application pool will not be added to the  application pools associated with web applications until you execute the Update method.  You can test this by executing all of the commands up to but not including the Update method, and then listing out the web application pools.  Additionally, you will not see the new application pool show up in IIS Manager until after you execute the Deploy method.
• The Remove method of [Microsoft.SharePoint.Administration.SPWebService]::ContentService.ApplicationPools object appears to only remove the web application pool from the farm configuration database and not also from IIS.  On the other hand, the UnprovisionGlobally method of an SPApplicationPools object removes the application pool both from SharePoint and IIS.
• If you get an instance of the SPApplicationPools object and review its members, note that there is a Provision method but that this method does not push the update to the WFEs.  On the other hand, the UnprovisionGlobally method of this object does touch both SharePoint configuration and IIS, updating both.  This seems inconsistent.
• Thanks to Brendan Griffin and Henrik Tønnessen for helpful presentations on this topic.

SharePoint 2013: how to change a web application pool identity

Introduction
This posting explores how to change a web application pool identity using PowerShell methods.  It assumes that both the current and target identities are configured as managed accounts (this makes things much simpler).  You'll start out by first just reviewing the current identity of the web application.  Next, you'll execute a few very simple scripts that change change the application pool configuration to the target managed account. All references used in this posting are listed below.

Procedure

1. Review existing web application pool identity
1. Log into a SharePoint 2013 server using the SharePoint Setup User Administrator account (eg, spAdmin). This is the same account that you (should have) used to perform the initial farm installation and configuration.

   This is important in that the changes you will be making will be to the farm configuration database; and, by default, only this account has the privileges necessary to make such changes.

2. Launch an elevated SharePoint Management shell.
3. Execute the following command, making appropriate revisions:

   $wa=Get-SPWebApplication "[YourSiteURL]"
   $wa.ApplicationPool
   

   This lists out all the pertinent information concerning the web application pool's identity. A useful command to remember for future reference.
2. Implement the change
1. Now, using the same management shell, execute the next few commands to make the change to the identity:

   $ma=Get-SPManagedAccount -Identity "[target managed account]"
   $wa.ApplicationPool.ManagedAccount=$ma
   $wa.ApplicationPool.Update()
   $wa.ApplicationPool.Deploy()
   

   The change will be implemented immediately.
3. Verify the change
1. Log into one of the farm WFEs hosting the web application - use any administrator account.
2. Launch IIS Manager.
3. In the Connections tree, expand Application Pools.

   If you still see the original identity, press F5 to refresh - no need to recycle the application pool or perform an IIS reset.

References

• SharePoint User and Service Accounts
• Initial deployment administrative and service accounts in SharePoint 2013
• Account permissions and security settings in SharePoint 2013
• SharePoint 2013: Service Account Configurations and Permissions
• PowerShell
• Get-SPWebApplication
• Get-SPManagedAccount
• Miscellaneous
• Changing the Web Application Pool Identity using PowerShell

Notes

• Executing the first three lines in step 2.1), above, updates the farm configuration database, but does not update the identity among the application pools on the web front ends.  You can verify this by stopping after executing the Update() method, and then going to IIS on one of the WFEs and looking at the application pool identities listed there.  So, to get the update pushed out to the WFEs, you must execute the Deploy() method of the ApplicationPool property.

SharePoint 2013: change all site access request emails

Introduction

This posting shows you how to change all of the site access request emails in one go using PowerShell.  To see how to disable such access requests in bulk, check out the Notes section.

Procedures

1. To quickly review the RequestAccessEmail settings for all subwebs of a site collection, execute the following in an elevated SharePoint Management shell:
   

   Get-SPSite [your Site Collection URL] | Get-SPWeb -limit all | Sort-Object Title | ft title, HasUniquePerm, RequestAccessEnabled, RequestAccessEmail | Format-table -auto
   

2. To set the RequestAccessEmail setting for all subwebs of a site collection, execute the following script in an elevated PowerShell window:

   if ((Get-PSSnapin -Name "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue) -eq $null)
   {
     Add-PsSnapin Microsoft.SharePoint.PowerShell
   }
   $siteURL = Read-Host "Enter the URL to the site collection"
   $email = Read-Host "Enter the new Request Access email address"
   $site = Get-SPSite $siteURL
   $countupdated = 0
   $countnotupdated = 0
   ForEach ($web in $site.AllWebs)
   {
     If (!$web.HasUniquePerm)
     {
       Write-Host $web.Title, " - Inherits from parent, no change made"
       $countnotupdated = $countnotupdated + 1
     }
     Else
     {
       $web.RequestAccessEmail = $email
       $web.Update()
       Write-Host $web.title, " - updated email"
       $countupdated = $countupdated + 1
     }
   }
   Write-Host "RequestAccessEmail Updating Completed"
   Write-Host "Total updated: "$countupdated
   Write-Host "Total not updated: "$countnotupdated
   

References

• Define who recieves mail notification about access request
• Get-SPWebApplication
• SPWeb.RequestAccessEmail property 
• Cannot Update Web's RequestAccessEmail property
• Change All SharePoint Site's Access Request Emails with PowerShell
• Replace-RequestAccessEmail

Terminology

• Web: this is a subsite.  Use Get-SPWeb to retrieve.
• Site: this is generally used to refer to a site collection.  Use Get-SPSite to retrieve.

Notes

• I found that if you check the value of RequestAccessEmail via PowerShell and compare that with the value you see if you actually navigate to the site's settings for this  (Site Settings > Site Permissions > Access Request Settings), these values are inconsistent. Furthermore, by comparing the results between what PowerShell returned and what was visible online, I found that the value for RequestAccessEmail returned by PowerShell was the most recent one - 1.  In other words, if I made changes A, B and C, in that order, PowerShell returned B while online was shown C.  The value returned by PowerShell was always one change behind.
• To disable access requests for all sites, just set RequestAccessEmail to "" in the code routine above.

SharePoint 2013: how to view default list and site templates

TIP

Presented below are PowerShell methods for extracting list and site templates.

Default List Templates

$web = Get-SPWeb http://YourSiteURL
$web.ListTemplates | Select-Object name, Type_Client, FeatureID | Sort-Object Name | Format-Table -auto

Default Site Templates

Get-SPWebTemplate | Select-Object Name, Title, isHidden | Sort-Object Name | Format-Table -auto

Custom List Templates

$web = Get-SPWeb http://YourSiteURL
$list = $web.Lists["List Template Gallery"]
$table = New-Object system.data.datatable "MyTable"
$col1 = new-object system.data.datacolumn "TemplateTitle"
$col2 = new-object system.data.datacolumn "TemplateType"
$col3 = new-object system.data.datacolumn "FeatureID"
$table.columns.add($col1)
$table.columns.add($col2)
$table.columns.add($col3)
ForEach ($item in $list.items) {$row=$table.NewRow();$row.TemplateTitle=$item.Properties.TemplateTitle;$row.TemplateType=$item.Properties.TemplateType;$row.FeatureID=$item.Properties.FeatureID;$table.Rows.Add($row)}
$Table | sort-object templateTitle -desc | format-table -auto

References

• List Template types and IDs in SharePoint
• Get a list of web templates and IDs in a SharePoint site
• List saved as template does not appear under Add an app or what lists can you save as template and use for creating other lists based on them
• Creating table using Powershell
• SharePoint 2013 List Templates
• Get ListTemplate and Create New List in PowerShell
• PowerShell to Get List Schema in SharePoint

Notes

• I've not been able to find the GUID property for default site templates.  It's not listed.  There must be some sort of unique ID for these, since some of them have the same name and must be distinguished by other means.
• Note that not all custom list template properties are found directly in the item object but that some are found in the Properties sub-object.  Also, because it's a list, you can't easily extract the templates using a single command.  So, instead, I created a table object, populated the table, and then displayed the object using convenient format commands.

SharePoint 2013: Using Log Parser to develop usage metrics

Introduction

Microsoft LogParser provides the SharePoint admnistrator with significantly greater usage analysis capabilities than those previously offered in SharePoint 2010 and much much more so than offered in 2013, which are minimal and problematic.  This posting captures the steps undertaken in analyzing simple website usage metrics using Microsoft Log Parser.  Specifically, it captures the steps for generating usage graphs based upon IIS data, including:

• Daily Total User Requests (Page Hits)

Procedure

1. Collate farm configuration information
1. Identify all farm web servers
• For this farm, there are two: WFE1 and WFE2.
2. Identify IIS log settings all web servers
• IIS Manager > Select web application > Double-click Logging
• Schedule: Daily
• Format: W3C
3. Identify IIS Log Folders all web servers
• By default, these are here: C:\inetpub\logs\LogFiles.
• Each web application will have its own folder, distinguished by unique IDs. These IDs among the farm web servers will match: the name of a web application log folder on WFE1 will be the same as for that same web application on WFE2. For example, given a two-WFE farm, having two web applications (one for My Sites and one for the regular sites), the folder on both web servers for the My Sites logging might be W3SVC1128939604 and for the standard sites W3SVC1509962310. Note the prefix for each of these: W3SVC.
4. Identify the following service accounts:
1. Farm service account (eg, spFarm)
2. Setup User Administrator (eg, spAdmin)
3. Search content crawl (eg, spContent, spCrawl or spSearch)

   Note down these accounts, both in their claims-aware format (eg, 0#.w|DOMAIN\Account) and their standard AD format (eg, DOMAIN\Account).  Both forms may appear in the IIS logs and both would need to be filtered out so as to focus on actual user metrics.

2. Prepare Analysis Workstation
1. Copy the Log Parser 2.2 binaries to some folder.
2. Add path to Log Parser to DOS PATH environment variable.
3. Create Analysis Folder on local workstation
1. Off root drive to keep path simple.
2. Create dump subfolders for each web server, WFE1 and WFE2: This is needed for storing the log files to be analyzed.  The log names files for each web server are not uniquely identified by server.  This means that the naming used by, say WFE1, will be the same as the naming used by WFE2.  Thus, if you co-mingle these files, they will overwrite each other.
4. Copy IIS logs to analysis folder
1. Copy logs from WFE1 to the WFE1 subfolder and append WFE1 to each log file.  Repeat for WFE2.  These two folders will eventually be used to analyze NLB.
2. Create another folder under Analysis and copy ALL renamed logs into this single folder.  This will be used for bulk analysis.
5. Break out logs by year and month
1. Within the Analysis folder, created folder structure by year and then subfolders by month.
2. Copy IIS logs to appropriate folders: this is a third copy of the logs. 

   Note: I've organized the log files in this manner so as to facilitate analyses using Log Parser.  It was the most rapid way I could think of at the time for building the metrics that I wanted by month.

3. Build Daily Total User Requests Data
1. Build site list
1. Field: Date, Type: Date (only, standard)
2. Field: Requests, Type: Number (0)
3. Field: DailyUniqueUsers, Type: Number (0)
4. Field: MonthlyUniqueUsers, Type: Number(0)
5. Field: YearlyUniqueUsers, Type: Number(0)
2. Open a command shell
3. Navigate to a folder containing all of the log files for a month (and containing the log files from all WFEs for that month).
4. Run these scripts and in this order:
1. logparser -i:IISW3C -o:CSV "select count(*) as ct,cs-username,date from *.log where sc-status<>401 AND cs-username<>'0#.w|DOMAIN\spContent' AND cs-username<>'0#.w|DOMAIN\spAdmin' AND cs-username<>'' AND cs-username<>'DOMAIN\spContent' AND cs-username<>'DOMAIN\spAdmin' group by cs-username,date order by date" -q >dateout.csv

   Note: Tailor the where clause to filter out those service accounts generating a lot of hits but that do not generate meaningful usage data from a user usage perspective.  Same for the setup user administrator account, which is used by the farm administrator to administer configuration.
   
   Note: Some users, who leave a browser connected to SharePoint for long periods, may generate anomalously large hits. For example, on one day during the entire month, one user generated 547,233 hits, almost all of it to [site]/vti_bin/sites.asmx.  Filtering out such results reduced the total hit count for that day to a level consistent with previous results.

2. logparser -i:CSV -o:csv "select date,sum(ct) as TOTALREQUESTS,count(*) as UNIQUEUSERS from dateout.csv group by date" -q > dailycountsdateo.csv
5. Copy contents of dailycountsdateo.csv to site list.
6. Repeat for each month until all desired months have been analyzed.
7. Once you have a list of dates and daily hit totals, present the data graphically via an Image web part:
   
   .

References

• Download Log Parser 2.2
• Log Parser Studio
• Analyzing Microsoft SharePoint Products and Technologies Usage
• Configure Per-Site Logging Options at the Server Level (IIS 7)
• SharePoint 2010 Capacity Management: Log Parser: though this posting was written for 2010, I still found it relevant for 2013.
• How to present AD metrics in a SharePoint 2010 dashboard
• Quick Analytics from SharePoint (kind of...)
• SharePoint 2013 TIP: how to easily and cost-effectively get unique users metrics
• W3C Logging
• Easy SharePoint 2013 unique users metrics
• SharePoint 2013: Using Log Parser to develop usage metrics

Notes

• Claims-based authentication complications: I found that some users appeared in the IIS logs both under their claims-based authentication (eg, 0#.w|DOMAIN\Adam.Smith) and under their standard AD authentication (eg, DOMAIN\Adam.Smith).  I don't know why this is.  This complicated attempting to determine unique user numbers via LogParser: a single user would appear to be two different users, since Log Parser compares characters, not usernames.  To workaround this, I performed these steps:
1. Used LogParser to generate a listing of all users. 
2. In Excel, removed the prefixes to reduce the listing to just usernames (ie, removed 0#.w|DOMAIN\ and DOMAIN\.
3. Used Excel advanced functionality to find unique entries.
4. Counted unique entries.
• Use "NULL" when filtering for values in the IIS web log that are blank. For example, to filter out all entries having username = NULL, add this statement to the WHERE clause:

  cs-username<>NULL 

• How to write output to a file.  There are two ways in which to have LogParser output written to a file.  The first method involves using the "into" clause.  So, for example, if you had a LogParser statement that you wanted to execute, like this one:

  logparser -i:IISW3C "select count(*) as ct,EXTRACT_TOKEN(cs(user-agent),0,'/') as agent from *.log group by agent order by ct desc"

  you would do this

  logparser logparser -i:IISW3C "select count(*) as ct,EXTRACT_TOKEN(cs(user-agent),0,'/') as agent into MyFile.txt from *.log group by agent order by ct desc"

  Note the placement: just before the from clause.  Using the into method writes the output to file exactly as you see it in the command shell.  The other way is to use the "-q" option, like so:

  logparser -i:IISW3C "select count(*) as ct,EXTRACT_TOKEN(cs(user-agent),0,'/') as agent from *.log group by agent order by ct desc" -q > MyFile.txt

  Note that it comes after the closing quotation mark.  Using the -q method writes a clean columnar output to the file but without any headers. 
• Renaming files in bulk:

  Get-ChildItem -Filter "old" -Recurse | Rename-Item -NewName {$_.name -replace 'old','new' }

SharePoint 2013: Two-Tier farm deployment procedure

Introduction

This posting presents the steps for deploying a small two-server, two-tier SharePoint 2013 farm for use in external corporate collaboration.

NOTE: throughout this posting, the SharePoint Setup User Administrator account is used for installation and configuration.  This is the account used to initially install and configure the farm and should be the account used to install and configure all subsequent SharePoint software.

Procedure

1. Provision Service Accounts
1. spAdmin: SharePoint Setup User Administrator account
2. spApp
3. spContent: search crawl service account
4. spFarm: farm service account
5. spProfile
6. spSearch
7. spService: services service account
8. spSql: database engine service account
9. spSuperR: 
10. spSuperU
11. spWorkfl
2. Prepare Resources
1. Machines
1. Server1
1. Role: Database Server
2. Drives
• C:System 120 GB
• D:Data 250 GB
• E:Logs 100 GB
• F:Backup 250 GB
3. RAM: 12 GB
4. Cores: 4
2. Server2
1. Role: SharePoint Server
2. Drives
• C:System 160 GB
• D:Data 250 GB
• E:Logs 100 GB
3. RAM: 12 GB
4. Cores: 4
2. Software
1. SQL Server 2012 Standard
2. SharePoint Server 2013 Enterprise
3. Build SQL Server Host
1. See: SharePoint 2013: how to install named SQL Server instance for new farm.
4. Prepare SharePoint Server Host
1. Add Desktop Experience Feature
2. Install Application Server Role
3. Install Web Server Role
1. Add NET Framework 3.5 Features.
2. Add ASP.NET 4.5 Feature
3. Add Windows Process Activation Service Support > HTTP Activation
4. Edit HOSTS file to create temporary networking
1. C:\Windows\System32\Drivers\etc
5. Create 32-bit and 64-bit database access aliases
6. Disable loopback checking: New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopBackCheck" -Value "1" -PropertyType dword
7. Disable IESC
8. Verify SharePoint Setup User Administrator and Farm Service accounts are members of local Administrators group.
5. Install SharePoint Server 2013 prerequisites
6. Install SharePoint Server 2013 binaries
7. Create Configuration and Administration Databases
1. Launch elevated SharePoint Management Shell
2. Execute: Add-Pssnapin Microsoft.SharePoint.PowerShell
3. Execute: New-SPConfigurationDatabase –DatabaseName configurationdatabasename  –DatabaseServer sqlserverinstancename –AdministrationContentDatabaseName administrationcontentdatabasename
1. configurationdatabasename: name you want to assign to the farm configuration database.  For example: [someprefix]_Config.
2. sqlserverinstancename: this is the name of the alias you have configured for database access.
3. administrationcontentdatabasename: this is the name you want to assign to the central administration content database.  For example: [someprefix]_Content_CA.
4. You will be prompted to enter the farm credentials: this is the farm service account name and password.
5. Next, enter the passphrase.  For example, use the farm service account password.
6. Wait for about five minutes.
8. Configure SharePoint Farm
1. Launch SharePoint Products Configuration Wizard using the SharePoint Setup User Administrator account (eg, spAdmin).
2. At the Welcome page, click Next.
3. At the popup prompt, click Yes.
4. At the Modify server farm Settings page, click Next.
5. At the Configure SharePoint Central Administration Web Application page, enable the Specify port number option, and enter a port number (eg, 5000).
6. Ensure that NTLM is selected, and then click Next.
7. At the Completing the SharePoint Products Configuration Wizard page, click Next.  Configuration will take less than five minutes.
8. At the Configuration Successful page, click Finish.  The dialog closes and a navigator instance is launched and navigated to the Central Administration site.
9. Click the Cancel button, when prompted to use the Configuration Wizard.
9. Configure Managed Accounts
1. Go to: CA > Security > General Security > Configure managed accounts.
2. Enter all of the service accounts that you will be using for the farm.
10. Configure Outgoing Email
1. Go to: CA > System Settings > Email and Text Messages > Configure outgoing email settings.
2. Enter appropriate SMTP server, etc.
11. Configure Service Applications
1. Usage and Health
1. Launch elevated SharePoint Management Shell
2. Execute:
   New-SPUsageApplication -Name "Usage Application" -DatabaseName  databasename -DatabaseServer databaseinstancename
   (Get-SPServiceApplicationProxy | where-object {$_.TypeName -eq “Usage and Health Data Collection Proxy”}).Provision()
2. Managed Metadata
1. Launch Central Administration as SharePoint Setup User Administrator account.
2. Go to: Application Management > Service Applications > Manage service applications
3. On the SERVICE APPLICATIONS tab on the ribbon, click the New button, and then select Managed Metadata Service.
4. Configure as follows:
1. Name: Managed Metadata Service
2. Database Server: [will default to alias previously entered]
3. Database Name: [prefix]_Metadata
4. Database Authentication: Windows
5. Failover Database Server: [name of failover]
6. Select Create new application pool, and then enter SharePoint Hosted Services
7. Application Pool Security Account: services account
8. Content Type Hub: [leave blank]
9. Report Syndication Import Errors: Yes
10. Add this services application to the farm's default list: Yes
11. Click OK.

    After clicking OK, you will be returned to the Service Applications list, which will now display the proxy for the Application Discovery and Load Balancer Service Application. Note too that the usual SharePoint database roles, such as SPDataAccess, etc, are not created for the Management Metadata database, so, don't panic if you don't see them there.

5. Go to: CA > System Settings > Manage services on server.
6. Start the Managed Metadata Web Service
7. Go to: CA > Application Management > Manage service applications
8. Select (don't click on the title) Managed Metadata Service Connection
9. On the SERVICE APPLICATIONS tab on the ribbon, click the Properties button.
10. Enable these settings ONLY:
1. This service application is the default storage location for Keywords
2. This service application is the default storage location for column specific term sets.
11. Select (don't click on the title) Managed Metadata Service.
12. On the SERVICE APPLICATIONS tab on the ribbon, click the Permissions button.
13. Add the search crawl account (spContent) and provision it with Read.
14. Add the service account (spService) running the Managed Metadata application pool (SharePoint Hosted Services) and provision it with Full Access.
3. State Service
1. Launch elevated SharePoint Management Shell
2. Execute:
   $serviceapp = New-SPStateServiceApplication -Name "State Service"
   New-SPStateServiceDatabase -Name "StateServiceDatabaseName" –ServiceApplication $serviceapp
   New-SPStateServiceApplicationProxy -Name "State Service Proxy" -ServiceApplication $serviceapp –DefaultProxyGroup
4. Secure Store Service
1. Launch Central Administration as SharePoint Setup User Administrator account.
2. Go to: Application Management > Service Applications > Manage service applications
3. On the SERVICE APPLICATIONS tab on the ribbon, click the New button, and then select Secure Store Service.
4. Configure as follows:
1. Name: Secure Store Service
2. Database Server:  [will default to alias previously entered]
3. Database Name: [prefix]_SecureStoreService
4. Database Authentication: Windows
5. Failover Database Server: [failover name]
6. Application Pool: Select Use existing application pool, and then select SharePoint Hosted Services.
7. Audit log enabled: enable this and set for 30 days (default).
5. Click OK.
6. Go to: CA > System Settings > Manage services on server.
7. Start the Secure Store Service.
8. Go to: CA > Application Management > Manage service applications.
9. Select (don't click on the title) Secure Store Service.
10. On the SERVICE APPLICATIONS tab on the ribbon, click the Manage button.
11. On the EDIT tab of the ribbon, click the Generate New Key button.
12. Enter a passphrase (eg, use the same one as used for the farm passphrase).
13. Click OK.
5. Business Data Connectivity
1. Launch Central Administration as SharePoint Setup User Administrator account.
2. Go to: Application Management > Service Applications > Manage service applications.
3. On the SERVICE APPLICATIONS tab on the ribbon, click the New button, and then select Business Data Connectivity Service.
4. Configure as follows:
1. Name: Business Data Connectivity Service.
2. Database Server:  [will default to alias previously entered]
3. Database Name: [prefix]_BDCService
4. Database Authentication: Windows
5. Failover Database Server: [failover name]
6. Application Pool: Select Use existing application pool, and then select SharePoint Hosted Services.
7. Click OK.
5. Go to: CA > System Settings > Manage services on server.
6. Start the Business Data Connectivity Service.
6. Excel Services
1. Launch Central Administration as SharePoint Setup User Administrator account.
2. Go to: Application Management > Service Applications > Manage service applications.
3. On the SERVICE APPLICATIONS tab on the ribbon, click the New button, and then select Excel Services Application.
4. Configure as follows:
1. Name: Excel Services.
2. Application Pool: Select Use existing application pool, and then select SharePoint Hosted Services.
3. Add this services application to the farms default list: yes
5. Click OK.
6. Go to: CA > System Settings > Manage services on server.
7. Start the Excel Calculation Services service.
8. Go to: CA > Application Management > Manage service applications
9. Select (don't click on the title) the Excel Services application.
10. On the SERVICE APPLICATIONS tab on the ribbon, click the Manage button.
11. Click Trusted File Locations.
12. Verify that an entry for address "http://" is listed.  This configures the entire farm as a trusted location - no need to specify specific SharePoint sites and folders.
7. Visio Graphics Service Application
1. Launch Central Administration as SharePoint Setup User Administrator account.
2. Go to: Application Management > Service Applications > Manage service applications.
3. On the SERVICE APPLICATIONS tab on the ribbon, click the New button, and then select Visio Graphics Service.
4. Configure as follows:
1. Name: Visio Graphics Service.
2. Application Pool: Select Use existing application pool, and then select SharePoint Hosted Services.
3. Add this services application to the farms default list: yes
5. Click OK.
6. Go to: CA > System Settings > Manage services on server.
7. Start the Visio Graphics Service.
8. Go to: Application Management > Service Applications > Manage service applications.
9. Select the Secure Store Service application (don't click the title).
10. On the SERVICE APPLICATIONS tab on the ribbon, click the Manage button.
11. On the EDIT tab of the ribbon, click the New button.
12. Configure as follows:
1. Target Application ID: VisioUnattendedAccount.
2. Display Name: Visio Unattended Account.
3. Contact Email: [email address].
4. Target Application Type: Group.
13. Click Next.
14. Click Next again.
15. Configure as follows:
1. Target Application Administrator: SharePoint Setup User Administrator Account.
2. Members: [enter Domain Users].
16. Click OK.
17. Go to: Application Management > Service Applications > Manage service applications.
18. Click on the title of the Visio Graphics Service application.
19. Click on the Global Settings link.
20. Scroll down to the External Data section, and then enter VisioUnattendedAccount.
21. Click OK.
8. Work Management Service
1. Create a new application pool:
   New-SPServiceApplicationPool -Name "WMS AppPool" -Account "Domain\spApp"
   (Get-SPServiceApplicationPool "WMS AppPool").Provision()
   
2. Go to: CA > Application Management > Manage service applications.
3. On the SERVICE APPLICATIONS tab on the ribbon, click the New button, and the select Work Management Service Application.
4. Configure as follows:
1. Name: Work Management Service.
2. Application Pool: Select Use existing application pool, and then select WMS AppPool"
3. Service application proxy: enable.
5. Click OK.
6. Grant the account that the Work Management service is running as "Full Control" to the User Profiles Using "administrators" button on the ribbon
7. Go to: Application Management > Service Applications > Manage service applications.
8. Click on the title of the Work Management Service.

   If you check IIS Application Pools listing at this moment, you will not see the WMS AppPool show up just yet. You need to start the service, and then it will appear in the list. Note that it will not appear under its name, but under a GUID.

9. Start the Work Management Service.
9. Search Service
• This will be engaged separately.
10. Deploy Additional Service Applications
1. Go to: CA > Security > Configure service accounts.
2. Set Windows Service – Claims to Windows Token Service to the service account.
3. Set Windows Service – Microsoft SharePoint Foundation Sandboxed Code Service to the service account (ie, spService).
4. Go to: CA > System Settings > Manage services on server.
5. Start Claims to Windows Token Service.
6. Start Microsoft SharePoint Foundation Sandboxed Code Service.
12. Configure Monitoring
1. Configure Diagnostic Logging
1. Go to: CA > Monitoring > Configure diagnostic logging.
2. Configure as follows:
1. Event Log Flood Protection: enabled (by default)
2. Trace Log Path: (preferably a dedicated logging drive\SPLogs\ULS)
3. Click OK.
2. Configure Usage and Health data collection
1. Go to: CA > Monitoring > Configure usage and health data collection  
2. Configure as follows:
1. Log file location: (preferably a dedicated logging drive\SPLogs\Usage)
2. Enable health data collection: enabled
3. Click OK.
13. Provision Primary Content Web Application
1. Create New Web Application
1. Go to: CA > Application Management > Manage web applications
2. On the WEB APPLICATIONS tab of the ribbon, click the New button.
3. Configure as follows:
1. Accept defaults unless otherwise indicated
2. Name of the site (I prefer using no spaces)
3. Host Header: FQDN of the DNS entry.  If you've configured temporary static DNS (via HOSTS file), enter this domain name.
4. Database Name: [prefix]_Content
4. Click OK
2. Configure Web Application Settings
1. Configure General Settings
1. Accept defaults unless otherwise indicated
2. Default Time Zone: select appropriate zone.
3. Browser File Handling: Permissive (to enable PDFs to open in browser)
4. Send User Name and Password in Email: No
5. Maximum Upload Size: 50 MB
2. Configure Resource Throttling
1. Accept defaults unless otherwise indicated
3. Configure Workflow
1. Accept defaults unless otherwise indicated
4. Configure Outgoing Email
1. Accept defaults unless otherwise indicated.

   If you configured these settings for the farm already, these fields will be pre-populated for the web application.

2. Outbound SMTP server: enter as appropriate
3. From address: enter as appropriate
4. Reply-To address: enter as appropriate
5. Configure Mobile Account: skip
6. Configure SharePoint Designer
1. Accept defaults unless otherwise indicated.
3. Create Root Site Collection
1. Go to: CA > Application Management > Create site collections
2. Configure as follows:
1. Web Application: select the target web application.
2. Title and Description: enter title.
3. Template Selection: Publishing Portal.
4. Primary Site Collection Administrator: SharePoint Setup User Administrator account.
5. Secondary Site Collection Administrator: primary site collection administrator.
3. Click OK
4. Activate Key Features
1. Web Application Level
1. Go to: CA > Application Management > Manage Web Applications
2. Select the primary content web application
3. On the WEB APPLICATIONS tab on the ribbon, click the Manage Features button.
4. Verify that the features listed below are activated.  If they are not, activate them.  Some of these features are necessary to support other applications and caching.
1. Document Sets metadata synchronization
2. SharePoint Server Enterprise Search
3. SharePoint Server Enterprise Web application features
4. SharePoint Server Site Search
5. SharePoint Server Standard Web application features
2. Site Collection Level
1. Go to: Site Settings > Site Collection Administration > Site collection features.
2. Verify that the features below are activated.  If they are not, activate them.  Some of these features are necessary to support other applications and caching:
1. SharePoint Server Enterprise Site Collection features
2. SharePoint Server Publishing Infrastructure
3. SharePoint Server Standard Site Collection features
4. Workflows
5. Configure Caching
1. Configure object cache user accounts
1. Open an elevated SharePoint Management shell
2. Execute the following:
   $wa = Get-SPWebApplication -Identity "[webapplication]"
   $wa.Properties["portalsuperuseraccount"] = "[superuser]"
   $wa.Properties["portalsuperreaderaccount"] = "[superreader]"
   $wa.Update()
   

   You must use the claims-authentication format for these user accounts. This is of the format:
   i:0#.w|domain\UserAccount

3. Go to: CA > Application Management > Manage Web Applications
4. Select the primary content web application.
5. On the WEB APPLICATIONS tab on the ribbon, click the User Policy button.
6. Click Add Users.
7. On the Zones list, select All zones, and then click Next.
8. In the Users text box, enter the super user account name in claims-authentication format.
9. Check Full Control - Has full control.
10. Click Finish.
11. Click Add Users
12. On the Zones list, select All zones, and then click Next.
13. Check Full Read - Has full read-only access.
14. In the Users text box, enter the super reader account name in claims-authentication format.
15. Click Finish.
2. Configure BLOB cache settings
1. Navigate to C:\inetpub\wwwroot\wss\VirtualDirectories\[primary content web application]
2. Save a copy of web.config.
3. Open the original in NotePad.
4. Search for "<BlobCache"
5. Set the location attribute to a data drive, eg, "D:\spdata\blobcache".
6. Set the enabled attributed to "true".
7. Set the maxSize="10".

   This Microsoft TechNet article indicates that the default here is 10. Value is expressed in GB.  Changing this file in any way causes an IIS recycle.

8. Save and close the file.
3. Configure Page Output Cache
1. Navigate to C:\inetpub\wwwroot\wss\VirtualDirectories\[primary content web application]
2. Save a copy of web.config.
3. Open the original in NotePad.
4. Search for "<OutputCacheProfiles"
5. Set the useCacheProfileOverrides to True.
6. Save and close the file.
4. Configure Object Cache
1. Ensure that the SharePoint Server Publishing Infrastructure is activated for the site collection.
2. Navigate to C:\inetpub\wwwroot\wss\VirtualDirectories\[primary content web application]
3. Save a copy of web.config.
4. Open the original in NotePad.
5. Search for "<ObjectCache"
6. Set the maxSize attribute to "100".
7. Save and close the file.
14. Provision a Search Service Application
1. Preparation
1. Verify setup user administrator account (eg, spAdmin) is member of local Administrator group on all farm servers. 
2. Identify service accounts and passwords: 
1. Content Access service account 
2. Administration and query service account 
3. Map the Admin service account to diagnostic logging database as dbo. 
4. Identify the web front end server names 
1. WFE1 
5. Identify the drive on the servers where you want to store indexes.  This drive must be the same on all farm servers hosting SharePoint. 
1. (eg) D:\SPIndex 
6. Verify that any application pools created for previous installations (if any) of the Search Service Application have been removed. 
1. (eg) Search Service AppPool 
2. Implementation
1. Instantiate Search Services 
1. Remote into the application server as the Setup User Administrator account (eg, spAdmin). 
2. Open the SharePoint 2013 Management Shell as administrator. 
3. Download this script: Enterprise Search Deployment Script  . 
4. Edit variables as appropriate to your farm. 
5. Run the script. 
6. After completion of the script, navigate to the Search Service Administration page and verify that the search service topology is similar to what is presented above. 
7. Verify that the default content access service account is set as the crawl account. 
2. Configure Content Sources 
1. In CA, navigate to Content Sources, and then click on Local SharePoint sites (it will be the only item in the list at present). 
2. Note the sources (URLs) present. 
3. Create individual content sources for each of these URLs so that they can be crawl scheduled individually.  So, for example, configure the following entries: 
1. Local SharePoint sites: point it to your primary web application.  If your farm has more than one web application supporting user websites, creating individual entries for each.

   At this point, you have not yet created My Sites or a User Profile Service application. Once you create these, you will need to update the Content Sources accordingly.
4. Configure crawl schedules for each content source as appropriate. Create full and incremental schedules. 
3. Configure SSL Content sources 
1. If your search service needs to use SSL to crawl certain content sources, you will need to configure the service to ignore SSL warnings. 
2. In CA, go to: General Application Settings > Search > Farm Search Administration. 
3. In the Farm-Level Search Settings group, look for Ignore SSL warnings. 
4. Click No. 
5. Enable Ignore SSL certificate name warnings. 
6. Click OK. 
4. Additional Search Service Account Configuration
1. Grant the Search Service account RW permission to the network backup folder.
5. Provision Global Search Center
1. Navigate to the root of the primary content site.
2. From the Settings menu, select Site Content.
3. Scroll down to the bottom and click the new subsite link.
4. Enter the Title as SearchCenter.
5. For the Web Site Address, enter SearchCenter.
6. In the Template Selection group, select the Enterprise tab, and then select the Basic Search Center.
7. In the Navigation Inheritance group, select Yes.
8. Leave all other settings as default.
9. Click the Create button.

   This will created a variety of search-type pages, including a results.aspx page.  This is the page you'll need to set the Global and site collection search results URLs to.
6. Configure Global Search Center 
1. In CA, navigate to the Search Service Administration page.
2. Click the link, Enter a URL for the Global Search Center.
3. Enter the Global Search Center URL to the Search Center results page you previously created for your web application.
4. Click OK.
5. Navigate to the root site collection of the content web application.
6. Go: Site Settings > Site Collection Administration > Search Settings.
7. Enter the Search Center URL.
8. Uncheck Use the same results page settings as my parent.
9. Select Send queries to a custom results page URL.
10. Enter the URL to the Search Center results page.
11. Click OK.
15. Configure AppFabric
1. Change AppFabric Service account

   By default, the AppFabric service will be configured to run under the farm service account.  This will eventually trigger a rule violation, The server farm account should not be used for other services.  To avoid this issue, change the AppFabric identity to another service account, such as the application server account (eg, spService).  The following steps show you how.

1. Launch an elevated SharePoint Management shell.
2. Execute the following commands in the  shell: use-cachecluster; get-CacheHost.  This should return a service status of UP.  If so, proceed to the next step.  Otherwise, troubleshoot and resolve before continuing.
3. Execute the following commands:

    
   $farm = Get-SPFarm
   $cacheService = $farm.Services | 
     where {$_.Name -eq "AppFabricCachingService"}
   $accnt = Get-SPManagedAccount -Identity "domain\spService"
   $cacheService.ProcessIdentity.CurrentIdentityType = "SpecificUser"
   $cacheService.ProcessIdentity.ManagedAccount = $accnt
   $cacheService.ProcessIdentity.Update() 
   $cacheService.ProcessIdentity.Deploy()
     
   

4. Test the reconfigured AppFabric service by executing the following commands in the same shell: use-cachecluster; get-CacheHost.  This should a service status of UP.  
16. Final Checks
1. Check Service Accounts
1. In an elevated SharePoint Management shell, execute the following commands:
   
   $ComputerName = $env:computername
   $SPServices = Get-WmiObject -Class Win32_Service -ComputerName $ComputerName | ? {($_.Name -eq "AppFabricCachingService") -or ($_.Name -eq "c2wts") -or ($_.Name -eq "FIMService") -or ($_.Name -eq "FIMSynchronizationService") -or ($_.Name -eq "Service Bus Gateway") -or ($_.Name -eq "Service Bus Message Broker") -or ($_.Name -eq "SPAdminV4") -or ($_.Name -eq "SPSearchHostController") -or ($_.Name -eq "OSearch15") -or ($_.Name -eq "SPTimerV4") -or ($_.Name -eq "SPTraceV4") -or ($_.Name -eq "SPUserCodeV4") -or ($_.Name -eq "SPWriterV4") -or ($_.Name -eq "FabricHostSvc") -or ($_.Name -eq "WorkflowServiceBackend")}
   $SPServices | Select-Object DisplayName, StartName, StartMode, State, Status | Sort-Object DisplayName | Format-Table -AutoSize
    
2. All service accounts listed should be running, except for the FIM and VSS Writer services.
2. Check IIS Sites and App Pools
1. In an elevated SharePoint Management shell, execute the following commands:
   
   Import-Module webadministration
   $IIS = Get-ChildItem IIS:\Sites | Select-Object Name, ID, ApplicationPool, ServerAutoStart, State
   $IIS | Format-Table -autosize
    
2. All listed web sites should have a state of Started.
3. Next, execute the following commands:
   
   Add-WindowsFeature Web-WMI
   $AppPools = Get-CimInstance -Namespace root/MicrosoftIISv2 -ClassName IIsApplicationPoolSetting -Property Name, AppPoolIdentityType, WAMUserName, AppPoolState | select @{e={$_.Name.Replace('W3SVC/APPPOOLS/', '')};l="Name"}, AppPoolIdentityType, WAMUserName, AppPoolState
   $AppPools | Format-Table -AutoSize
    
4. All listed SharePoint application pools should have an AppPoolState of 2.

References

• SharePoint 2013: how to install named SQL Server instance for new farm
• Configure Service Applications
• Manage the State Service (SharePoint Server 2010): still applicable to 2013.
• Overview of managed metadata service applications in SharePoint Server 2013
• Configure Business Connectivity Services solutions for SharePoint 2013
• How to Setup and Configure Visio Graphics Service in SharePoint 2013: outstanding and comprehensive presentation.
• SharePoint 2013: Work Management Service Application
• Use Windows PowerShell cmdlets to administer the Work Management Service in SharePoint Server 2013
• SharePoint 2013: How to Configure Work Management Service Application using PowerShell
• Provision Web Application
• Configure Caching
• Cache settings operations in SharePoint Server 2013
• Configure object cache user accounts in SharePoint Server 2013
• Configure cache settings for a web application in SharePoint Server 2013
• Application Pools
• Create a SharePoint Application Pool using PowerShell
• Provision a Search Service Application
• SharePoint 2013: How to deploy a search service application using PowerShell
• Set up a Search Center in SharePoint 2013

SharePoint 2013: Can not create a Publishing Portal site

Problem

You have stood up a new SharePoint 2013 farm.  You've provisioned all service applications and configured caching (all types).  You create a new content web application, and then attempt to create a new root site collection based upon the Publishing Portal template from Central Administration.  Both the web application and the root site collection were created through Central Administration.  You see the usual notification in Central Administration indicating that the site collection was created successfully.  However, when you attempt to navigate to the new root site collection, you see the usual.

Troubleshooting

1. Checked ULS: found instances of the following:
   
   

   "System.IO.FileNotFoundException: The system cannot find the file specified. 
   (Exception from HRESULT: 0x80070002), StackTrace:..."
    
   UserAgent not available, file operations may not be optimized....
    
   

2. Check Application log: no critical, error or warning events associated with the problem were found.
3. Test other site templates: removed the Publishing Portal site, and then attempted to create root site using Team Site template.  Successful.  Tried using Basic Search template.  Successful.  Then tried again using Publishing template.  Unsuccessful.
4. Reviewed  postings: this posting seemed to indicate a problem with Web.Config.  I recalled that I had edited web.config for the target web application in order to enable BLOB and object caching.  I saved the original before edit it.
5. Re-implement original web.config: after restoring the original, unedited file, I was able to create a root site collection based upon the Publishing Portal template.

Solution

• Restore the original Web.Config file.

References

• SharePoint 2007’s Most Common and Confusing Error
• Could not create publishing site
• Cannot access SharePoint 2013 publishing site
• The DataSourceID of 'TopNavigationMenu' must be the ID of a control of type IHierarchicalDataSource
• Unable to Create Root Site collection with Publishing Portal Template
• The DataSourceID of ‘TopNavigationMenu’ must be the ID of a control of type IHierarchicalDataSource (this is a different article than the one above)

SharePoint 2013: AppFabric service repeatedly stops

Problem

You discover that the AppFabric Caching Service, seen in the Services control panel, repeatedly stops.  You can start it, and it runs awhile, but then it stops.

History

• Errors appear to have begun after changing the AppFabric identity from its default (on new farm installation, this is the farm service account) to a service account (eg, spService).

Troubleshooting

1. Check Service Status: Executing Use-CacheCluster; Get-CacheHost, while the service is running, you find system status to be UNKNOWN.  If you execute this while the service is stopped, you see a status of DOWN.
2. Check Application Log: reviewing the server's logs, you see these events occurring regularly:
   
   

   Error Event 111: Microsoft-Windows Server AppFabric Caching
   AppFabric Caching service crashed with exception 
   {Microsoft.ApplicationServer.Caching.DataCacheException:...
   
   Error Event 1000: Application Error
   Faulting application name: DistributedCacheService.exe, version: 1.0.4632.0,
    time stamp: 0x4eafeccf...
   
   Error Event 2016: .NET Runtime
   Application: DistributedCacheService.exe
   Framework Version: v4.0.30319
   Description: The process was terminated due to an unhandled exception...
   
   Error Event 7031: Service Control Manager
   The AppFabric Caching Service service terminated unexpectedly.  It has done 
   this 1 time(s).  The following corrective action will be taken in 60000 
   milliseconds: Restart the service...
    
   Error Event 7034: Service Control Manager
   The AppFabric Caching Service service terminated unexpectedly.  It has done 
   this 26 time(s)...
    
   Warning Event 6: Microsoft Windows Fabric
   {7bf7299f000000000000000000000000} failed to refresh lookup table, 
   exception: {Microsoft.Fabric.Common.OperationCompletedException: 
   Operation completed with an exception ---> System.TimeoutException: 
   The operation has timed out.... [service account]
    

3. Check Permissions: added AppFabric identity to local Administrators group, but this failed to resolve problem. Changed AppFabric identity back to the farm service account (eg, spFarm). No new errors appeared.  Thus, the problem scope was narrowed to the service account.  Next: needed to determine what about the farm service account enabled it to successfully run the AppFabric service when the application service account could not.
4. Check Database Role Memberships: reviewed and compared farm configuration database (eg, Config) roles of farm and application service accounts: farm service account mapped as: public, db_owner, SPDataAccess, SharePoint_Shell_Access, WSS_Content_Application_Pools, db_accessadmin; application service account mapped as: public and WSS_Content_Application_Pools only.  Thus, application service account did not have sufficient access to farm configuration database.  Mapped SPDataAccess database role to application service account; changed AppFabric identity back to application service account, then monitored: no new errors.

Solution

• Ensure that the AppFabric service identity has the appropriate access to the farm configuration database.  Mapping it to the SPDataAccess role is sufficient.

References

• AppFabric Distributed Cache keeps crashing in SharePoint 2013 – Fixed!
• Both Distributed Cache SharePoint Service and AppFabric Caching Service stop
• AppFabricCachingService – Service Status: Unknown
• AppFabric Caching and SharePoint: Concepts and Examples (Part 1)
• Account permissions and security settings in SharePoint 2013
• My Sites and The SPDataAccess SQL Role

Notes

• Small, two server, two-tier farm
• SQL Server 2012 Standard
• SharePoint 2013 Enterprise
• New deployment.

SharePoint 2013: Set-SPEnterpriseSearchServiceApplication : Content source access username or password is not valid.

Problem

You are nearly completed with the scripted installation of a new Search service.  You execute the last command,

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

where $CAAcct is the content access service account and $CAAcctPW is the encrypted form of the content access service account password.  However, you see this error message:

Set-SPEnterpriseSearchServiceApplication : Content source access username or 
password is not valid.
At line:1 char:1
+ Set-SPEnterpriseSearchServiceApplication -Identity $SearchApp -ApplicationPool 
$ ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: 
(Microsoft.Offic...viceApplication:SetSearchServiceApplication) 
[Set-SPEnterpriseSearchServiceApplication], ArgumentException
   + FullyQualifiedErrorId : Microsoft.Office.Server.Search.Cmdlet
    .SetSearchServiceApplication

You check the content access service account, spContent, and verify that the password you scripted is the correct one in your records.  For this posting, let it be "Pas$word".  You try resetting the password, and then re-running the command, but it returns the same error message.  You then try executing the command using the unencrypted form of the password.  This time, you see this error present:

Set-SPEnterpriseSearchServiceApplication : Cannot bind parameter 

'DefaultContentAccessAccountPassword'. Cannot convert the "Pas" value of type 

"System.String" to type "System.Security.SecureString".
At line:1 char:172
+ ... ccountPassword $password
+                    ~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) 

[Set-SPEnterpriseSearchServiceApplication], ParameterBindingException
    + FullyQualifiedErrorId : CannotConvertArgumentNoMessage,

Microsoft.Office.Server.Search.Cmdlet.SetSearchServiceApplication

You note that only the first characters before the "$" are shown in this error message.  You then reconfigure the account with the same password, substituting the "$" with a "-".  This time, the command executed successfully.

Solution

• When building a search service application, do not configure the search content access service account password with a "$".

References

• SharePoint 2013: How to deploy a search service application using PowerShell

SharePoint 2013: How to resolve common Visio Web Access problems

Introduction

This posting presents steps for resolving two common Visio Web Access problems:

 

Both these problems can be caused by simple configuration or permissions issues that are easily rectified.

Solution

1. Visio Web Access: Sorry, we couldn't open your file using this feature.  Visio Web Access is not available on this site.
1. Ensure these site and site collection features have been activated:
1. SharePoint Server Enterprise Site features
2. SharePoint Server Enterprise Site Collection features
2. Ensure this SharePoint service on server has been started:
• Visio Graphics Service
3. Ensure this service application status is started:
1. Visio Graphics Service
2. Connection to Visio Graphics Service
2. Error: The server failed to process the request.
1. Ensure the Visio Web Access service application pool identity has been mapped to the farm content database SPDataAccess role or greater permission level
   

References

• SharePoint 2013: Service Applications list
• Visio - bug - The server failed to process the request
• Visio Graphics Service service application
• How to Setup and Configure Visio Graphics Service in SharePoint 2013
• Sorry, we couldn't open your file using this feature. Visio Web Access is not available on this site.

Notes

• The following are conclusive indications regarding the "failed to process the request" error:
• Seen in the ULS logs: Insufficient SQL database permissions for user 'Name: domain\service.account SID... ImpersonationLevel: None' in database '[the Central Administration content database]' on SQL Server instance [your farm DB server name or alias]'... 
• Seen in the server's Application logs: same.

SharePoint 2013: Review of the Get started with your site web part

Introduction

The Get started with your site tiles appear automatically on the home page of some site collection.

Specifically, it appears on the home page of those site collections for which the Wiki Page Home Page feature is automatically activated:

When the Wiki Page Home page feature is activated, it causes a wiki page to be the site's landing page, and not a standard web part page.  You can see this by simply viewing the page in Edit mode. Web part pages display the Add a Web Part link in various zones on the page.  The wiki page does not. A Wiki page enables you to enter both content and web parts into all wiki spaces.

The Get started with your site web part is a member of the group of web parts available to all site templates.  It is not associated with any particular feature: you can deactivate all site features, and it will still be available.  It is a single, self-contained web part providing the usual web part configuration options (layout, etc).  You find this web part, by default, in the Media and Content group of web parts, seen when adding a new web part to a page:

It is listed in a site's Web Part Gallery:

The Get started with your site web part functions quite a bit like the Promoted Links app. It presents a tiling experience similar to the Promoted Links web part.  However, there the similarity ends.

Comparison with the Promoted Links App Part

The Get started with your site web part is almost completely self-contained and you cannot modify the range of tiles that appear, the link URLs, and so on.  All you really can do is add it to a web page, modify its basic web part properties and that's about it.  In contrast, the Promoted Links app part enables you to modify a wide range of parameters, including the number of tiles you want to display, the link URLs, background images, and so on. Promoted Links is an app part.  Moreover, it's part of the Team Collaboration Lists feature and only becomes available when you activate this feature:

This feature is activated by default for some site templates, such as the Team Site template.  Other templates for which it is automatically activated are listed in the table below.  Once this feature is activated, you can then find the Promoted Links app part along with all the other app parts available to your site at the Site Contents page.

Like any other app, you first have to create it. Double-clicking the Promoted Links tile creates a new page just like if you added a list or library app to your site. Once it is created, you add entries to this "list" and configure them.

For example, let's say that I added a new Promoted Links app part to a site, naming it MyPromoted-Links.  Next, I populate it with a couple of items:

As you can see, it's just a type of list.  Then, I would add a reference to that list to a web part page just like you would add a reference to any other site list or library in order to display it on a web part page:

Below, I've add a reference to the MyPromoted-Links app to the landing page of my team site, which still features the Get started with your site web part but now also presents a reference to the Promoted Links app part:

Contrast this with the Get started with your site web part, discussed in the beginning.  As you can see, the respective processes for deploying these two SharePoint objects are very different. They are two completely different objects.

Site Templates Featuring the Get started with your site Web Part

The Get started with your site web part is displayed automatically on the landing page of some types of those newly created site collections for which the Wiki Page Home Page site feature is automatically activated.  Only a few such templates are configured this way.  Here's a listing of the OOTB templates and which ones have this feature activated and which ones don't:

Type	Template                        Activated
Collaboration	Team Site Yes Blog No Developer Site No* Project Site Yes Community Site No (uses Promoted Links app)
Enterprise	Document Center  No eDiscovery Center No Records Center: No Business Intelligence Center No Enterprise Search Center No My Site Host No Community Portal No Basic Search Center No Visio Process Repository         Yes
Publishing	Publishing Portal                No Enterprise Wiki No Product Catalog No

If you don't want to have the Get started with your site web part displayed on the home page of your site, you can easily remove it by simply deleting it from the page.  You can also get rid of it by deactivating the Wiki Page Home Page site feature, which reverts the site's home page back to a web part page.

Remove the web part

1. Navigate to the page presenting the Get started with your site web part.
2. Check out the page (assuming Version history has been enabled on the library containing this page)
3. On the Settings menu, click Edit page.
4. Delete the web part.
5. Save the page.
6. Check the page back in.

   The Getting Started site feature has nothing to do with the Get started with your site web part.  
   

   

   Deactivating the Getting Started site feature does NOT remove the Getting started with your site web part from the landing page.  The Getting started with your site object is just a web part.  It's always available to you, whether or not the Getting Started site feature is activated.

Add the web part

1. Navigate to the target page.
2. Check out the page (assuming Version history has been enabled on the library containing this page)
3. On the Settings menu, click Edit page.
4. Click inside a wiki space or click the Add a Web Part link.
5. In the Categories section, select Media and Content, then select Get started with your site, and the click Add.
6. Click Save.
7. Check the page back in.

References

• Question about "Get Started With Your Web Site" web part
• Remove getting started from home page
• SharePoint 2013 "Get Started with your site" Web Part - FAQs
• Create Custom Promoted Link Tiles in SharePoint 2013
• Promoted links, The New OTB Tile Web Part in SharePoint 2013
• How to remove "Get started with your site"
• SharePoint 2013 Out of Box Web Parts: comprehensive overview of OOTB web parts.
• office 365 :Get started with Apps for Office and SharePoint webpart is missing 

TIP: how to use repadmin to find user info in AD LDS

Tip

This posting presents repadmin commands useful against an AD LDS instance used for a small SharePoint 2007 farm.

Get Time Stamps

Get badPasswordTime, lastLogonTimestamp, pwdLastSet and whenCreated for all users

repadmin /showattr * "CN=...,dc=...,dc=..." /subtree /filter:"(&(objectCategory=Person)(objectClass=user))" /attrs:badPasswordTime,lastLogontimestamp,pwdLastSet,whenCreated /homeserver:serverName:389 > C:\lastlogons.txt

References

• Windows Server 2012: Repadmin
• Windows Server 2003: Repadmin
• Repadmin Requirements, Syntax, and Parameter Descriptions
• Repadmin for Experts
• Repadmin Syntax
• The repadmin command ignores a Windows Server 2008-based RODC when the command is used together with the /syncall switch
• “The LastLogonTimeStamp Attribute” – “What it was designed for and how it works”
• ldap query find active users
• LDAP Query Basics

Notes

• Windows Server 2008 R2