Getting this error in set a condition action while publishing a workflow

You’ll need to navigate to the drive where your SharePoint Web installation is installed on. For instance, if you made a Web App on port 80 (and that’s where the Workflow in question that is no longer working is located), then the following directory might work:

C:\inetpub\wwwroot\wss\VirtualDirectories\80‍

Inside of that directory, you will find a file called “web.config”

(I suggest making a BACKUP of this file if you haven’t already. Just copy it somewhere safe)

Inside of that file (edit in notepad, notepad++, or whatever editor you choose), you will find a bunch of xml. It’ll be faster if you just search for the following line:

<System.Workflow.ComponentModel.WorkflowCompiler>‍

Once you have found that, you will look for the following child nodes:

<authorizedTypes>
      <targetFx version="v4.0">‍‍

(your targetFx may or may not have the version attribute on it… it doesn’t matter)

directly after the targetFx node, you should be able to add the following line

<authorizedType Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System.CodeDom" TypeName="*" Authorized="True"/>‍

 

The Synchronization service won’t start in sharepoint 2013

Needless to say that User profile problems are more than endless, i had some really strange behavior of the Synchronization service when post configuring the User profile Service Application which won’t start no matter what.

Note : The client has sharepoint 2013 and SQL server 2014.

I start digging into the ULS logs as usual and i got this message:

[Date and Time] OWSTIMER.EXE (0x1DA0) 0x1DA4 SharePoint Portal Server User Profiles 9i1w Medium ILM Configuration

ILM Configuration: Configuring database
ILM Configuration: Error ‘ERR_CONFIG_DB’.
UserProfileApplication.SynchronizeMIIS: Failed to configure MIIS post database, will attempt during next rerun. Exception: System.Configuration.ConfigurationErrorsException: ERR_CONFIG_DB
at Microsoft.Office.Server.UserProfiles.Synchronization.ILMPostSetupConfiguration.ValidateConfigurationResult(UInt32 result)
at Microsoft.Office.Server.UserProfiles.Synchronization.ILMPostSetupConfiguration.ConfigureMiisStage2()
at Microsoft.Office.Server.Administration.UserProfileApplication.SetupSynchronizationService(ProfileSynchronizationServiceInstance profileSyncInstance).

Note : Keep in mind for UPA Config db means Synchronization DB as all the configuration details is stored there.

I start searching over the internet and it turn out to be a BUG coming from the fact that sharepoint 2013 has some compatibility problems with SQL Server 2014.

SOLUTION:

If you use SQL server 2014 to host the Sync DB or Moved your Databases to SQL 2014 ( Sharepoint 2013 ) , then there is a known issues & you need to Update to April 2014 CU or above for Sharepoint 2013 , https://support.microsoft.com/en-us/kb/2760265

Issue that this hotfix package fixes

If you have Microsoft SQL Server 2014, you cannot run profile synchronization in SharePoint Server 2013 SP1 by using the Forefront Identity Management engine.

UserProfileApplication.SynchronizeMIIS: Failed to configure ILM, will attempt during next rerun. Exception: System.Data.SqlClient.SqlException

Run SharePoint Management Shell as Farm Admin

$sync_db = “PROD_SA_UPS_Sync”

$ups_service_app_name = “User Profile Service”

net stop sptimerv4

$syncdb=Get-SPDatabase | where {$_.Name -eq $sync_db}

$syncdb.Unprovision()

$syncdb.Status=’Offline’

$ups = Get-SPServiceApplication  | where {$_.Displayname -eq $ups_service_app_name }

$ups.ResetSynchronizationMachine()

$ups.ResetSynchronizationDatabase()

$syncdb.Provision()

net start sptimerv4

Start the UserProfileSyncService again

ERR_config_Db while starting the UPA Synchronization service in SharePoint 2010/2013

Post configuring the User profile Service Application , You need to Start the Synchronization service if you intended to use ForeFront Identity Manager Component in Sharepoint 2010/2013 which provides abilities to Import / Export data from a variety of Directory sources & Augment profile data from Additional Sources like BCS etc. The sync service Startup has many known issues & bunch of issues which might cause the Sync Service startup failure .

This Post is to provide causes of Event ID 9i1w “ERR_Config_Db” as seen in ULS logs post trying to start the Sync Service

[Date and Time] OWSTIMER.EXE (0x1DA0) 0x1DA4 SharePoint Portal Server User Profiles 9i1w Medium ILM Configuration

ILM Configuration: Configuring database
ILM Configuration: Error ‘ERR_CONFIG_DB’.
UserProfileApplication.SynchronizeMIIS: Failed to configure MIIS post database, will attempt during next rerun. Exception: System.Configuration.ConfigurationErrorsException: ERR_CONFIG_DB
at Microsoft.Office.Server.UserProfiles.Synchronization.ILMPostSetupConfiguration.ValidateConfigurationResult(UInt32 result)
at Microsoft.Office.Server.UserProfiles.Synchronization.ILMPostSetupConfiguration.ConfigureMiisStage2()
at Microsoft.Office.Server.Administration.UserProfileApplication.SetupSynchronizationService(ProfileSynchronizationServiceInstance profileSyncInstance).

Note : Keep in mind for UPA Config db means Synchronization DB as all the configuration details is stored Here .

Possible Cause 1: This is due to insufficient privileges for the SharePoint Farm Account on the Sync DB (not the Config DB!). You need to add the farm account to the Sync DB users as DBO with a default schema of DBO and then start UPS again.

Possible Cause 2: Incorrect Pre-requisites installed , i.e SQL server Native Client 2012 /2014 is installed , while the Requirement is to have a SQL 2008 /2008 Sp1 . Details here : http://technet.microsoft.com/en-us/library/cc262485.aspx#reqOtherCap

Possible Cause 3: If you use SQL server 2014 to host the Sync DB or Moved your Databases to SQL 2014 ( Sharepoint 2013 ) , then there is a known issues & you need to Update to April 2014 CU or above for Sharepoint 2013 , https://support.microsoft.com/en-us/kb/2760265

Possible Cause 4: Connectivity issues to SQL server , like Wrong Alias . Start –>Run–>Cliconfg to check & configure aliases

Possible cause 5: Using FDQN of SQL server while creating the SharePoint server Farm instead of NetBIOS name .

Possible Cause 6: Triggers configured on the SQL server to disable adding new databases or modifications

Possible Cause 7: Auto Update statistics is disabled in SQL server

In SQL Management Studio, right-click on the Sync database, choose Properties, and click on the Options page.  “Auto Update Statistics” is in the Automatic section, set the value to True.

View the administrator audit log

In Exchange Online, you can use the Exchange admin center (EAC) to search for and view entries in the administrator audit log. The administrator audit log records specific actions, based on Exchange Online PowerShell cmdlets, performed by administrators and users who have been assigned administrative privileges. Entries in the administrator audit log provide you with information about what cmdlet was run, which parameters were used, who ran the cmdlet, and what objects were affected.

 Note

Administrator auditing logging is enabled by default.
The administrator audit log doesn’t record any action that’s based on an Exchange Online PowerShell cmdlet that begins with the verbs Get, Search, or Test.
Audit log entries are kept for 90 days. When an entry is older than 90 days, it’s deleted.

What do you need to know before you begin?

• Estimated time to complete: 5 minutes
• You need to be assigned permissions before you can perform this procedure or procedures. To see what permissions you need, see the “View reports” entry in the Feature Permissions in EOP topic.
• As previously stated, administrator audit logging is enabled by default. To verify that it’s enabled, you can run the following command.

Get-AdminAuditLogConfig | Format-List AdminAuditLogEnabled

In Exchange Server, you can enable administrator audit logging if it’s disabled by running the following command.

Set-AdminAuditLogConfig -AdminAuditLogEnabled $True

• In Exchange Online Protection and Exchange Online, administrator audit logging is always enabled. It can’t be disabled.
• For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard shortcuts for the Exchange admin center.

Use the EAC to view the administrator audit log

1. In the EAC, go to Compliance management > Auditing, and choose Run the admin audit log report.
2. Choose a Start date and End date, and then choose Search. All configuration changes made during the specified time period are displayed, and can be sorted, using the following information:
   • Date: The date and time that the configuration change was made. The date and time are stored in Coordinated Universal Time (UTC) format.
   • Cmdlet: The name of the cmdlet that was used to make the configuration change.
   • User: The name of the user account of the user who made the configuration change.

     Up to 5000 entries will be displayed on multiple pages. Specify a smaller date range if you need to narrow your results. If you select an individual search result, the following additional information is displayed in the details pane:

   • Object modified: The object that was modified by the cmdlet.
   • Parameters (Parameter:Value): The cmdlet parameters that were used, and any value specified with the parameter.
3. If you want to print a specific audit log entry, choose the Print button in the details pane.

How do you know this worked?

If you’ve successfully run an administrator audit log report, configuration changes made within the date range you specify are displayed in the search results pane. If there are no results, change the date range and then run the report again.

 Note

When a change is made in your organization, it may take up to 15 minutes to appear in audit log search results. If a change doesn’t appear in the administrator audit log, wait a few minutes and run the search again.

Use Upgrade Advisor to Prepare for Upgrades

SQL Server Upgrade Advisor helps you prepare for upgrades to SQL Server 2014. Upgrade Advisor analyzes installed components from earlier versions of SQL Server, and then generates a report that identifies issues to fix either before or after you upgrade.

How Upgrade Advisor Works

When you run Upgrade Advisor, the Upgrade Advisor Home page appears. From the Home page, you can run the following tools:

• Upgrade Advisor Analysis Wizard
• Upgrade Advisor Report Viewer
• Upgrade Advisor Help

The first time that you use Upgrade Advisor, run the Upgrade Advisor Analysis Wizard to analyze SQL Server components. When the wizard finishes the analysis, view the resulting reports in the Upgrade Advisor Report Viewer. Each report provides links to information in Upgrade Advisor Help that will help you fix or reduce the effect of the known issues.

Upgrade Advisor Analysis

Upgrade Advisor analyzes the following SQL Server components:

• Database Engine
• Analysis Services
• Reporting Services
• Integration Services

The analysis examines objects that can be accessed, such as scripts, stored procedures, triggers, and trace files. Upgrade Advisor cannot analyze desktop applications or encrypted stored procedures.

Output is in the form of an XML report. View the XML report by using the Upgrade Advisor report viewer.

How to Install and Run Upgrade Advisor

The location where you install SQL Server Upgrade Advisor depends on what you will be analyzing. Upgrade Advisor supports remote analysis of all supported components except Reporting Services. If you are not scanning instances of Reporting Services, you can install Upgrade Advisor on any computer that can connect to your instance of SQL Server, and that meets the Upgrade Advisor prerequisites. For more information, see Supported Version and Edition Upgrades. If you are scanning instances of Reporting Services, you must install Upgrade Advisor on the report server.

Upgrade Advisor is available in a feature pack.

Prerequisites for installing and running Upgrade Advisor are as follows:

• Windows Server 2008 SP2, Windows 7 SP1, and Windows Server 2008 R2 SP1.
• Windows Installer beginning with version 4.5. You can install Windows Installer from the Windows Installer Web site.
• Microsoft .NET Framework 4. .NET Framework 4 is available on the SQL Server 2014 product media, and from the .NET Framework 4 download page.
  • To install the .NET Framework 4 from the SQL Server 2014 media, locate the root of the disk drive. Then, double-click the \redist folder, double-click the DotNetFrameworks folder, and run dotNetFx40_Full_x86_x64.exe (for 32-bit operating systems or for 64-bit operating systems).

To install Upgrade Advisor from the Web, click the download button on the download page. You can then run installation immediately, or save the SQLUA.msi file to run later. If you are installing from the product disc, run SQLUA.msi directly from the product disk.

After you install Upgrade Advisor, you can open it from the Start menu:

• Click Start, point to All Programs, point to Microsoft SQL Server 2014, and then click SQL Server 2014 Upgrade Advisor.

For more information, see the Upgrade Advisor documentation included in the Upgrade Advisor download and the SQL Server 2014 Release Notes.

IIS Application Pool Crash and Debug Diag

Introduction

If you observe either of the following events under the system logs in Event Viewer, then this article is meant for you.

A process serving application pool ‘%1’ suffered a fatal communication error with the Windows Process Activation Service. The process id was ‘%2’. The data field contains the error number.

A process serving application pool ‘%1’ terminated unexpectedly. The process id was ‘%2’. The process exit code was ‘%3’.

This is a clear indication of an application pool crash issue wherein something went wrong within the application and the application pool had to be terminated. Once the application pool is terminated, its corresponding w3wp process is also terminated. Hence, if you have saved any cache/sesson based information within the w3wp process, it gets completely wiped out.

Ideally, when an application pool crashes, in order to honor the incoming requests, a new w3wp process gets spawned up automatically. However, if the application pool crashes more than 5 times within a period of 5 minutes, then the application pool goes into a stopped state. You will have to restart the application pool manually to get it up and running. You will observe the following event under system logs in Event Viewer if something similar happens.

Application pool ‘%1’ is being automatically disabled due to a series of failures in the process(es) serving that application pool.

You can modify this setting under “Rapid Fail Protection” section present under Advanced settings of the respective application pool. It is “Enabled” by Default.

Capture Dumps

Now that we know that our application pool has crashed, the next step is to determine why exactly it crashed. In order to determine this, we will have to capture a dump of the w3wp process just before it terminates. There are multiple ways to do this. You can set up WER, procdump and Debug Diag to capture a crash dump. In this article, I will discuss only the Debug Diag  way of capturing data.

Debug Diag

This is by far the easiest and the most sophisticated tool to capture a crash dump of an application pool. This is how we set it up. You can download it from here.

Launch debug diag and select “crash” rule.

Select “A specific IIS web application pool”

Select the specific application pool which is crashing.

You might also receive a pop up indicating that the IIS management compatibility feature is not installed and that the application pools will not be listed. Not to worry ! Just click on OK and type in the application name manually in the above window.

Select “Breakpoint”

Click on “Add breakpoint”

Click on “Ntdll!ZwTerminateProcess” under Breakpoint such that it is selected as the Breakpoint Expression. Change Action Type to “Full userdump” and set Action Limit to 10 and click on OK. 

Action Type indicates the type of dump that would be captured. A mini user dump will not provide complete information of the issue as it captures very minimal data of the w3wp process.

Action Limit indicates the number of dumps that this rule will capture.

Click on Save and close

Click on Next to activate the breakpoint

Click on “Next”

In the above section, you can change the path where the dumps will be stored. The size of each dump file will be the same as that consumed by w3wp process in the memory. So, keeping that in mind, place the dumps in a drive that has enough free disk space.

Click on “Finish” to activate the Rule.

You will now see that the crash rule is in active state and the “Userdump Count” is 0. As soon as the issue occurs, the dump count will increase and a corresponding dump file will be generated.

PS: A normal recycle of the application pool will also trigger a dump. This is because when the application pool recycles, its corresponding w3wp process’s PID changes and hence a dump gets generated. This is a false positive dump and will not help in the analysis of the application pool crash issue. So whenever you see an increment in the userdump count, check the event logs to see if the above mentioned crash events have occurred. If yes, then the dump that has been captured is correct.

Dump Analysis

Once the dump is captured, you can use the Debug Diag Analysis executable to analyse the captured crash dump. Just a “double click” on the dump will also work. Make sure you have the symbol path set right. To check this, select Tools –> Options and settings and make sure your “Symbol Search Path for Analysis” and “Symbol Search path for Debugging” are set to “srv*c:\symcache*http://msdl.microsoft.com/download/symbols”.

Once the report is generated, you can open it in IE and understand the call stack of the thread that triggered the Breakpoint Expression. Read the call stack from bottom to top and figure out which method or component triggered the application pool to crash

Hope this helps 🙂

Repair a cache host

During installation, configuration, or maintenance activities, the Distributed Cache service might enter a non-functioning state. Evidence of a malfunctioning Distributed Cache service will appear in Health Rules in Central Administration, or when users use features in SharePoint Server that rely on the Distributed Cache. For example, the Newsfeed on a user’s My Site will start reporting errors. Also, administrators might receive the error message “cacheHostInfo is null ” when they run SharePoint Management Shell cmdlets to manage the Distributed Cache service.

There are two steps to repair a cache host.

On the non-functioning Distributed Cache host, use the following procedures to restore the Distributed Cache host.

1. At the SharePoint Management Shell command prompt, run the Remove-SPDistributedCacheServiceInstance cmdlet.
2. At the SharePoint Management Shell command prompt, run the Add-SPDistributedCacheServiceInstance cmdlet.

• At the SharePoint Management Shell command prompt, type the following syntax.

$instanceName =”SPDistributedCacheService Name=AppFabricCachingService”

$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}

If($serviceInstance -ne $null)
{
$serviceInstance.Delete()
}

• After the Distributed Cache Service has been manually deleted, run step 2 again.

Fine-tune the Distributed Cache service by using a PowerShell script

Monitoring

You can monitor performance counters on the Distributed Cache servers to get a better understanding of cache performance issues. Some of the counters that are typically useful to troubleshoot issues include:

1. %cpu used up by cache service
2. %time spent in GC by cache service
3. Total cache misses/sec – A high value here can indicate your application performance might suffer because it is not able to fetch data from cache. Possible causes for this include eviction and/or expiry of items from cache.
4. Total object count – Gives an idea of how many items are in the cache. A big drop in object count could mean eviction or expiry is taking place.
5. Total client reqs/sec – This counter is useful in giving an idea of how much load is being generated on the cache servers from the application. A low value here usually means some sort of a bottleneck outside of the cache server (perhaps in the application or network) and hence very little load is being placed on cache servers.
6. Total Evicted Objects – If cache servers are constantly evicting items to make room for newer objects in cache, it is usually a good indication that you will need more memory on the cache servers to hold the dataset for your application.
7. Total failure exceptions/sec and Total Retry exceptions/sec

The Distributed Cache service setting for MaxConnectionsToServer is often tuned based on the number of CPUs that are used in the host computer. If, for instance you use multiple cores and then set the MaxConnectionsToServer setting to the same number of CPUs then the computer often uses too much memory and freezes. Similar issues happen when tuning the DistributedLogonTokenCache and DistributedViewStateCache settings. The default setting is 20ms but often exceptions are found when the token caching doesn’t happen in the 20ms setting. Use the following PowerShell scripts to change the settings for max connections and timeouts in SharePoint Server 2016 and SharePoint Server 2013.

To fine-tune the Distributed Cache service by using a PowerShell script

1. Verify that you meet the following minimum requirements:

• See Add-SPShellAdmin.
• You need to read about_Execution_Policies.

2. Copy the following variable declarations, and paste them into a text editor such as Notepad. Set parameter values specific to your organization. Save the file, and name it MaxConnections.ps1.

SharePoint Server 2016 PowerShell script

Add-PSSnapin Microsoft.Sharepoint.Powershell -ea 0

#DistributedLogonTokenCache
$DLTC = Get-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache
$DLTC.MaxConnectionsToServer = 1
$DLTC.requestTimeout = “3000”
$DLTC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache $DLTC

#DistributedViewStateCache
$DVSC = Get-SPDistributedCacheClientSetting -ContainerType DistributedViewStateCache
$DVSC.MaxConnectionsToServer = 1
$DVSC.requestTimeout = “3000”
$DVSC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedViewStateCache $DVSC

#DistributedAccessCache
$DAC = Get-SPDistributedCacheClientSetting -ContainerType DistributedAccessCache
$DAC.MaxConnectionsToServer = 1
$DAC.requestTimeout = “3000”
$DAC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedAccessCache $DAC

#DistributedActivityFeedCache
$DAF = Get-SPDistributedCacheClientSetting -ContainerType DistributedActivityFeedCache
$DAF.MaxConnectionsToServer = 1
$DAF.requestTimeout = “3000”
$DAF.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedActivityFeedCache $DAF

#DistributedActivityFeedLMTCache
$DAFC = Get-SPDistributedCacheClientSetting -ContainerType DistributedActivityFeedLMTCache
$DAFC.MaxConnectionsToServer = 1
$DAFC.requestTimeout = “3000”
$DAFC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedActivityFeedLMTCache $DAFC

#DistributedBouncerCache
$DBC = Get-SPDistributedCacheClientSetting -ContainerType DistributedBouncerCache
$DBC.MaxConnectionsToServer = 1
$DBC.requestTimeout = “3000”
$DBC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedBouncerCache $DBC

#DistributedDefaultCache
$DDC = Get-SPDistributedCacheClientSetting -ContainerType DistributedDefaultCache
$DDC.MaxConnectionsToServer = 1
$DDC.requestTimeout = “3000”
$DDC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedDefaultCache $DDC

#DistributedSearchCache
$DSC = Get-SPDistributedCacheClientSetting -ContainerType DistributedSearchCache
$DSC.MaxConnectionsToServer = 1
$DSC.requestTimeout = “3000”
$DSC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedSearchCache $DSC

#DistributedSecurityTrimmingCache
$DTC = Get-SPDistributedCacheClientSetting -ContainerType DistributedSecurityTrimmingCache
$DTC.MaxConnectionsToServer = 1
$DTC.requestTimeout = “3000”
$DTC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedSecurityTrimmingCache $DTC

#DistributedServerToAppServerAccessTokenCache
$DSTAC = Get-SPDistributedCacheClientSetting -ContainerType DistributedServerToAppServerAccessTokenCache
$DSTAC.MaxConnectionsToServer = 1
$DSTAC.requestTimeout = “3000”
$DSTAC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedServerToAppServerAccessTokenCache $DSTAC

#DistributedFileLockThrottlerCache
$DFLTC = Get-SPDistributedCacheClientSetting -ContainerType DistributedFileLockThrottlerCache
$DFLTC.MaxConnectionsToServer = 1
$DFLTC.requestTimeout = “3000”
$DFLTC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedFileLockThrottlerCache $DFLTC

#DistributedSharedWithUserCache
$DSWUC = Get-SPDistributedCacheClientSetting -ContainerType DistributedSharedWithUserCache
$DSWUC.MaxConnectionsToServer = 1
$DSWUC.requestTimeout = “3000”
$DSWUC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedSharedWithUserCache $DSWUC

#DistributedUnifiedGroupsCache
$DUGC = Get-SPDistributedCacheClientSetting -ContainerType DistributedUnifiedGroupsCache
$DUGC.MaxConnectionsToServer = 1
$DUGC.requestTimeout = “3000”
$DUGC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedUnifiedGroupsCache $DUGC

#DistributedResourceTallyCache
$DRTC = Get-SPDistributedCacheClientSetting -ContainerType DistributedResourceTallyCache
$DRTC.MaxConnectionsToServer = 1
$DRTC.requestTimeout = “3000”
$DRTC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedResourceTallyCache $DRTC

#DistributedHealthScoreCache
$DHSC = Get-SPDistributedCacheClientSetting -ContainerType DistributedHealthScoreCache
$DHSC.MaxConnectionsToServer = 1
$DHSC.requestTimeout = “3000”
$DHSC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedHealthScoreCache $DHSC

SharePoint Server 2013 PowerShell script

Add-PSSnapin Microsoft.Sharepoint.Powershell -ea 0

#DistributedLogonTokenCache
$DLTC = Get-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache
$DLTC.MaxConnectionsToServer = 1
$DLTC.requestTimeout = “3000”
$DLTC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedLogonTokenCache $DLTC

#DistributedViewStateCache
$DVSC = Get-SPDistributedCacheClientSetting -ContainerType DistributedViewStateCache
$DVSC.MaxConnectionsToServer = 1
$DVSC.requestTimeout = “3000”
$DVSC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedViewStateCache $DVSC

#DistributedAccessCache
$DAC = Get-SPDistributedCacheClientSetting -ContainerType DistributedAccessCache
$DAC.MaxConnectionsToServer = 1
$DAC.requestTimeout = “3000”
$DAC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedAccessCache $DAC

#DistributedActivityFeedCache
$DAF = Get-SPDistributedCacheClientSetting -ContainerType DistributedActivityFeedCache
$DAF.MaxConnectionsToServer = 1
$DAF.requestTimeout = “3000”
$DAF.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedActivityFeedCache $DAF

#DistributedActivityFeedLMTCache
$DAFC = Get-SPDistributedCacheClientSetting -ContainerType DistributedActivityFeedLMTCache
$DAFC.MaxConnectionsToServer = 1
$DAFC.requestTimeout = “3000”
$DAFC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedActivityFeedLMTCache $DAFC

#DistributedBouncerCache
$DBC = Get-SPDistributedCacheClientSetting -ContainerType DistributedBouncerCache
$DBC.MaxConnectionsToServer = 1
$DBC.requestTimeout = “3000”
$DBC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedBouncerCache $DBC

#DistributedDefaultCache
$DDC = Get-SPDistributedCacheClientSetting -ContainerType DistributedDefaultCache
$DDC.MaxConnectionsToServer = 1
$DDC.requestTimeout = “3000”
$DDC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedDefaultCache $DDC

#DistributedSearchCache
$DSC = Get-SPDistributedCacheClientSetting -ContainerType DistributedSearchCache
$DSC.MaxConnectionsToServer = 1
$DSC.requestTimeout = “3000”
$DSC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedSearchCache $DSC

#DistributedSecurityTrimmingCache
$DTC = Get-SPDistributedCacheClientSetting -ContainerType DistributedSecurityTrimmingCache
$DTC.MaxConnectionsToServer = 1
$DTC.requestTimeout = “3000”
$DTC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedSecurityTrimmingCache $DTC

#DistributedServerToAppServerAccessTokenCache
$DSTAC = Get-SPDistributedCacheClientSetting -ContainerType DistributedServerToAppServerAccessTokenCache
$DSTAC.MaxConnectionsToServer = 1
$DSTAC.requestTimeout = “3000”
$DSTAC.channelOpenTimeOut = “3000”
Set-SPDistributedCacheClientSetting -ContainerType DistributedServerToAppServerAccessTokenCache $DSTAC

3. Open the SharePoint Management Shell
4. Change to the directory to which you saved the file.
5. At the PowerShell command prompt, type the following command:

./MaxConnections.ps1

Perform a graceful shutdown of the Distributed Cache service by using a PowerShell script

In a SharePoint Server farm, a cache cluster exists when one or more cache hosts run the Distributed Cache service. In a SharePoint Server farm, one cache exists, and the cache spans the cache cluster. An administrator may need to move the cached contents to another cache host when applying updates to the server. To prevent data loss associated with moving the cached contents you need to perform a graceful shutdown of the server using the PowerShell script in the following procedure. The graceful shutdown procedure transfers all cached data from the cache host on which the graceful shutdown procedure is being run on to another cache host in the farm. The transfer process takes 15 minutes or more to run depending on how many items exist in the cache.

To perform a graceful shutdown of the Distributed Cache by using a PowerShell script

Use the following PowerShell script to perform a graceful shutdown of the Distributed Cache server in order to move the cached contents to another cache host. Ensure that you specify the correct node to shutdown and change the script as needed to name the correct parameters for your organization.

1. Verify that you meet the following minimum requirements:

• See Add-SPShellAdmin.
• You must read about_Execution_Policies.

2. Copy the following variable declarations, and paste them into a text editor such as Notepad. Set parameter values specific to your organization. Save the file, and name it GracefulShutdown.ps1.

## Settings you may want to change for your scenario ##
$startTime = Get-Date
$currentTime = $startTime
$elapsedTime = $currentTime – $startTime
$timeOut = 900
Use-CacheCluster
try
{
Write-Host “Shutting down distributed cache host.”
$hostInfo = Stop-CacheHost -Graceful -CachePort 22233 -ComputerName sp2016App.contoso.com
while($elapsedTime.TotalSeconds -le $timeOut-and $hostInfo.Status -ne ‘Down’)
{
Write-Host “Host Status : [$($hostInfo.Status)]”
Start-Sleep(5)
$currentTime = Get-Date
$elapsedTime = $currentTime – $startTime
$hostInfo = Get-CacheHost -HostName SP2016app.contoso.com -CachePort 22233
}
Write-Host “Stopping distributed cache host was successful. Updating Service status in SharePoint.”
Stop-SPDistributedCacheServiceInstance
Write-Host “To start service, please use Central Administration site.”
}
catch [System.Exception]
{
Write-Host “Unable to stop cache host within 15 minutes.”
}

Where sp2016App.contoso.com is the computer domain name of Distributed Cache server you use.

3. Open the SharePoint Management Shell
4. Change to the directory to which you saved the file.
5. At the PowerShell command prompt, type the following command:

./GracefulShutdown.ps1

Change the service account

When the server farm is first configured, the server farm account is set as the service account of the AppFabric Caching service. The Distributed Cache service depends on the AppFabric Caching service. To change the service account of the AppFabric Caching service to a managed account:

1. Create a managed account.
2. Set the Managed account as the service account on the AppFabric Caching service. At the SharePoint Management Shell command prompt, run the following command:

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

Where Domain_name\user_name is the domain name and user name of the SharePoint managed account.