Using PowerCLI to create new role and assign service account used by Citrix XenDesktop & XenApp 7.x service account permissions for vCenter Server 5.1 and 5.5

As demonstrated in one of my previous posts for XenDesktop 5.6:

Using PowerCLI to create new role and assign service account used by Citrix XenDesktop 5.6 permissions for vCenter Server 5.1

http://terenceluk.blogspot.com/2013/04/using-powercli-to-create-new-role-and_9.html

… you can use PowerCLI to create, configure and assign the role required for the XenDesktop service account to access vCenter. This post serves as an update for Citrix XenDesktop and XenApp 7.x environments.

The permissions required for the service account that XenDesktop / XenApp uses to connect to vSphere vCenter can be found at the following URL:

http://support.citrix.com/proddocs/topic/xenapp-xendesktop-76/xad-install-prep-host-vmware.html

The following are the permissions to set for the role if this was to be done manually:

Datastore

• Allocate Space
• Browse Datastore
• Low level file operations

Global

• Manage custom attributes
• Set custom attribute

Network

• Assign Network

Resource

• Assign virtual machine to resource pool

Tasks

• Create task

Virtual Machine > Configuration

• Add or remove device
• Add existing disk
• Add new disk
• Advanced
• Change CPU Count
• Memory
• Remove disk
• Change resource
• Settings

Virtual Machine > Interaction

• Power Off
• Power On
• Reset
• Suspend

Virtual Machine > Inventory

• Create from existing
• Create new
• Register
• Remove

Virtual Machine > Provisioning

• Allow disk access
• Allow virtual machine download
• Allow virtual machine files upload
• Clone virtual machine
• Deploy template
• Mark as virtual machine

Virtual Machine > Snapshot Management

• Create snapshot
• Remove Snapshot
• Revert Snapshot

The cmdlet to execute to automatically create a role named XenApp Service and assign the permissions as displayed in the screenshots above are as follows:

$priv = Get-VIPrivilege -ID

Datastore.AllocateSpace,Datastore.Browse,Datastore.FileManagement,Network.Assign,Resource.AssignVMToPool,Task.Create,VirtualMachine.Config.AddRemoveDevice,VirtualMachine.Config.AddExistingDisk,VirtualMachine.Config.AddNewDisk,VirtualMachine.Config.AdvancedConfig,VirtualMachine.Config.CPUCount,VirtualMachine.Config.Memory,VirtualMachine.Config.RemoveDisk,VirtualMachine.Config.Resource,VirtualMachine.Config.Settings,VirtualMachine.Interact.PowerOff,VirtualMachine.Interact.PowerOn,VirtualMachine.Interact.Reset,VirtualMachine.Interact.Suspend,VirtualMachine.Inventory.Create,VirtualMachine.Inventory.CreateFromExisting,VirtualMachine.Inventory.Delete,VirtualMachine.Inventory.Register,VirtualMachine.Provisioning.Clone,VirtualMachine.Provisioning.DiskRandomAccess,VirtualMachine.Provisioning.GetVmFiles,VirtualMachine.Provisioning.PutVmFiles,VirtualMachine.Provisioning.DeployTemplate,VirtualMachine.Provisioning.MarkAsVM,VirtualMachine.State.CreateSnapshot,VirtualMachine.State.RemoveSnapshot,VirtualMachine.State.RevertToSnapshot,Global.ManageCustomFields,Global.SetCustomField

New-VIRole -Name "XenApp Service" -Privilege $priv

With the role created, you can execute the following cmdlet to assign the domain service account to the vCenter object (top most level):

$rootFolder = Get-Folder -NoRecursion

$myPermission = New-VIPermission -Entity $rootFolder -Principal “NetBIOSdomainName\svc_XenDesktop” -Role “XenDesktop Service” -Propagate:$true

$rootFolder = Get-Folder -NoRecursion

Note that the cmdlets above were tested with Citrix XenDesktop 7.6 and vCenter 5.1.0 Build 1364037.

Exchange 2010 federation calendar sharing reports the error: “The attendee’s server couldn’t be contacted. (Error code: 5016)”

Problem

You’ve completed configuring federation for two Exchange 2010 server organizations and begin testing calendar sharing but noticed that users from one of the Exchange organizations displays the following message when viewing free/busy schedule:

The attendee’s server couldn’t be contacted. (Error code: 5016)

Executing the Test-FederationTrust cmdlet on the Exchange Server in the domain that does not appear to be sharing calendar information displays the following errors:

[PS] C:\Windows\system32>Test-FederationTrust -UserIdentity administrator@domainABC.com

RunspaceId : 44741c0c-b08a-4979-abbc-9317481f9307
Id         : FederationTrustConfiguration
Type       : Success
Message    : FederationTrust object in ActiveDirectory is valid.

RunspaceId : 44741c0c-b08a-4979-abbc-9317481f9307
Id         : FederationMetadata
Type       : Error
Message    : The federation trust doesn't contain the same certificates published by the security token service in its
             federation metadata.

RunspaceId : 44741c0c-b08a-4979-abbc-9317481f9307
Id         : StsCertificate
Type       : Success
Message    : Valid certificate referenced by property TokenIssuerCertificate in the FederationTrust object.

RunspaceId : 44741c0c-b08a-4979-abbc-9317481f9307
Id         : StsPreviousCertificate
Type       : Success
Message    : Valid certificate referenced by property TokenIssuerPrevCertificate in the FederationTrust object.

RunspaceId : 44741c0c-b08a-4979-abbc-9317481f9307
Id         : OrganizationCertificate
Type       : Success
Message    : Valid certificate referenced by property OrgPrivCertificate in the FederationTrust object.

RunspaceId : 44741c0c-b08a-4979-abbc-9317481f9307
Id         : TokenRequest
Type       : Success
Message    : Request for delegation token succeeded.

RunspaceId : 44741c0c-b08a-4979-abbc-9317481f9307
Id         : TokenValidation
Type       : Error
Message    : Failed to validate delegation token.

[PS] C:\Windows\system32>

Solution

While there are probably various reasons why the errors above would be thrown, one of the environments I worked with that had this issue was fixed by rerunning the Manage Federation... wizard as such:

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

http://terenceluk.blogspot.com/2014/10/lync-server-management-shell-2013-does.html

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.

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

Problem

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 Source=SQL.domain.com;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:

at

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:

Solution

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:

https://technet.microsoft.com/en-us/office/dn788954.aspx

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:

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:

Update-AutomaticLinkedClonePool

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

http://pubs.vmware.com/view-52/index.jsp?topic=%2Fcom.vmware.view.integration.doc%2Fview_integration_powershell.5.5.html

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

VMware View 6 HTML 5 access issue with Internet Explorer 9

Problem

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:

Solution

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:

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

Problem

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

Exception:

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:

Solution

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: