Thursday, March 5, 2015

Lync Server Management Shell displays a black screen and does not load

I recently received a call from a client about an issue they had with their Lync Server Management Shell over at their DR location where their Windows Server 2012 R2 Lync Server 2013 Standard DR pool was deployed. What would happen is that an administrator would attempt to start the Lync Server Management Shell and while the window opens, the shell never actually loads:


The first thought I had in mind was an issue I had a while ago where there was something wrong with the shortcut so I asked them to check one of my previous blog posts:

Lync Server Management Shell 2013 does not load and hangs with a black screen on a Windows Server 2012 R2 server

After verifying that the shortcut’s Target was set correctly, I asked them to check what version of Lync Server 2013 they were running and the response I received was that they had forgotten to patch the DR server and that it was still running the RTM version:


Not really knowing whether patching would fix the issue, I went ahead and asked them to do it anyways just in case it did:


I was told a short while later that the patch did indeed fix the issue and that the Lync Server Management Shell now loaded properly. Although I can’t really confirm it, I think the issue was probably due to the shortcut but the patch probably fixed it.

Tuesday, March 3, 2015

Lync Server Persistent Chat service would not start after a new deployment


You’ve just completed deploying Lync Server Persistent Chat but noticed that you are unable to start the service.  Reviewing the Lync Server event logs shows the following errors recorded:

Log Name: Lync Server

Source: LS Persistent Chat Server

Event ID: 53553

Level: Error

The server is not compatible with the database at Data;Initial Catalog=mgc;Integrated Security=SSPI


The follow event logged after the one shown above:

Log Name: Lync Server

Source: LS Persistent Chat Server

Event ID: 53503

Level: Error

Microsoft Lync Server 2013, Persistent Chat could not start due to the following exception:


Microsoft.Rtc.Internal.Chat.Server.ServerCommon.Exceptions.StopServerException: Unexpected DB version.

   at Microsoft.Rtc.Internal.Chat.Server.ServerCommon.TransportServerBase.Initialize()

   at Microsoft.Rtc.Internal.Chat.Server.Channel.Server.ChannelServer.Initialize()

   at Microsoft.Rtc.Internal.Chat.Server.ServerCommon.MgcServiceBase.startServer()

   at Microsoft.Rtc.Internal.Chat.Server.ServerCommon.MgcServiceBase.createAndStartServer().


The service remains stopped or will stop if you attempt to start it:



This issue has actually existed a long time ago but I never wrote a blog post on it as I don’t deploy Lync Persistent Chat that often.  The solution to this problem is to install Cummulative Update 3 (CU3) released sometime in 2013 or simply apply the latest Lync CU update available today from:

Below is a screenshot of the Persistent Chat RTM version build number and the build number for the February 2015 update package:


You will be asked to restart the server after applying the updates.  The Lync Server Persistent Chat service will start once the server is restarted:


Monday, March 2, 2015

Setting the a VMware Horizon View Pool's "Remote Machine Power Policy" configuration via PowerCLI

I’m sure most would agree with me when I say that the performance of the VMware View GUI management console can be extremely frustrating at times. What I’ve tried my best to do over the past few years of working with VMware VDI environments is to use PowerCLI cmdlets as much as possible when performing routine tasks such as recompose operations.  One of the other operations I seem to perform quite a bit recently is configuring the Remote Machine Power Policy during maintenance windows and the 5+ clicks sometimes feel like an eternity so this blog post will serve as one that I can reference to in the future to save myself from going through the GUI.

The Remote Machine Power Policy can be found under the Desktop Pool… tab as shown here:


Using the Get-Pool cmdlet will display the full details of each pool and the attribute representing the Remote Machine Power Policy is powerPolicy:


The following cmdlet can be used to display only the Pool ID and Remote Machine Power Policy:

Get-Pool | fl Pool_ID,powerPolicy


As the pools above are all Automatic Linked Clone Pools, the cmdlet we’ll be using to set the Remote Machine Power Policy will be:


Details of this cmdlet can be found at the following URL:

The options we have for configuring the Remote Machine Power Policy are as follows:

  1. AlwaysOn
  2. RemainOn
  3. Suspend
  4. PowerOff

So to configure the pool to be always turned on, we would execute the following cmdlet:

Update-AutomaticLinkedClonePool -Pool_id <desktopPoolID> -powerPolicy AlwaysOn

What’s unfortunately is that the following cmdlet does NOT allow me to set all the pools to a specific policy even in VMware Horizon View 6:

Get-Pool | Update-AutomaticLinkedClonePool -powerPolicy AlwaysOn

Sunday, March 1, 2015

VMware View 6 HTML 5 access issue with Internet Explorer 9


You attempt to access a VMware View 6 desktop via Blast HTML 5 access with Internet Explorer 9 but receive the following screen where the progress wheel spins on indefinitely:


You’ve verified that HTML Access is enabled:


… as well as the Blast Secure Gateway configuration:



The first thought I had when I ran into this issue was that there was something wrong with the View Connection server because this was an environment that was working just a few days ago but after combing through all of the settings and finding nothing wrong, I went ahead and tried accessing the desktop from the same machine but with the Chrome browser and was able to connect.  Suspecting that it may simply be a browser issue, I went ahead and test the View connection server’s IE browser and was able to connect:


Note that the IE version details are as follows:

Version 10.0.9200.16721
Update Versions: 10.0.10 (KB2879017)

I’m not sure if the issue with IE 9 is related to the recent patches that were installed onto the desktop but I suspect it probably is.  The following is the version details of the problematic IE:

Version 9.0.8112.16421
Update Versions: 9.0.34 (KB3008923)


Note that IE 9 is officially supported as per the following VMware documentation:


Thursday, February 26, 2015

Error deplying a new XenApp 7.6 Machine Catalog using Citrix Machine Creation Services (MCS) with VMware vSphere


You’re attempting to create a new XenApp 7.6 Machine Catalog using Citrix Machine Creation Services (MCS):



Completing the wizard starts the process of cloning the XenApp application server’s master image but you notice that the process does not complete and you are presented with the following error:

An error occurred while preparing the image.


Clicking on the View error details button displays the following error details:

Error Id: XDDS:0DAA3833


Citrix.Console.Models.Exceptions.ProvisioningTaskException An error occurred while preparing the image.

at Citrix.Console.PowerShellSdk.ProvisioningSchemeService.BackgroundTasks.ProvisioningSchemeTask.CheckForTerminatingError(SdkProvisioningSchemeAction sdkProvisioningSchemeAction)

at Citrix.Console.PowerShellSdk.ProvisioningSchemeService.BackgroundTasks.ProvisioningSchemeTask.WaitForProvisioningSchemeActionCompletion(Guid taskId, Action`1 actionResultsObtained)

at Citrix.Console.PowerShellSdk.ProvisioningSchemeService.BackgroundTasks.ProvisioningSchemeCreationTask.StartProvisioningAction()

at Citrix.Console.PowerShellSdk.ProvisioningSchemeService.BackgroundTasks.ProvisioningSchemeCreationTask.RunTask()

at Citrix.Console.PowerShellSdk.BackgroundTaskService.BackgroundTask.Task.Run()

DesktopStudio_ErrorId : UnknownError

ErrorCategory : NotSpecified

ErrorID : FailedToCreateImagePreparationVm

TaskErrorInformation : Terminated

InternalErrorMessage : Either the account is not granted sufficient privilege or disabled or username/password is incorrect


Reviewing the Recent Tasks pane in vCenter shows that the create folder task never begins:



This problem is most likely caused by missing permissions for the service account used by Citrix Studio to connect and execute operations in your vSphere environment. In this particular case, the missing permission was the Advanced permission under Configuration:


The cloning and deployment of the XenApp application server completed successfully once the permission was granted:



Tuesday, February 24, 2015

NetScaler VPX 10.5 build loses network connectivity shortly after restarting the appliance

I recently ran into an issue that had me troubleshooting a NetScaler VPX issue for a good two weeks and while there’s an actual VMware and Citrix KB article about the issue, I hope that this blog post will reach out to anyone who actually follows my blog or twitter so that they are aware of it.


I was informed by a client that the NetScaler HA Pair I deployed over a year ago that the Citrix portal published behind it no longer worked and when I logged on, I noticed that I was unable to log into the management GUI of the NetScaler.  What I would basically get is the login page and once I type in the credentials and attempt to log in, I would see a white page indicating it’s loading and eventually fail after a very long time.

Attempting to ping the device would either flat out no longer respond or exhibit drop packets shown in the following screenshot:


Logging onto the console and attempting to ping other servers on the same subnet would fail but pinging the NetScaler VPX’s own IP address would work.  A quick restart of the NetScaler would return the appliance to what appear to be a regular state for various window of time but will be short lived.

The NetScaler VPX in the environment is version is 10.5 build



After troubleshooting over the week, I finally found the following VMware article:

After applying patches to an ESXi 5.1/5.5 host, Citrix NetScaler virtual machine with e1000 vNIC loses network connectivity (2092809)

… and the following Citrix article:

NetScaler VPX Loses Network Connectivity on VMware ESXi 5.1.0 2191751 and VMware ESXi 5.5 2143827

What I found out shortly after asking was that the ESXi hosts were recently updated to ESXi 5.1 Update 3 which supersedes the Patch 5 build that VMware and Citrix indicates would cause the NetScaler to lose its network connectivity.

I can confirm that the workaround as outlined in the Citrix KB as well as updating the appliance to 10.5 build 55.8 resolves the issue.

Monday, February 23, 2015

Presenting PowerPoint presentation from Lync 2013 fails with: “Some presenting features are unavailable due to server connectivity issues.”

I’ve noticed that I get asked at least once every few months to look at why sharing PowerPoint presentations in a new Lync Server 2013 deployment with Office Web Apps would fail with the error message:

Some presenting features are unavailable due to server connectivity issues.



If you try to share the same PowerPoint .pptx presentation, you would notice that the file was successfully loaded as indicated by the following message:

This File is Already in the Meeting

Rename and Attach


You’ve also confirmed that lal the Lync Server services have been started:


What I’ve noticed is that 9 out of the 10 times I get called for this is because .NET Framework 3.5 Features is not installed on the server:


This component is required for the Office Web Apps server when it is installed on either a Windows Server 2012 R1 or R2 server:


Hope this helps anyone who may run into this issue as there isn’t really a specific error logged in the events that points to this.