XDDS:6D813B19 – “An error has occurred with the Citrix License Server. Check the license server to make sure it is running, then try again.” on the Search node in Citrix Studio.

The error message “An error has occurred with the Citrix License Server. Check the license server to make sure it is running, then try again.” might be displayed on the Search node in Citrix Studio when user opens or refreshes the node.

Error details:

Error Id: XDDS:6D813B19


Citrix.Console.Common.CitrixAggregateException One or more parallel operations failed

at Citrix.Console.Common.CitrixParallel.InternalForEach[TIn](IEnumerable`1 items, Action`1 operation, Int32 maxSimultaneous)

at Citrix.Console.PowerShellSdk.SiteInformationService.SiteInformationService.Refresh()

at Citrix.Console.Desktops.UI.Mmc.Tabs.VdiMachineTabViewModel.<AddRefreshHandlers>b__4_0(Object s, EventArgs e)

at Citrix.Console.CommonControls.Mmc.SearchNodeTabViewModel`1.<>c__DisplayClass54_0.<PerformSearchInternal>b__0()

at Citrix.Console.CommonControls.ViewModelBase.<>c__DisplayClass90_0.<RunBackgroundTask>b__0(Object s, DoWorkEventArgs e)

Inner Exception:

Citrix.Console.Models.Exceptions.ScriptException An error has occurred with the Citrix License Server. Check the license server to make sure it is running, then try again.

at Citrix.Console.PowerShellInteraction.CmdletExecutionMethods.CreateException[T](ICommonLog logger, ExecutionResults`1 results, ICmdletExecutionHost host)

at Citrix.Console.PowerShellInteraction.CmdletExecutionMethods.Execute[T](ISdkCmdlet`1 sdkCmd, ICmdletExecutionHost host, Boolean allowFailover)

at Citrix.Console.PowerShellSdk.LicensingService.Scripts.GetCertificateScript.RunScript()

at Citrix.Console.PowerShellInteraction.PowerShellScript`1.Run()

at Citrix.Console.PowerShellSdk.SiteInformationService.SiteInformationService.GetLicenseAlert()

at Citrix.Console.PowerShellSdk.SiteInformationService.SiteInformationService.<>c__DisplayClass33_0.<Refresh>b__7()

at Citrix.Console.Common.CitrixParallel.<>c__DisplayClass4_1`1.<InternalForEach>b__0(Object arg)

DesktopStudio_ErrorId : UnknownError

Sdk Error Message : UnknownError

Sdk Error ID : Citrix.PowerShell.LicensingAdminStatus.UnknownError,Citrix.Licensing.Admin.SDK.Commands.GetLicCertificateCommand

ErrorCategory : NotSpecified

DesktopStudio_PowerShellHistory : Get the certificate for the Licensing Service

Date Time

Get-LicCertificate -AdminAddress “https://LICENSE_SERVER_ADDRESS:PORT_NUMBER/”

Get-LicCertificate : UnknownError

+ CategoryInfo : InvalidOperation: (Get-LicCertificate:String) [Get-LicCertificate]、InvalidOperationException

+ FullyQualifiedErrorId : Citrix.PowerShell.LicensingAdminStatus.UnknownError,Citrix.Licensing.Admin.SDK.Commands.GetLicCertificateCommand


  • No Related Posts

7021334: Error VHI 4300 “The scripting manager failed to initialize”

If your symptoms indicate failure with the Java scripting manager, see Recommended Solution for Java Issue and Alternative Solution for Java Issue. If your symptoms indicate failure with the .NET scripting manager, see Solution for .NET Issue.

Recommended Solution for Java Issue

To resolve this issue, set the environment variable vhi_embedded_xmx to a lower value, such as -Xmx512m. However, if a smaller value is already set (from a previous version), try removing the setting or increasing the value instead.


On Windows, set this variable at Control Panel > System and Security > System > Advanced (or Advanced system settings) > Environment Variables > System variables. The exact steps may vary, depending on your operating system version and Control Panel view.

Figure 2. New System Variable dialog

Figure 2. New System Variable dialog

Note: On Windows Server 2003 or Windows XP, to make the environment variable available to the Local System account that runs services, you must restart the system (see http://support.microsoft.com/kb/821761).


On UNIX/Linux, you may need to export the environment variable so that it is available to the process that runs the VHI session server.

Alternative Solution for Java Issue

If you do not have permissions to set system environment variables or restart the system, and are running version 7.1.221 or higher, you can edit JVM configuration files instead. Note: This procedure will need to be repeated after installing any future upgrade or hotfix, as the configuration files will be reset to default values.

  1. Locate your destool.conf and sesssrvr.conf files in the appropriate directory:

Windows: C:Program FilesAttachmateVerastreamHostIntegratoretc

UNIX/Linux: /opt/attachmate/verastream/hostintegrator/etc

  1. Open each file in a text editor.
  2. Locate the following existing line:
  1. Modify the parameter to use a lower value. For example:
  1. Save changes.
  2. Restart the session server service as described in Technical Note 10004. Close and restart any instances of the Design Tool application.

Note: If the system environment variable vhi_embedded_xmx (or vhi_embedded_classpath or vhi_embedded_libpath) are set, they take precedence over the .conf file contents.

Solution for .NET Issue

Ensure that your system has Internet access (such as ability to make outbound connections through a firewall) so it can connect to the system crl.verisign.net (for the Certificate Revocation List at VeriSign).

If you are running version 7.6.44 or earlier and your organization’s policies prohibit Internet access, complete the following steps to disable Authenticode verification:

  1. In a text editor, open the clrscriptserver.exe.config file located in C:Program FilesAttachmateVerastreamHostIntegratorlibdotnet.
  2. In the <runtime> section, insert the following line:
<generatePublisherEvidence enabled="false"/>

For example:


<generatePublisherEvidence enabled="false"/>

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

Note: Beginning in version 7.6.47, this setting already exists by default.

  1. Save changes and restart the Session Server service or Design Tool application. For more information about starting services, see Technical Note 10004.


  • No Related Posts

ATP Endpoint – new features

I need a solution

Is there any more detailed guide or white paper on below features?

e.g what specific rule or signature being used to detect suspicious powershell ? and which part of SEP this signature being added…IPS/ADC?

The following tasks can now be performed in near real-time using EDR 2.0:

  • Delete file

  • Endpoint search

  • Endpoint data recorder search¹ and full and process dumps

  • Ability for ATP to receive data from endpoints about the following events and activities:¹


    • Suspicious PowerShell executions

      Consists of suspicious PowerShell executions

    • Load point changes

      Consists of suspicious modifications to load points

    • Suspicious system activity

      Consists of the suspicious activity events that various rules detected

    • Heuristic detections

      Consists of heuristically-detected events of a certain order of the system activity events that are known to occur when malware is executed

    • Process launch activity

      Consists of most of the total process launch events that are generated


      Selecting this option can place a high demand on network resources.

    • Process terminate activity

      Consists of most of the total of the process terminate events that are generated



  • No Related Posts

Error: “Power State Unknown” “CDS_EVENT_HOSTING_FAILED_POWER_ACTION” in XenDesktop

To update the correct host machine ID on the DDC, complete one of the following solutions:

Solution 1

Restart the Citrix Site services on all the DDCs.

Note: This may result in momentary disruptions of new connections, however current sessions are not affected.

Open PowerShell as admin and run the following commands:

Get-Service Citrix* | Stop-Service -Force

Get-Service Citrix* | Start-Service

Solution 2

This can be caused by changes made on the hypervisor to VM metadata. If the VM’s unique ID has changed then the XenDesktop database may be unaware of this UID mismatch. This process will verify the UID known to XenDesktop for the VMs and compare against the UID provided by the hypervisor.

Warning! Back up the XenDesktop database before completing these actions.

  1. Open DDC using the PowerShell console and run the following commands to display all machine IDs of the virtual machines from the hypervisor. .

    asnp Citrix*$ErrorActionPreference=ContinueGet-ChildItem -Path XdHyp: -force -recurse | ?{ $_.IsMachine } | Out-File –Filepath c:xdhyp.txt
  2. The xdhyp.txt output file contains the correct machine IDs from the hypervisor. Open that file and press Ctrl+F or Edit > Find. Search for the name of the Virtual Machine, in this case the name of the Virtual Machine is PVS0003.

    Example output

    PSPath : Citrix.Host.Admin.V1Citrix.Hypervisor::XDHyp:ConnectionsXenServerPVS0003.vmPSParentPath : Citrix.Host.Admin.V1Citrix.Hypervisor::XDHyp:ConnectionsXenServerPSChildName : PVS0003.vmPSDrive : XDHypPSProvider : Citrix.Host.Admin.V1Citrix.HypervisorPSIsContainer : TrueName : PVS0003FullName : PVS0003.vmObjectType : VmId : 7d1d6004-5319-7a7e-59cb-2662e212a3e5IsContainer : TrueIsMachine : TrueIsSnapshotable : TrueObjectPath : /PVS0003.vmFullPath : XDHyp:ConnectionsXenServerPVS0003.vmIsSymLink : FalseAdditionalData : {}

    Note: The machine ID is as follows:

    Id : 7d1d6004-5319-7a7e-59cb-2662e212a3e5.

    Your result will vary.

  3. Run the following command:

    Get-BrokerMachine -PowerState Unknown

    This identifies the machines that have the unknown power state.

    + Note the “HostedMachineId “ from the output.

    + Now comparing the “ID” from Step1, and the “HostedMachineId “ from this step, You’ll find that the IDs are different.

    + Correct “Id” is from the Step-1 and incorrect value is present in Database (from step-3)

    + We can also verify the same by Browsing the below tables in SQL site database, and confirming the values.

    Chb_Config.Workers >> HostedMachineId >>

    DesktopUpdateManagerSchema.ProvisionedVirtualMachine >> VMId >>

  4. Run the following command to change the XendDesktop Database’s record for the machine ID to match the Hypersvisor’s Machine ID:

    Set-BrokerMachine -MachineName ‘MyDomainMyMachine’ -HostedMachineId [machine ID from preceding output]

    This corrects the HostedMachineId for the problem machines using the ID that was retrieved from xdhyp.txt.

  5. Check Desktop Studio or Desktop Director and refresh the list of results.

    The power state must now match the state indicated in the hypervisor.

Note: It might be necessary to restart the Citrix Broker Service on all DDCs and/or restart the virtual machine.

Solution 3

Remove the affected virtual machines from the Desktop Group in Desktop Studio and add them again.

NOTE: Removing machines from an MCS catalog cannot be reversed. Once the VM is removed you will only be able to add that machine to a catalog of the “Existing” type.

Solution 4

Ensure the SCVMM console version and hotfix level, installed on the DDCs, is the same version and hotfix level as the SCVMM server.

For example: Install the upgraded version of the SCVMM Console, version 8, KB3097539 on both controllers, which matched the SCVMM server hotfix level.

Solution 5

Run “Get-BrokerHypervisorConnection”, and check the output for Hypervisor “state,

If for any hypervisor connection the state is, anything else then ON or OFF,

Then try to put that connection in maintenance mode for few secs and then turn off the maintenance mode again.

User-added image

Solution 6

Understanding of the Broker > Hypervisor communication:

  • The Broker service runs on every Delivery Controller in the site (DDC). It has many subcomponents, one of which is the Hosting Management sub component.
  • The broker service must communicate to the Hypervisor using the VM/Machine ID
  • The UUID/Machine ID of the VM can be obtained by running “Get-BrokerMachine” cmdlet from any of the DDC’s in the site.
  • It needs to match with the BIOS file of the VM on the hypervisor to be managed properly by DDC’s in the Site.


  • If the Certificate is updated on the VSphere server the same needs to be updated on all the DDC’s in the Site. Certificate mismatch can also cause the Broker to change the power states to “Unknown” and Hypervisor connection state to “Unavailable”.
  • If there is a Host/VSphere Server which is put under maintenance or is down for any reasons, the Broker will change the Power state to “Unknown” and Hypervisor connection state to “Unavailable”.
  • If there is an issue with broker service on one controller, broker service from other controller will serve as the Preferred controller to control the Power and pool for the site.

Steps to remediate the situation if the issue occurs:

  • If there is a network or VMware host issue which has corrected itself, the broker service won’t be able to re-establish the communication on its own if the disruption is for a longer period of time. In that case the broker service needs to be restarted on all the DDC’s in the site.
  • Alternatively you may run the command below cmdlet on any of DDC’s using Power Shell.
  • Update-HypHypervisorconnection – LiteralPath “The Actual Path of hypervisor Connection”
  • -LiteralPath of the Hypervisor connection can be obtained by running the below cmdlet on PowerShell of any DDC.

cd Xdhyp:

cd ./Connections

  • for instance: Update-HypHypervisorConnection -LiteralPath “XDHyp:connectionsConnection”
  • Alternatively you may do the following using Studio to update the connection:

Click on Hosting tab on Studio -> Right click the connection -> Click on Edit Connection -> Without making any changes click on OK.


  • No Related Posts

Studio shows “Error: Failed to validate the Central Configuration Service location. You do not have sufficient permissions to administer this Site using Studio.”


1. Use the following PowerShell commands to find the SID of the user account currently in use on the machine where Studio is installed:

$objUser = New-Object System.Security.Principal.NTAccount(“<DomainUserName>”)

$strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])


2. Check if the SID found in step 1 matches with the SID(s) contained in the DAS.Administrator table of the XenApp/XenDesktop Site Database in the SQL server

Perform below steps to find the SID stored in the database:

– Open SQL Management studio >> Connect to SQL server instance

– Expand Databases>> [SiteDatabase] >> Tables >> DAS.Administrators

– Right click on DAS.Administrators > Select Top 1000 Rows.

This will display the SIDs of the Administrator objects configured for the Site.

If the SIDs do not match, then it means that the user account currently in use on the machine where Studio is installed is not a Citrix Administrator account and does not have sufficient permissions to administer the XenApp/XenDesktop Site using Studio.

In that case you need to login in the server with a user account that is a Citrix Administrator.

You can use the following PowerShell commands to find what user account or AD object belongs the SID(s) found in the DAS.Administrators table (Step 2) of the Site Database in the SQL server to then login on the server using that account:

$objSID = New-Object System.Security.Principal.SecurityIdentifier `

(“<SID in question>”)

$objUser = $objSID.Translate( [System.Security.Principal.NTAccount])


In the case that the SIDs match, then it means that the SID of the Citrix Administrator account is corrupted in the database. In that case you will have to delete the SID.


  • No Related Posts

How to Grant XenApp & XenDesktop Access to Your Azure Subscription

In this document we will explore different ways of granting XenApp & XenDesktop access to your Azure subscription. It describes how to connect to Azure Resource Manager in XenApp & XenDesktop using Subscription Scope Service Principals and includes a detailed description of the authentication process.

Azure Service Principals

Support for Azure Resource Manager (ARM) is encapsulated in a component known as the ARM Plugin and it is a standard feature of XenApp & XenDesktop. In order to provision machines in Azure, the ARM Plugin must be granted access to your Azure subscription via a service principal that has been assigned permissions to the relevant Azure resources. A service principal serves the same basic purpose as a user account: it provides the ARM Plugin with an Azure Active Directory identity; credentials for authentication and permissions on Azure resources. Just like user accounts, service principals are configured using Role Based Access Control (RBAC).

Depending on how permissions are defined, we classify service principals as:

  1. Subscription Scope Service Principals; or
  2. Narrow Scope Service Principals

Subscription Scope Service Principals

Subscription Scope Service Principals have Contributor permissions on all resources in the subscription which makes them easy to create and manage. In fact, Citrix Studio automates the process of creating Subscription Scope Service Principals or they can be created manually in PowerShell. Another benefit is that they allow the ARM Plugin to create Azure Resource Groups and completely automate the management of resources. The disadvantage is that the ARM Plugin may have permissions to resources in the subscription that are unrelated to the resources that the ARM Plugin is tasked with managing.

Using the Contributor role allows the ARM Plugin to create, delete, read and write all resources in the subscription, but permissions do not extend to objects in any Azure Active Directory nor are Subscription Scope Service Principals allowed to grant other users or service principals access to resources.

Narrow Scope Service Principals

Narrow Scope Service Principals allow the ARM Plugin access to a limited set of resources defined by you. Azure requires subscription scope permissions in order to create resource groups and the ARM Plugin is therefore unable to create resource groups when using Narrow Scope Service Principals. This means that, in addition to the service principals, you are required to provide a pool of resource groups for each catalog into which machines are to be provisioned.

At the time of writing, Citrix Studio does not support creating Narrow Scope Service Principals or catalogs using Narrow Scope Service Principals so both of these tasks must be performed using PowerShell. However, once a catalog has been created, it can be managed like any other catalog in Studio including adding and deleting machines. If at some point you wish to use an existing Narrow Scope Service Principal with a new pool of resource groups, you must explicitly add permissions to the service principal using PowerShell.

Defining Your Azure Subscription Access Requirements

The techniques and examples in the following sections are intended to demonstrate various options in a reasonably simple manner and may need to be adapted to your particular circumstances. Here are some guidelines to help you define your requirements:

Consider using a Subscription Scope Service Principal if:

  • you want the simplest management experience.
  • you want to avoid using PowerShell and manage everything in Citrix Studio.
  • your Azure subscription is dedicated to a single XenApp & XenDesktop service.
  • you are doing a proof of concept XenApp & XenDesktop installation.
  • your XenApp & XenDesktop administrators have contributor access at Azure subscription scope.

Consider using a Narrow Scope Service Principal if:

  • your Azure subscription is hosting multiple unrelated services.
  • your Azure administrators have different subscription permissions depending on their role.
  • your company has security standards that require access control at a fine-grained level.
  • you have an existing process for creating Narrow Scope Service Principals

It is also worth noting that you can create “child” subscriptions that are billed as part of your primary subscription and refer to the default Azure Active Directory in your primary subscription. This provides another mechanism for controlling access to unrelated resources.

Planning a Narrow Scope Service Principal Catalog

The key decision that must be made before creating a Narrow Scope Service Principal catalog is deciding how many resource groups are required to host the initial and future number of virtual machines. Due to a limitation in the Machine Creation Services that drives the ARM Plugin, it is not possible to add resource groups once a catalog has been created.

Citrix recommends provisioning one catalog per resource group pool.

The ARM Plugin will create the necessary infrastructure in each resource group consisting of storage accounts, security groups, network interfaces, virtual machines etc. Storage accounts are created on demand as needed when and if machines are added to the catalog. This means that the size of a catalog can grow to an upper limit set by the size of the resource group pool and Azure subscription quotas. Once a storage account has been created, it is not deleted until the catalog is deleted. Since any virtual machine can be deleted, it is possible to end up with empty storage accounts. This however is rare because virtual machines tend to be randomly distributed over the available storage accounts so machines have to be tediously selected by inspecting the content of storage accounts in order to deliberately empty a storage account.

Azure limits the number of virtual machines in a resource group to 800, but the ARM plugin uses a different measure. A standard Azure disk has a limit of 500 IO operations per second (IOPS) and a standard storage account has an IOPS limit of 20,000. For this reason, the ARM Plugin provisions no more than 40 machines to a storage account. This limit is currently applied to both standard and premium storage. In addition, the ARM Plugin will create no more than 19 storage accounts in a resource group.

The basic formula for calculating the number of resource groups based on the maximum number of machines is therefore:

Number of resource groups = ceiling( Maximum number of machines / (40 * 19) )

The ARM Plugin assumes that it has exclusive use of the resource group pool, i.e., there should be no user created resources in any of the specified resource groups.

Basics of Azure Role Based Access Control (RBAC)

Access to Azure resources are granted by assigning an RBAC role to a service principal at a certain scope where scope can be a subscription, a resource group or a specific resource. Resources are arranged in a containment hierarchy and the permissions defined by the role apply to all resources below the scope where it is applied. For example, a role applied on a subscription is applied to all resources in the subscription and a role applied to a resource group is applied to all resources contained in the resource group.

An implication of the Azure resource hierarchy is that only service principals with subscription scope permissions are allowed to create resource groups. This is not ideal because it prevents applications like the ARM Plugin from creating resource groups on demand to logical group and manage resources unless they have broad permissions on the full subscription.

Azure has a large selection of built in roles and additionally supports the definition of custom roles.

Refer to the Microsft KB Article for more information on Custom Roles in Azure RBAC.

Creating a Subscription Scope Service Principal

This example shows how to create a Subscription Scope Service Principal. The details can subsequently be to used to create an Azure connection in Citrix Studio by electing to use an existing service principal or an Azure connection can be created manually in PowerShell.


[string]$applicationName = “SubscriptionScopeSP”,




$application = New-AzureRmADApplication -DisplayName $applicationName -HomePage “https://localhost/$applicationName” `

-IdentifierUris “https://$applicationName” -Password $applicationPassword

New-AzureRmADServicePrincipal -ApplicationId $application.ApplicationId

# Wait for the service principal to become available

Start-Sleep -s 60

New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $application.ApplicationId `

-scope “/subscriptions/$subscriptionId”

Write-Host (“Application ID: ” + $application.ApplicationId)

Creating a Basic Narrow Scope Service Principal

In this section we will create the simplest possible Narrow Scope Service Principal where permissions are assigned at the resource group scope.

The ARM Plugin needs permission to the following resources:

  1. The master image VHD

  2. The virtual network for the machines

  3. The resource groups into which the machines are to be provisioned.

To simplify the script, we make an assumption that Contributor access can be granted at resource group scope. This means that the ARM Plugin will have contributor permissions on the resource group where the image VHD is stored, the resource group that contains the virtual network and the resource group pool where the machines are to be provisioned.


[string]$applicationName = “BasicNarrowScopeSP”,





$application = New-AzureRmADApplication -DisplayName $applicationName -HomePage “https://localhost/$applicationName” `

-IdentifierUris “https://$applicationName” -Password $applicationPassword

New-AzureRmADServicePrincipal -ApplicationId $application.ApplicationId

# Wait for the service principal to become available

Start-Sleep -s 60

New-AzureRmRoleAssignment -RoleDefinitionName Citrix-Network-Usage-Reader -ServicePrincipalName $application.ApplicationId `

-scope “/subscriptions/$subscriptionId/”

foreach ($rg in $resourceGroups)


New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $application.ApplicationId `

-scope “/subscriptions/$subscriptionId/resourcegroups/$rg”


Write-Host (“Application ID: ” + $application.ApplicationId)

Creating a Narrow Scope Service Principal using Custom Roles

Azure comes with a large set of built in RBAC roles and we made use of the Contributor role in the previous section. As noted, that gave the ARM Plugin slightly broader permissions than strictly required. In this section, we will define a custom role and further tighten access. If desired, access can be completely locked down using additional custom roles and applying roles directly to the image and network resources.

The required permissions are subject to change as we continue to improve the ARM Plugin and add new features. We will use the permissions listed below and define a custom role for granting access to the virtual network and the master image at the resource group scope.

The master image VHD

For catalog creation:

  • Microsoft.Storage/storageAccounts/read
  • Microsoft.Storage/storageAccounts/listKeys/action

For Future Citrix Studio support:

  • Microsoft.Resources/subscriptions/resourceGroups/read

The virtual network for the machines

  • Microsoft.Network/virtualNetworks/read
  • Microsoft.Network/virtualNetworks/subnets/join/action

The resource groups into which the machines are to be provisioned

We could create another custom role with the following permissions, but to keep the example simple, we will continue to use the Contributor role for the machine resource groups. These resource groups should not contain any resources not created by the ARM plugin and using the contributor role makes it less likely that changes to the ARM plugin will require changes to the service principal.

  • Microsoft.Compute/virtualMachines/*

  • Microsoft.Network/networkInterfaces/*

  • Microsoft.Network/networkSecurityGroups/*

  • Microsoft.Resources/deployments/*

  • Microsoft.Resources/subscriptions/resourceGroups/read

  • Microsoft.Storage/storageAccounts/*

  • Microsoft.Storage/storageAccounts/listKeys/action

XenApp & XenDesktop Custom Access Roles

We create a new custom role by first defining it in JSON:

{ "Name": "Citrix-Custom-Reader", "Description": "Grants access to Citrix XenDesktop images and virtual networks.", "Actions": [ "Microsoft.Storage/storageAccounts/read", "Microsoft.Storage/storageAccounts/listKeys/action", "Microsoft.Network/virtualNetworks/read", "Microsoft.Network/virtualNetworks/subnets/join/action" ], "NotActions": [ ], "AssignableScopes": [ "/subscriptions/<YOUR-SUBSCRIPTION-ID>" ]}

We can now create the role by referencing the JSON definition:

New-AzureRmRoleDefinition -InputFile citrix-custom-reader.json

Finally, we can use our new custom role when creating a service principal:

param([string]$applicationName = "NarrowScopeSP",[Parameter(Mandatory=$true)][string]$applicationPassword,[Parameter(Mandatory=$true)][string]$subscriptionId,[Parameter(Mandatory=$true)][string[]]$machineResourceGroups,[Parameter(Mandatory=$true)][string]$imageResourceGroup,[Parameter(Mandatory=$true)][string]$networkResourceGroup)$application = New-AzureRmADApplication -DisplayName $applicationName -HomePage "https://localhost/$applicationName" `-IdentifierUris "https://$applicationName" -Password $applicationPasswordNew-AzureRmADServicePrincipal -ApplicationId $application.ApplicationId# Wait for the service principal to become availableStart-Sleep -s 60New-AzureRmRoleAssignment -RoleDefinitionName Citrix-Network-Usage-Reader -ServicePrincipalName $application.ApplicationId `-scope "/subscriptions/$subscriptionId/"foreach ($rg in $machineResourceGroups){ New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $application.ApplicationId ` -scope "/subscriptions/$subscriptionId/resourcegroups/$rg"}New-AzureRmRoleAssignment -RoleDefinitionName Citrix-Custom-Reader -ServicePrincipalName $application.ApplicationId `-scope "/subscriptions/$subscriptionId/resourcegroups/$imageResourceGroup"New-AzureRmRoleAssignment -RoleDefinitionName Citrix-Custom-Reader -ServicePrincipalName $application.ApplicationId `-scope "/subscriptions/$subscriptionId/resourcegroups/$networkResourceGroup"Write-Host ("Application ID: " + $application.ApplicationId)

Creating XenApp & XenDesktop Azure Connections

While it is reasonable to create a XenApp & XenDesktop Azure connection in Citrix Studio using an existing service principal, it is equally reasonable to create the connection in PowerShell.

Here is an example of creating a connection in Powershell. This is particulary the case as, at the time of writing, Studio does not support creating catalogs using connections based on a narrow scope service principal.

param([string]$connectionName = "AzureConnection",[Parameter(Mandatory=$true)][string]$applicationId,[Parameter(Mandatory=$true)][string]$applicationPassword,[Parameter(Mandatory=$true)][string]$subscriptionId,[Parameter(Mandatory=$true)][string]$subscriptionName,[Parameter(Mandatory=$true)][string]$tenantId)Add-PsSnapin Citrix*$customProperties = @"<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Property xsi:type="StringProperty" Name="AuthenticationAuthority" Value="https://login.microsoftonline.com/"/> <Property xsi:type="StringProperty" Name="ManagementEndpoint" Value="https://management.azure.com/"/> <Property xsi:type="StringProperty" Name="StorageSuffix" Value="core.windows.net"/> <Property xsi:type="StringProperty" Name="TenantId" Value="$tenantId"/> <Property xsi:type="StringProperty" Name="SubscriptionId" Value="$subscriptionId"/> <Property xsi:type="StringProperty" Name="SubscriptionName" Value="$subscriptionName"/></CustomProperties>"@$connection = New-Item -ConnectionType "Custom" -CustomProperties $customProperties -HypervisorAddress @("https://management.azure.com/") `-Path @("XDHyp:Connections$connectionName") -Persist -PluginId "AzureRmFactory" -Scope @() `-SecurePassword (ConvertTo-SecureString -AsPlainText -Force $applicationPassword) -UserName $applicationIdNew-BrokerHypervisorConnection -HypHypervisorConnectionUid $connection.HypervisorConnectionUid

At this point you need to add resources to the connection which again can be done in Studio or in PowerShell.

Creating XenApp & XenDesktop Catalogs

The following example uses the Citrix PowerShell Snap-Ins to create a XenApp & XenDesktop catalog.

As Narrow Scope Service Principals do not allow the ARM Plugin to create resource groups, we must:

  1. Create a pool of resource groups.
  2. Assign the service principal permissions on all the resource groups in the resource group pool.
  3. List each resource group in the resource group in a custom property when creating the provisioning scheme.

The custom property is named ResourceGroups and the value is a comma separated list of resource group names. An example of how to define this custom property is shown below.

Note that only resource groups that are intended for machines should be listed in the custom property. The resource group(s) where the image and/or virtual network is located should not be included. If they are specified, the ARM plugin will attempt to provision machines into those resource group which will likely cause some unintended behaviour.

In this example, machines will be provisioned in two resource groups named xd-sales-1 and xd-sales-2.

Add-PsSnapin Citrix*# The hosting unit name is the name of the Azure connection resources that should be used for this catalog$hostingUnitName = "AzureHostingUnit"$domain = "citrix.local"$controllerAddress = ("ddc." + $domain)$adminAddress = ($controllerAddress + ":80")$catalogName = "catalog-name"$network = "network-resource-group.resourcegroupnetwork-name"$subnet = "subnet-name"$serviceOffering = "Standard_A4"$template = "image-resource-group.resourcegroupimagestorage.storageaccountimages.containerimage-name.vhd"$customProperties = @"<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Property xsi:type="StringProperty" Name="StorageAccountType" Value="Standard_LRS" /> <Property xsi:type="StringProperty" Name="ResourceGroups" Value="xd-sales-1, xd-sales-2" /></CustomProperties>"@$identityPool = New-AcctIdentityPool -AdminAddress $adminAddress -AllowUnicode -Domain $domain ` -IdentityPoolName $catalogName -NamingScheme "vm-#" -NamingSchemeType "Numeric" -Scope @()$brokerCatalog = New-BrokerCatalog -AdminAddress $adminAddress -AllocationType "Random" -IsRemotePC $False ` -MinimumFunctionalLevel "L7_9" -Name $catalogName -PersistUserChanges "Discard" -ProvisioningType "MCS" -Scope @() ` -SessionSupport "MultiSession"Write-Host $brokerCatalog$provScheme = New-ProvScheme -AdminAddress $adminAddress -CleanOnBoot -CustomProperties $customProperties ` -HostingUnitName $hostingUnitName -IdentityPoolName $catalogName ` -MasterImageVM "XDHyp:HostingUnits$hostingUnitNameimage.folder$template.vhd" ` -NetworkMapping @{"0"="XDHyp:HostingUnits$hostingUnitNamevirtualprivatecloud.folder$network.virtualprivatecloud$subnet.network"} ` -ProvisioningSchemeName $catalogName -Scope @() -SecurityGroup @() ` -ServiceOffering "XDHyp:HostingUnits$hostingUnitNameserviceoffering.folder$serviceOffering.serviceoffering"Write-Host $provSchemeSet-BrokerCatalog -AdminAddress $adminAddress -Name $catalogName -ProvisioningSchemeId $provScheme.ProvisioningSchemeUidAdd-ProvSchemeControllerAddress -AdminAddress $adminAddress.com -ControllerAddress $controllerAddress -ProvisioningSchemeName $catalogName

At this point you can refresh the catalog page in Citrix Studio, add machines and manage machines as with any other catalog.

User-added image


  • No Related Posts

The interpretor for “PowerSheIl” is not installed error when running task

I need a solution


I have the following situation. There is a Powershell task that constantly fails on user’s PC. The task fails with the following status error:’The interpretor for “PowerSheIl” is not installed, or has not been added to the command path’, return cod -1.  What does it mean ?

The same task runs fine on other computers. It also works when executed locally by user. The affected systems is Windows 10. The local execution policy is set to ‘Remote signed’.

Any ideas ?





  • No Related Posts

Re: NW9 – Exchange Backups Failling

I am running Exchange 2010 backups in a DAG on NW Server 9. I was troubleshooting an issue with support and they suggested I upgrade NW client / NMM from to, but now the backups fail within a minute. I have not had any luck getting support to call me back for the past two days and am hoping someone can suggest a solution.

I have tried uninstalling / reinstalling nw client / nmm and reverting back to; same results.


107092:nsrnmmsv: Version information for C:Program FilesEMC NetWorkernsrbinnsrnmmsv.exe: Original file name: nsrnmmsv.exe Version: Comments: Supporting Microsoft Volume Shadow Copy Service

127159:nsrnmmsv: Created temp path C:Program FilesEMC NetWorkernsrtmpnmm2016-03-23_22-47-47_4588-4832.

nsrnmmsv: multithreaded save set parallelism==4

133296 1458787668 0 0 0 4832 4588 0 cgtcckmbx01.cgtc.com nsrnmmsv NSR info 26 Starting backup operation. 0

136553 1458787668 5 0 0 4832 4588 0 cgtcckmbx01.cgtc.com nsrnmmsv NSR critical 131 NMM .. Exchange2010 Shell interface is unavailable. This may indicate that the EMC powershell library was not properly registered. 0

111867 1458787668 5 0 0 4832 4588 0 cgtcckmbx01.cgtc.com nsrnmmsv NSR critical 48 Exchange2010 Shell interface is not initialised. 0

145370 1458787668 5 0 0 4832 4588 0 cgtcckmbx01.cgtc.com nsrnmmsv NSR critical 83 Initialization error — Exchange shell failed to initialize. Required for Exchange. 0

DAG01.cgtc.com:pseudo_saveset: retried 1 times.


  • No Related Posts