I came across this error message regarding the number of concurrent shells being exceeded while using EMC 2010.
Connecting to the remote server failed with the following error message. The WS-Management service cannot process the request. This user is allowed a maximum of 18 concurrent shells, which has been exceeded. Close existing shells or raise the quota for this user.
The above error message is self explanatory. The user in question has more than 18 concurrent shell connections to the Exchange server, probably in a number of remote sessions to various servers.
The limit is imposed by the throttling policy in Exchange. In my case, the default policy has the maximum PowerShell concurrency set to 18.
How to fix this issue?
- Close any unused/unwanted shell connections
- Edit the throttling policy for the user and raise the limit to a higher value, say 25. Run Set-ThrottlingPolicy Default* –PowerShellMaxConcurrency 25 to set it. If you have a number of throttling policy, you need to find the one that is applied to that user and edit it.
- You can also create a new policy with higher limits and apply it to the user (maybe for all admins).
I came across this error message while uninstalling an Exchange 2010 server.
Setup cannot continue with the uninstall because the cscript process has open files. Close the process and restart setup.
The issue was that the System Center Management service was locking the files.
After stopping the System Center Management service, the readiness check passed and I was able to uninstall Exchange properly.
The Exchange Team has released update rollup 2 for Exchange 2010 SP3.
This update rollup does not apply to Exchange Server 2010 RTM, SP1 or SP2. You should have atleast Exchange 2010 SP3 running.
Download UR2 for Exchange 2010 SP3 and check the description.
The following update rollups have also been released today.
- Update Rollup 11 for Exchange Server 2007 SP3
- Update Rollup 7 for Exchange Server 2010 SP2
- Exchange Server 2013 RTM CU1 MSRC Security bulletin MS13-061
- Exchange Server 2013 RTM CU2 MSRC Security bulletin MS13-061
Check the source for more info.
I came across this strange error while installing Exchange 2010 SP2 on a brand new server running Windows 2008 R2 SP1.
[ERROR] The following error was generated when “$error.Clear(); & $RoleBinPath\ServiceControl.ps1 EnableServices $RoleRoleName.Replace(‘Role’,”)
” was run: “Provisioning layer initialization failed: ‘Failed to reconnect to Active Directory server DC.Domain.Local. Make sure the server is available, and that you have used the correct credentials.’”.
[ERROR] Provisioning layer initialization failed: ‘Failed to reconnect to Active Directory server DC.Domain.Local. Make sure the server is available, and that you have used the correct credentials.’
[ERROR] Failed to reconnect to Active Directory server DC.Domain.Local. Make sure the server is available, and that you have used the correct credentials.
[ERROR] Active Directory server DC.Domain.Local is not available. Please retry at a later time.
[ERROR-REFERENCE] Id=AllRolesCommonFirst___56139ce4432346ecb7936afae4c3a9cc Component=EXCHANGE14:\Current\Release\Shared\Datacenter\Setup
Setup is stopping now because of one or more critical errors.
Finished executing component tasks.
Ending processing Install-BridgeheadRole
[WARNING] Setup has made changes to operating system settings that require a reboot to take effect. Please reboot this server prior to placing it into production.
End of Setup
It was complaining about the DC being not reachable/ online and that the credentials was wrong. I checked both – DC was up and running without any issues and the credentials was correct.
After having a chat with Microsoft support, I came to know that it is a known issue – at least among the Microsoft PSS guys. The problem was that the server had SCOM agent installed and the server was put in maintenance mode during the Exchange installation.
After taking the server off from the maintenance mode in SCOM, the setup ran without any issues! I had installed Exchange on a number of other servers with maintenance mode on in the same environment. So, the question remains – what exactly is maintenance mode for?
Version 2 of rollups have become so common these days
The Exchange Team has released version 2 of the Update Rollup 5 for Exchange 2010 SP2 deployments. The version 1 was released a few weeks back, but was withdrawn due to a DAG related bug.
As usual, any interim updates from Microsoft PSS should be uninstalled and Forefront should be disabled before running the rollup setup.
The required services are automatically restarted when you run the setup.
Download the rollup 5 v2 here and a list of fixes can be read here
Remote access is lost after upgrading Windows 2008 R2 RTM server to SP1! How to fix it?
I know that SP1 for 2008 R2 has been out for a while and any new server builds should have it by default. But not all companies have their builds upgraded to SP1. I came across this issue while patching a 2008 R2 RTM server before installing Exchange 2010.
The issue was that the base RTM build had Security Hotfix 2667402. From the KB article, following paragraph got my attention.
After you install security update 2667402 on a computer that is running Windows 7 or Windows Server 2008 R2, and then you install Service Pack 1 (SP1) for Windows 7 or for Windows Server 2008 R2, the binary version of Rdpcorekmts.dll is 6.1.7600.16952 and not 6.1.7601.17767. In this scenario, you may be unable to create a remote desktop session to control the Windows 7-based or Windows Server 2008 R2-based computer.
This issue occurs because the SP1 binary version of Rdpcorekmts.dll was not originally deployed when security update 2667402 was originally installed.
On June 12, 2012, security update 2667402 was rereleased to address this issue. Customers who are running Windows 7 or Windows Server 2008 R2 should install the reoffered update. This includes those who already successfully installed the update that was originally offered on March 13, 2012.
The fix was to remove the hotfix 2667402 via ILO.
After the server was restarted, I could establish an RDP session. Microsoft recommends to reinstall the same hotfix which was re-released in June 2012.
We might need this info at times, especially when installing Exchange in a large organization with a number of AD sites.
We can easily find this info from the command line. Run the following from your workstation.
Nltest /server:remoteservername /dsgetsite
If you are running the command locally on the server, nltest /dsgetsite will do.