Problem

You have a working Citrix XenDesktop 7.6 with StoreFront 3.0 published through a NetScaler VPX appliance NS11.0 55.20.nc that has been stable for quite some time and have decided to upgrade the NetScaler to the latest NS11.0 63.16.nc.  You proceed to go through the upgrade of the appliance:

The appliance appears to be operational as navigating to the portal URL displays the authentication page presented by the NetScaler:

However, you notice that you are not able to successfully log into the portal after entering the credentials because the Internet Explorer browser simply presents a white screen:

You attempt to use Chrome to test instead:

Then notice that instead of a white page, the browser terminates the attempt and displays the message:

This webpage has a redirect loop

ERR_TOO_MANY_REDIRECTS

Expanding the Details option displays the following:

This webpage has a redirect loop

ERR_TOO_MANY_REDIRECTS

Reload

Hide details

The webpage at https://access.domain.com/ has resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and not a problem with your computer.

Learn more about this problem.

Solution

While there may be various causes as to why this error would be thrown, the cause for the environment I worked in was because the upgraded NetScaler did not appear to like the redirect configuration I had in IIS on the StoreFront server:

The Web Interface Address in the NetScaler Gateway Session Profile was configured without the full directory path:

https://storefront.domain.com

What ended correcting the issue was to remove the redirect configured on the IIS properties of the StoreFront server:

… and using the full URL path for the StoreFront website:

https://storefrontdr.domain.com/Citrix/UKWeb

Note that I’ve also tried upgrading the StoreFront server to 3.0.1.55 but that did not correct the issue:

Problem

You’ve successfully deployed ADFS in your on-prem environment and would like to use the password change portal that the server provides but you notice that navigating to https://adfs.domain.com/adfs/portal/updatepassword displays the following error:

Expanding the Error details displays the following:

Error details

· Activity ID: 00000000-0000-0000-1400-0080000000d3

· Error time: Wed, 16 Sep 2015 14:02:27 GMT

· Cookie: enabled

· User agent string: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; InfoPath.2; MS-RTC LM 8; .NET CLR 1.1.4322; .NET CLR 3.5.30729; .NET CLR 3.0.30729; MS-RTC EA 2; .NET4.0C; .NET4.0E)

Solution

The reason why the portal is not functioning properly is because you are attempting to use a workstation that isn’t joined to the domain to access this page.  The initial design of this service requires authenticated or registered devices that are joined to the domain but Microsoft changed the relaxed the requirement after receiving feedback from customers.  The patch that relaxes this constraint can be found in the following KB:

https://support.microsoft.com/en-us/kb/3035025#/en-us/kb/3035025

The webpage should function as expected once the patch is applied:

More information about the setup and why the requirement was relaxed can be found in the following MSDN blog post:

Note: ADFS 2012 R2 required authenticated/registered devices (a.k.a ‘workplace join’) to allow the change of passwords. Based on customer feedback, we have relaxed this constraint and allow this from all devices. You will need to apply 3035025 hotfix on all the ADFS servers.

http://blogs.msdn.com/b/samueld/archive/2015/05/13/adfs-2012-r2-now-supports-password-change-not-reset-across-all-devices.aspx

Problem

You’ve recently created a new Directory in Azure but noticed that you created it in the wrong Location and since it is a new directory with no objects created, you decide to delete quickly notice that you are unable to with the following message presented:

Delete directory

Cannot delete ‘<Directory Name>’

The following issue(s) prevent deletion of this directory:

Directory contains one or more applications that were added by a user or administrator.

Solution

The reason why a seemingly new directory cannot be deleted is because the creation process automatnically creates applications that needs to be manually deleted.  The following KB outlines the process:

You can’t delete a directory through the Azure Management Portal
https://support.microsoft.com/en-us/kb/2967860

The suggested cmdlet that the KB above suggest to be executed is:

Get-MsolServicePrincipal | Remove-MsolServicePrincipal

What I’ve noticed from most colleagues or clients who ask me about this is that they are unsure as to how to run this safely without accidentally deleting applications associated with directories and objects that are in their Azure account.

With this in mind, the correct method of deleting applications associated with the directory you want to delete is to log in with the global administrator of your subscription account that you used to create this directory and create a new global admin for this directory itself:

Ensure that Global Admin is selected:

Continue to create the temporary password:

As this is a new account with a temporary password, you will need to log into the https://login.microsoftonline.com portal once to configure a password first otherwise you won’t be able to log in via remote PowerShell:

Once the password has been set, proceed to launch the Windows Azure Active Directory Module for Windows PowerShell and execute the Connect-MsolService cmdlet, authenticate and execute Get-MsolServicePrincipal:

The list of applications display should only be specific to the directory you are attempting to delete as you are logged into the account that was just created.  Proceed to execute the cmdlet Get-MsolServicePrincipal | Remove-MsolServicePrincipal to delete the applications:

Note that there will be some applications that can’t be deleted as shown in red so it is safe to ignore them.

With the applications deleted, continue by logging in as the global administrator subscription account used to create the directory, delete account that was created and finally delete the directory:

Delete directory

Select the checkbox to delete ‘<Directory Name>’. This can take an hour or more.

Deleting ‘<Directory Name>’ cannot be reversed, and will delete all resources in the directory.

Hope this clarifies the process of safely removing an Azure hosted directory.

Problem

You’ve used the Connect-MsolService cmdlet to connect to the WAAD instance then attempt to execute the Set-MsolADFSContext -computer <ADFSserver>.tokiomillennium.com command to hook into the local ADFS server but notice that you get the password prompt that doesn’t appear to accept any passwords that you attempt to use:

After the second attempt to authenticate, you are presented with the following error:

PS C:\> Set-MsolADFSContext -computer adfs.domain.com
Set-MsolADFSContext : The connection to adfs.domain.com Active Directo
ry Federation Services 2.0 server failed due to invalid credentials.
At line:1 char:20
+ Set-MsolADFSContext <<<<  -computer adfs.domain.com
    + CategoryInfo          : InvalidOperation: (:) [Set-MsolADFSContext], Fed
   erationException
    + FullyQualifiedErrorId : ConnectionToGenevaServerFailed,Microsoft.Online.
   Identity.Federation.Powershell.ContextCredentialsCommand

PS C:\>

You’ve ensured that Enable-PSRemoting -force has been executed successfully as outlined in the following KB: https://support.microsoft.com/en-us/kb/2587730

You’ve also confirmed that the port 5985 is opened on the firewall as per the following TechNet blog: http://blogs.technet.com/b/tune_in_to_windows_intune/archive/2013/11/07/the-connection-to-adfs-domain-com-active-directory-federation-services-2-0-server-failed-due-to-invalid-credentials.aspx

You proceed to use the Set-MsolADFSContext cmdlet with the -logfile c:\log.txt switch for more information:

… and obtain the following information:

11/16/2015 10:07:37 AM    Command Set-MsolADFSContext invoked.
11/16/2015 10:07:37 AM    Creating ADFS Server PS session.
11/16/2015 10:07:37 AM    ContextCredentialsCommand:CreatePowerShellSessionToGenevaServer: Invoked.
11/16/2015 10:07:37 AM    Creating PS session to 'adfs.domain.com' ADFS server
11/16/2015 10:07:37 AM    Connect using current logged-on user creds.
11/16/2015 10:07:37 AM    Runspace Connection info: Scheme:http Port:5985, AuthenticationType:Default Uri:adfs.domain.com AppName:wsman, Shell:http://schemas.microsoft.com/powershell/Microsoft.PowerShell
11/16/2015 10:07:37 AM    Connection Uri: http://adfs.domain.com:5985/wsman/
11/16/2015 10:07:38 AM    Opening runspace to 'http://adfs.domain.com:5985/wsman/'
11/16/2015 10:07:38 AM    System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult asyncResult)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
11/16/2015 10:07:38 AM    fullyQualifiedErrorId: System.Management.Automation.Remoting.PSRemotingDataStructureException
11/16/2015 10:07:38 AM    Command failed: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.ParseAndThrowErrorRecord(ErrorRecord errorRecord, String overRideErrorId)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.OpenToGenevaServer(PSCredential serverCredential)
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.<>c__DisplayClass2.<CreatePowerShellSessionToGenevaServer>b__0()
   at Microsoft.Online.Identity.Federation.Powershell.Utility.InvokeOperationWithRetry(Action operation, Type exceptionType, String errorId, Int32 retryCount, Int32 retryWaitTimeInMilliseconds)
11/16/2015 10:07:38 AM    Retry errorId: ConnectionToGenevaServerFailed
11/16/2015 10:07:38 AM    Retry exception: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException
11/16/2015 10:07:38 AM    Going to sleep mode for 1000 milliseconds before reattempt - 2
11/16/2015 10:07:39 AM    Runspace Connection info: Scheme:http Port:5985, AuthenticationType:Default Uri:adfs.domain.com AppName:wsman, Shell:http://schemas.microsoft.com/powershell/Microsoft.PowerShell
11/16/2015 10:07:39 AM    Connection Uri: http://adfs.domain.com:5985/wsman/
11/16/2015 10:07:39 AM    Opening runspace to 'http://adfs.domain.com:5985/wsman/'
11/16/2015 10:07:39 AM    System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult asyncResult)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
11/16/2015 10:07:39 AM    fullyQualifiedErrorId: System.Management.Automation.Remoting.PSRemotingDataStructureException
11/16/2015 10:07:39 AM    Command failed: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.ParseAndThrowErrorRecord(ErrorRecord errorRecord, String overRideErrorId)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.OpenToGenevaServer(PSCredential serverCredential)
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.<>c__DisplayClass2.<CreatePowerShellSessionToGenevaServer>b__0()
   at Microsoft.Online.Identity.Federation.Powershell.Utility.InvokeOperationWithRetry(Action operation, Type exceptionType, String errorId, Int32 retryCount, Int32 retryWaitTimeInMilliseconds)
11/16/2015 10:07:39 AM    Retry errorId: ConnectionToGenevaServerFailed
11/16/2015 10:07:39 AM    Retry exception: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException
11/16/2015 10:07:39 AM    Going to sleep mode for 2000 milliseconds before reattempt - 3
11/16/2015 10:07:41 AM    Runspace Connection info: Scheme:http Port:5985, AuthenticationType:Default Uri:adfs.domain.com AppName:wsman, Shell:http://schemas.microsoft.com/powershell/Microsoft.PowerShell
11/16/2015 10:07:41 AM    Connection Uri: http://adfs.domain.com:5985/wsman/
11/16/2015 10:07:41 AM    Opening runspace to 'http://adfs.domain.com:5985/wsman/'
11/16/2015 10:07:41 AM    System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult asyncResult)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
11/16/2015 10:07:41 AM    fullyQualifiedErrorId: System.Management.Automation.Remoting.PSRemotingDataStructureException
11/16/2015 10:07:41 AM    Command failed: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.ParseAndThrowErrorRecord(ErrorRecord errorRecord, String overRideErrorId)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.OpenToGenevaServer(PSCredential serverCredential)
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.<>c__DisplayClass2.<CreatePowerShellSessionToGenevaServer>b__0()
   at Microsoft.Online.Identity.Federation.Powershell.Utility.InvokeOperationWithRetry(Action operation, Type exceptionType, String errorId, Int32 retryCount, Int32 retryWaitTimeInMilliseconds)
11/16/2015 10:07:41 AM    Retry errorId: ConnectionToGenevaServerFailed
11/16/2015 10:07:41 AM    Retry exception: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException
11/16/2015 10:07:41 AM    Failure after too many retry attempts...
11/16/2015 10:07:41 AM    Wrong credentials to ADFS Server connection, attempt #'1'
11/16/2015 10:07:41 AM    Prompting the user for 'adfs.domain.com' ADFS Server creds.
11/16/2015 10:07:41 AM    ContextCredentialsCommand:GetServerCredentials: Invoked.
11/16/2015 10:08:04 AM    Runspace Connection info: Scheme:http Port:5985, AuthenticationType:Default Uri:adfs.domain.com AppName:wsman, Shell:http://schemas.microsoft.com/powershell/Microsoft.PowerShell
11/16/2015 10:08:04 AM    Connection Uri: http://adfs.domain.com:5985/wsman/
11/16/2015 10:08:04 AM    Opening runspace to 'http://adfs.domain.com:5985/wsman/'
11/16/2015 10:08:04 AM    System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult asyncResult)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
11/16/2015 10:08:04 AM    fullyQualifiedErrorId: System.Management.Automation.Remoting.PSRemotingDataStructureException
11/16/2015 10:08:04 AM    Command failed: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.ParseAndThrowErrorRecord(ErrorRecord errorRecord, String overRideErrorId)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.OpenToGenevaServer(PSCredential serverCredential)
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.<>c__DisplayClass2.<CreatePowerShellSessionToGenevaServer>b__0()
   at Microsoft.Online.Identity.Federation.Powershell.Utility.InvokeOperationWithRetry(Action operation, Type exceptionType, String errorId, Int32 retryCount, Int32 retryWaitTimeInMilliseconds)
11/16/2015 10:08:04 AM    Retry errorId: ConnectionToGenevaServerFailed
11/16/2015 10:08:04 AM    Retry exception: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException
11/16/2015 10:08:04 AM    Going to sleep mode for 1000 milliseconds before reattempt - 2
11/16/2015 10:08:05 AM    Runspace Connection info: Scheme:http Port:5985, AuthenticationType:Default Uri:adfs.domain.com AppName:wsman, Shell:http://schemas.microsoft.com/powershell/Microsoft.PowerShell
11/16/2015 10:08:05 AM    Connection Uri: http://adfs.domain.com:5985/wsman/
11/16/2015 10:08:06 AM    Opening runspace to 'http://adfs.domain.com:5985/wsman/'
11/16/2015 10:08:06 AM    System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult asyncResult)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
11/16/2015 10:08:06 AM    fullyQualifiedErrorId: System.Management.Automation.Remoting.PSRemotingDataStructureException
11/16/2015 10:08:06 AM    Command failed: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.ParseAndThrowErrorRecord(ErrorRecord errorRecord, String overRideErrorId)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.OpenToGenevaServer(PSCredential serverCredential)
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.<>c__DisplayClass2.<CreatePowerShellSessionToGenevaServer>b__0()
   at Microsoft.Online.Identity.Federation.Powershell.Utility.InvokeOperationWithRetry(Action operation, Type exceptionType, String errorId, Int32 retryCount, Int32 retryWaitTimeInMilliseconds)
11/16/2015 10:08:06 AM    Retry errorId: ConnectionToGenevaServerFailed
11/16/2015 10:08:06 AM    Retry exception: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException
11/16/2015 10:08:06 AM    Going to sleep mode for 2000 milliseconds before reattempt - 3
11/16/2015 10:08:08 AM    Runspace Connection info: Scheme:http Port:5985, AuthenticationType:Default Uri:adfs.domain.com AppName:wsman, Shell:http://schemas.microsoft.com/powershell/Microsoft.PowerShell
11/16/2015 10:08:08 AM    Connection Uri: http://adfs.domain.com:5985/wsman/
11/16/2015 10:08:08 AM    Opening runspace to 'http://adfs.domain.com:5985/wsman/'
11/16/2015 10:08:08 AM    System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult asyncResult)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
11/16/2015 10:08:08 AM    fullyQualifiedErrorId: System.Management.Automation.Remoting.PSRemotingDataStructureException
11/16/2015 10:08:08 AM    Command failed: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.ParseAndThrowErrorRecord(ErrorRecord errorRecord, String overRideErrorId)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.OpenToGenevaServer(PSCredential serverCredential)
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.<>c__DisplayClass2.<CreatePowerShellSessionToGenevaServer>b__0()
   at Microsoft.Online.Identity.Federation.Powershell.Utility.InvokeOperationWithRetry(Action operation, Type exceptionType, String errorId, Int32 retryCount, Int32 retryWaitTimeInMilliseconds)
11/16/2015 10:08:08 AM    Retry errorId: ConnectionToGenevaServerFailed
11/16/2015 10:08:08 AM    Retry exception: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException
11/16/2015 10:08:08 AM    Failure after too many retry attempts...
11/16/2015 10:08:08 AM    Wrong credentials to ADFS Server connection, attempt #'2'
11/16/2015 10:08:08 AM    Prompting the user for 'adfs.domain.com' ADFS Server creds.
11/16/2015 10:08:08 AM    ContextCredentialsCommand:GetServerCredentials: Invoked.
11/16/2015 10:08:22 AM    Runspace Connection info: Scheme:http Port:5985, AuthenticationType:Default Uri:adfs.domain.com AppName:wsman, Shell:http://schemas.microsoft.com/powershell/Microsoft.PowerShell
11/16/2015 10:08:22 AM    Connection Uri: http://adfs.domain.com:5985/wsman/
11/16/2015 10:08:23 AM    Opening runspace to 'http://adfs.domain.com:5985/wsman/'
11/16/2015 10:08:23 AM    System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult asyncResult)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
11/16/2015 10:08:23 AM    fullyQualifiedErrorId: System.Management.Automation.Remoting.PSRemotingDataStructureException
11/16/2015 10:08:23 AM    Command failed: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.ParseAndThrowErrorRecord(ErrorRecord errorRecord, String overRideErrorId)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.OpenToGenevaServer(PSCredential serverCredential)
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.<>c__DisplayClass2.<CreatePowerShellSessionToGenevaServer>b__0()
   at Microsoft.Online.Identity.Federation.Powershell.Utility.InvokeOperationWithRetry(Action operation, Type exceptionType, String errorId, Int32 retryCount, Int32 retryWaitTimeInMilliseconds)
11/16/2015 10:08:23 AM    Retry errorId: ConnectionToGenevaServerFailed
11/16/2015 10:08:23 AM    Retry exception: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException
11/16/2015 10:08:23 AM    Going to sleep mode for 1000 milliseconds before reattempt - 2
11/16/2015 10:08:24 AM    Runspace Connection info: Scheme:http Port:5985, AuthenticationType:Default Uri:adfs.domain.com AppName:wsman, Shell:http://schemas.microsoft.com/powershell/Microsoft.PowerShell
11/16/2015 10:08:24 AM    Connection Uri: http://adfs.domain.com:5985/wsman/
11/16/2015 10:08:24 AM    Opening runspace to 'http://adfs.domain.com:5985/wsman/'
11/16/2015 10:08:24 AM    System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult asyncResult)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
11/16/2015 10:08:24 AM    fullyQualifiedErrorId: System.Management.Automation.Remoting.PSRemotingDataStructureException
11/16/2015 10:08:24 AM    Command failed: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.ParseAndThrowErrorRecord(ErrorRecord errorRecord, String overRideErrorId)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.OpenToGenevaServer(PSCredential serverCredential)
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.<>c__DisplayClass2.<CreatePowerShellSessionToGenevaServer>b__0()
   at Microsoft.Online.Identity.Federation.Powershell.Utility.InvokeOperationWithRetry(Action operation, Type exceptionType, String errorId, Int32 retryCount, Int32 retryWaitTimeInMilliseconds)
11/16/2015 10:08:24 AM    Retry errorId: ConnectionToGenevaServerFailed
11/16/2015 10:08:24 AM    Retry exception: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException
11/16/2015 10:08:24 AM    Going to sleep mode for 2000 milliseconds before reattempt - 3
11/16/2015 10:08:26 AM    Runspace Connection info: Scheme:http Port:5985, AuthenticationType:Default Uri:adfs.domain.com AppName:wsman, Shell:http://schemas.microsoft.com/powershell/Microsoft.PowerShell
11/16/2015 10:08:26 AM    Connection Uri: http://adfs.domain.com:5985/wsman/
11/16/2015 10:08:26 AM    Opening runspace to 'http://adfs.domain.com:5985/wsman/'
11/16/2015 10:08:26 AM    System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult asyncResult)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
11/16/2015 10:08:26 AM    fullyQualifiedErrorId: System.Management.Automation.Remoting.PSRemotingDataStructureException
11/16/2015 10:08:26 AM    Command failed: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException: Connecting to remote server adfs.domain.com failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.ParseAndThrowErrorRecord(ErrorRecord errorRecord, String overRideErrorId)
   at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.OpenToGenevaServer(PSCredential serverCredential)
   at Microsoft.Online.Identity.Federation.Powershell.ContextCredentialsCommand.<>c__DisplayClass2.<CreatePowerShellSessionToGenevaServer>b__0()
   at Microsoft.Online.Identity.Federation.Powershell.Utility.InvokeOperationWithRetry(Action operation, Type exceptionType, String errorId, Int32 retryCount, Int32 retryWaitTimeInMilliseconds)
11/16/2015 10:08:26 AM    Retry errorId: ConnectionToGenevaServerFailed
11/16/2015 10:08:26 AM    Retry exception: Microsoft.Online.Identity.Federation.Powershell.IdentityFederationException
11/16/2015 10:08:26 AM    Failure after too many retry attempts...
11/16/2015 10:08:26 AM    Wrong credentials to ADFS Server connection, attempt #'3'

Reviewing the event logs of the ADFS server (not the proxy) show that the following Event ID 4 error is logged:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server bmadfs01$. The target name used was HTTP/adfs.domain.com. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (domain.COM) is different from the client domain (domain.COM), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

Log Name: System

Source: Security-Kerberos

Event ID: 4

Level: Error

You’ve reviewed the following forum post and your environment does not exhibit the SPN issue:

https://social.technet.microsoft.com/Forums/windows/en-US/a4c5c787-ea65-4150-8d16-2a19c569a589/enterpssession-winrm-cannot-process-the-request-kerberos-authentication-error-0x80090322?forum=winserverpowershell

Solution

The solution to this issue if none of the above troubleshooting suggestions apply to your environment actually to execute the Set-MsolADFSContext cmdlet using the internal ADFS server’s FQDN rather than the adfs A record you created to reference the server.  The environment I worked in that exhibited this issue had an internal DNS A record adfs that mapped to the internal ADFS server so when the cmdlet was executed referencing this record, it caused the Kerberos error to be thrown and logged.  As simple as this error could be, I find that this question gets asked quite often so I hope this blog post would help those encounter this issue.

I recently had to remove the federation between an on-prem Active Directory and an Azure Directory so that we could re-federate the on-prem Active Directory to a new Azure Directory.  The process is quite easy but there doesn’t appear to be clear documentation for the steps so I thought it would be worth while writing this blog post just in case I ever had to do this again in the future.

Begin by removing the domain from the Azure Directory that you no longer need it to be federated to.  The tasks required are as follows:

• Stop the DirSync
• Disable ADFS federation
• Delete the directory (you can’t have the same on-prem directory added to more than one Azure Directory)

Within the new Azure Directory that you are going to federate the on-prem directory to:

• Create a new global admin account for this Azure Directory
• Add the new domain to Azure Directory
• Create the required TXT record to verify the domain
• Launch the WAAD console and execute Connect-MsolService
• Log in with the global admin account for the Azure Directory
• Execute Get-MsolDomain to ensure that the on-prem domain is listed and the Authentication field is listed as Managed

• Execute Set-MsolADFSContext -computer <yourInternalADFSserverFQDN>
• Execute Convert-MsolDomainToFederated -DomainName <domainToFederateFQDN>

• The federation to the previous Azure Directory would have created a Microsoft Office 365 Identity Platform in the Relying PartyTrusts folder in the AD FS console as shown here:

• Proceed by deleting it:

• Then recreating it by executing Update-MsolFederatedDomain -domainname <domainToFederateFQDN>

• Refreshing the Relying PartyTrusts folder should now show a recreated Microsoft Office 365 Identity Platform
• Reconfigure and then run DirSync now to synchronize the on-prem Active Directory with the Azure Directory

I recently ran into an interesting issue where I went through a series of troubleshooting steps that eventually led me to reinstalling the VMware Horizon View Agent on a master image but quickly realized I wasn’t able to.  The error messages I was presented wasn’t too helpful so I thought writing this blog post may help others who may encounter the same problem.

The whole process started off with an administrator asking me to look at why a user wasn’t able to connect to their virtual desktops after we recompose their VDI with the latest snapshot that recently had 2GB of Windows updates installed.  The user would attempt to log onto the View environment as such:

The Connection Server is preparing the desktop…

They would see a black screen as such:

Then they would get cut off and displayed the following error message:

VMware Horizon Client

The connection to the remote computer ended.

Suspecting the PCoIP logs would assist with the troubleshooting, I browsed over to the desktop’s VDM\logs folder:

\\VDI-001\c$\ProgramData\VMware\VDM\logs

… then opened one of the pcoip_agent logs to review the entries.  Some of the entries I noticed were:

Server died.

… and:

disconnect reason: 0

The follow log entries are as follows:

11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Adding session to list.

11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Total number of active sessions = 1

11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Sending connection response ok.

11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] connection_response (end), 0

11/17/2015, 14:02:36.562> LVL:2 RC: 0 AGENT :monitor_soft_hosts: {s_tag:0x9bd8fbc8ee73a36a} Server died.

11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect [soft host]: agent close code: 6, disconnect reason: 0

11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect: {s_tag:0x9bd8fbc8ee73a36a} disconnect is ** NOT ** pending (hndl: 5, pid: 924, process handle: 0000060c)

11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect: {s_tag:0x9bd8fbc8ee73a36a} Server process already exited (hndl: 5, pid: 924, process handle: 0000060c)

11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_finish_disconnect_thread: connection_closed 6

11/17/2015, 14:02:36.703> LVL:2 RC: 0 AGENT :sSERVER_SESSION::~sSERVER_SESSION: {s_tag:0x9bd8fbc8ee73a36a} Closing pcoip server process handle 000000000000060C

Reviewing the View Connection server’s logs from the folder:

C:\ProgramData\VMware\VDM\logs

… reveal the entry:

2015-11-17T14:17:10.024-04:00 DEBUG (0C70-094C) <e1f29aa5-68ed-437b-ad9f-cc1759d63d8b> [DesktopTracker] onEvent: PENDING_EXPIRED - UserName:a-tluk;DomainName:CONTOSO;UserDn:cn=s-1-5-21-206374890-975330658-925700815-10626,cn=foreignsecurityprincipals,dc=vdi,dc=vmware,dc=int;UserSid:null;GroupSids:null;BrokerUserSid:S-1-5-21-206374890-975330658-925700815-10626;ConnectionId:fcca_***_1220;Protocol:null;ClientName:null;ClientAddress:null;ServerDn:cn=a34734d6-4e78-4d07-83c4-5ce3d1ce31cd,ou=servers,dc=vdi,dc=vmware,dc=int;ServerPoolDn:cn=standard_CON_desktop,ou=server groups,dc=vdi,dc=vmware,dc=int;ServerDnsName:CONFSTAWKST-158.tokiomillennium.com;DynamicIpAddress:10.23.0.92;ManagedObjectId:null;Id:e1f29aa5-68ed-437b-ad9f-cc1759d63d8b;State:PENDING_EXPIRED;SessionGuid:c80b-***-2d5b;PreviousSessionGuid:null;LoggedInAsDomain:CONTOSO;LoggedInAsUser:a-tluk;SessionType:DESKTOP;RemotableContent:null

Reviewing the Events database in the View Administrator console reveals the following:

The pending session on machine <VDIname> for user contoso\a-tluk has expired.

What I’ve done in the past for troubleshooting black screen disconnection issues was to reinstall the VMware Horizon View agent but what I noticed was that attempting to install the View Agent on the master image after uninstalling it would briefly show the splash screen, disappear and nothing would happen.  From there, I proceeded to uninstall VMware Tools and reinstall it but quickly noticed that the install would fail with the message:

VMware Product Installation

This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package.

Attempting to copy the installer onto the desktop and run the install would generate the following error message:

Setup failed to extract the files necessary to install VMware Tools.

From here on, what ended up being the cause of all these issues was actually because there was no space in the %temp% directory to extract the installation files. The reason why this was the case was because the environment I was working in had SanDisk’s ioVDI solution deployed and the %temp% folder was redirected to a disposable disk that also stored the page file which had already filled up the disk.  This was why the installer for VMware Tools and the Horizon View Agent would fail and it was also why the user had connection issues.

The whole ordeal concluded in a way that I did not expect so I hope the error messages I outlined here would be able to help anyone who happens to come across a similar issue with the same cause.

I’ve noticed that I’ve been asked about the following error quite frequently over the past year so I thought writing a blog post may help anyone who might be searching for an answer to this problem.

Problem

You’ve configured a Load Balancing Virtual Server on your NetScaler appliance which you use to direct NetScaler Gateway Virtual Server requests to your StoreFront servers:

Accessing the StoreFront portal and authenticating through the NetScaler works fine but you notice the following error if you try to access the URL of the Load Balancing Virtual Server internally to bypass the NetScaler Gateway authentication page:

Cannot complete your request.

Clicking the OK button will cycle through the previous prompts and end with the same message.

Solution

While there are many reasons why this error would be thrown as outlined in the following KB:

http://support.citrix.com/article/CTX133904http://docs.citrix.com/en-us/storefront/3/integrate-with-netscaler-and-netscaler-gateway/load-balancing-with-netscaler.html?_ga=1.149961662.983477202.1446337615

Two of the most frequent reasons I’ve seen is either the need to create a host record on your StoreFront servers to resolve the FQDN URL you are using to send traffic to your NetScaler’s Load Balancing Virtual Server to resolve to itself or that Integrated Caching is enabled on the NetScaler:

Try turning this feature off if you are experiencing this issue:

Problem

You’ve noticed that sharing PowerPoint presentations in your Lync 2013 or Skype for Business 2015 business no longer works with the following error message being displayed:

Some presenting features are unavailable due to server connectivity issues.

Logging onto the WAC / Office Web Apps server displays the following errors logged:

Log Name: Application

Source: Application Error

Event ID: 1000

Level: Error

Faulting application name: pptviewerbackendwatchdog.exe, version: 15.0.4502.1000, time stamp: 0x512d2645

Faulting module name: KERNELBASE.dll, version: 6.2.9200.17366, time stamp: 0x554d4531

Exception code: 0xe0434352

Fault offset: 0x000000000004aea8

Faulting process id: 0xeec

Faulting application start time: 0x01d130637d0f659c

Faulting application path: C:\Program Files\Microsoft Office Web Apps\PowerPointViewingServicesWatchdog_App\pptviewerbackendwatchdog.exe

Faulting module path: C:\Windows\system32\KERNELBASE.dll

Report Id: bb35573c-9c56-11e5-9420-005056a10329

Faulting package full name:

Faulting package-relative application ID:

Log Name: Application

Source: Application Error

Event ID: 1026

Level: Error

Application: pptviewerbackendwatchdog.exe

Framework Version: v4.0.30319

Description: The process was terminated due to an unhandled exception.

Exception Info: System.TypeInitializationException

Stack:

at Microsoft.Office.Web.Common.ServiceInstanceFinder.GetLocalAgentInstance(Microsoft.Office.Web.Common.OfficeServiceType)

at Microsoft.Office.Web.Common.WatchdogHelper.PrepareRegistrations(Microsoft.Office.Web.Common.OfficeServiceType)

at Microsoft.Office.Web.Common.WatchdogHelper.WatchMachines(Microsoft.Office.Web.Common.OfficeServiceType, CheckServiceInstance, Microsoft.Office.Web.Common.OfficeServiceType, System.String)

at Microsoft.Office.Server.Powerpoint.Watchdog.ViewingBackend.Program.Main(System.String[])

Solution

I wasn’t able to find much material on this issue but the closest match was the following TechNet blog post:

http://blogs.technet.com/b/dodeitte/archive/2013/03/29/issue-with-automatic-updates-enabled-amp-office-web-apps-server-2013-update.aspx

The WAC / Office Web Apps server in this environment wasn’t on automatic updates but the administrators simply install any updates that are available on a routine schedule.  The KB2760445 wasn’t on the list of updates installed onto the server but as I didn’t have any other leads, I went ahead to uninstall Office Web Apps, then the language pack, then reinstalled all the components in the following order;

1. Office Web Apps Server 2013
2. Office Web Apps Server Language Pack 2013
3. Office Web Apps Server 2013 SP1

Once reinstalled, I recreated the Office Web Apps Server Farm and noticed that everything was working again.

A few notes worth mentioning that I noticed:

1. There is no need to install https://support.microsoft.com/en-us/kb/2760445 as noted in the TechNet blog above as the Office Web Apps Server 2013 SP1 covers it
2. I tried installing Office Web Apps Server 2013 SP1 prior to uninstalling and that did not fix the problem

Just for reference, the following version is Office Web Apps Server 2013 pre-SP1:

15.0.4420.1017

The following version is Office Web Apps Server 2013 after installing SP1:

15.0.4571.1502

I’ve recently been asked a few times by clients and colleagues about the ability to hide the new X1 StoreFront interface’s Favorites, Apps and Desktop tabs and as I don’t have a blog post demonstrating it, I thought I’d write this quick post so I could direct these questions to it.

Hiding the Favorites Tab

To hide the Favorites tab as shown in the screenshot below:

… simply launch the Citrix StoreFront console, navigate to Stores, select the store you would like to hide the tab and the click on the Disable User Subscriptions option on the right:

You will be briefly presented with the following prompt:

Click on Yes to complete the configuration.

Hiding the Apps or Desktops Tab

To hide the Apps or Desktops tab as shown in the screenshot below:

… simply navigate to the C:\inetpub\wwwroot\Citrix\<StoreName>Web directory, open the web.config file with Notepad:

Then search for either showAppsView or showDesktopsView which will bring you to the following section:

<userInterface autoLaunchDesktop="true" multiClickTimeout="3"

enableAppsFolderView="true">

<workspaceControl enabled="true" autoReconnectAtLogon="true"

logoffAction="disconnect" showReconnectButton="false" showDisconnectButton="false" />

<receiverConfiguration enabled="true" downloadURL="ServiceRecord/GetDocument/receiverconfig.cr" />

<uiViews showDesktopsView="true"showAppsView="true" defaultView="auto" />

<appShortcuts enabled="false" allowSessionReconnect="false" />

</userInterface>

Modify the true option for the respective tabs by changing them to false if you would like to hide them.

The following is an example of a StoreFront store with the Favorites and Apps tab hidden:

1. A single Exchange 2013 server with both the Mailbox and Client Access roles installed
2. The version is 15.0 (Build 1156.6) - CU11
3. The operating system is Windows Server 2012 R2 with the latest patches installed as of December 18, 2015

Problem

You attempt to upgrade your existing VMware Horizon View 6.0.1 infrastructure to 6.2.1 but noticed that after upgrading your View Connection and Security servers you receive the following error message when connecting to a virtual desktop:

Unable to connect to desktop: There is no available gateway for the display protocol. Try again, or contact your administrator if this problem persists.

Attempting to connect from an older VMware View client throws the following error:

The View Connection Server connection failed. The handle is in the wrong state for the requested operation.

Reviewing the Events log in th View Manager displays the following error message:

Severity: Audit failure

Message: Unable to launch from Pool <poolID> for user <domain\userID>: No co-management availability for protocol PCoIP

Solution

This isn’t the first VMware Horizon View 6.2.1 upgrade I’ve done but it is the first that I had to jump from 6.0.1 to 6.2.1 and because I worked on this upgrade during a small window and was unable to get connectivity to work even though I tried upgrading the View agent to a newer version, I ended up rolling back to 6.0.1 then opened up a ticket with VMware.

What I learned from the VMware support engineer was that older agents would not work with 6.2 or later versions because TLS 1.0 is disabled and since I had the View Connection and Security servers at 6.2.1 and the agents still at 6.0.1 FP2, these error messages were thrown (I’m not sure why the initial test I did when upgrading the agent didn’t work during the first window).

The following is what I learned after scheduling a second window to test performing the upgrade again:

1. Attempting to use the following KB to configure TLS 1.0 did not work for me: http://kb.vmware.com/kb/2130798

2. Disabling Use PCoIP Secure Gateway for PCoIP connects to machine fixed the issue:

This solution wasn’t practical for me as it would allow internal connections but external connections through the View Security Server would not work.

3. Upgrading the View Agent from 6.0.2.2331487:

… to 6.2 or higher would correct the issue:

6.2.1.3284564

6.2.0.3005627

4. If you have any View clients older than Horizon 3.3 (either on Windows, Windows Embedded, or any thin/zero client OS such as HP ThinPro) then you’ll also need to upgrade them or they won’t be able to connect to the desktop.

Update – January 6, 2015

I’m not sure if this was added at a later time because i did not see this note when I downloaded 6.2.1 in December but the Notes section on the download product page explains the potential issues you may face if you’re using an older Horizon Client:

To improve security, by default, View 6.2.1 does not support SSLv3 and does not accept incoming connections that use security protocol TLS 1.0. This will affect Horizon Client 3.3 and earlier versions, which can only use TLS 1.0. For instructions on how to enable TLS 1.0, see the View 6.2.1 release notes.

I’ve recently been involved with deploying a new Windows 10 VMware Horizon View pool to pilot the new operating system with the latest Office 2016 suite and ran into KMS activation issues because the Windows Server 2012 R2 KMS server was not configured properly so I thought it would be a good idea to outline the steps here so I could reference this in the future.

Begin by confirming that your Windows 10 desktop is indeed not activating by simply launching the Activation window on the desktop and attempt to activate.  If you’re sure that you already have 25 desktops with unique CMIDs activating but activation on the Windows 10 desktop still throws the following error:

Windows is unable to reach your company’s activation service. Please connect to your corporate network. If you are connected and continue to see the error, contact your system administrator. You can also click on error detail to find the exact error. Error code: 0xC004F074

… then proceed by ensuring that you have completed the steps outlined in the following KB:

Error 0xC004F015 when you try to activate Windows 10 Enterprise on a Windows Server 2012 R2 KMS host
https://support.microsoft.com/en-us/kb/3086418

What I’ve noticed in the environment I was working in was that if I attempted to apply the new Windows Srv 2012R2 DataCtr/Std KMS for Windows 10 product key onto the existing Windows Server 2012 R2 KMS server that already has a KMS key via the GUI:

… I would actually receive the following error:

That key can’t be used to activate Window son this PC-it can only be used to set up a key management service. Contact your system administrato or try a different key.

What actually needs to be done is to uninstall the existing key prior to applying the new one.  Before uninstalling the existing key, execute slmgr.vbs /dlv and note the Description:

Description: Windows(R) Operating System, VOLUME_KMS_WS12_R2 channel

Proceed by executing slmgr.vbs /upk to uninstall the existing KMS key:

With the old key uninstalled, execute the following:

slmgr.vbs /ipk <yourUniqueKMSProductKey>

With the new key successfully installed, executing slmgr.vbs /dlv should now display the following Description:

Description: Windows(R) Operating System, VOLUME_KMS_2012-R2_WIN10

Navigating back to the Windows 10 desktop should now allow you to activate successfully:

As mentioned above, the KMS server requires at least 25 Windows 10 desktops with unique CMIDs before it will activate desktops so if you see the following information event on your KMS server’s Key Management Service Log:

An activation request has been processed.

Info:

0xC004F042,25,WIN10P-001.domain.com,12259f7e-88ea-49a5-8ca8-5b49aae0cccd,2015/12/21 21:07,0,5,0,73111121-5638-40f6-bc11-f1d7b0d64300

… then this means that you have not reached the threshold of 25 desktops which is signified by the:

0xC004F042,25

When the threshold is met, the following information log will be written:

An activation request has been processed.

Info:

0x0,25,WIN10P-001.domain.com,43155fc4-20ec-4079-b1c8-2af013fb7f43,2015/12/23 15:52,0,1,259200,73111121-5638-40f6-bc11-f1d7b0d64300

As with the experience I had when configuring an existing KMS server to activate Windows 10 desktops:

Installing and configuring Windows 10 KMS Activation with Windows Server 2012 R2
http://terenceluk.blogspot.com/2016/01/installing-and-configuring-windows-10.html

… I also found that configuring the server for Office 2016 activations wasn’t as straight forward as using the VAMT tool so this blog post serves to demonstrate the steps to get a KMS server activating desktops with Office 2016.

Begin by logging into the Microsoft Volume Licensing Service Center at:

https://www.microsoft.com/Licensing/servicecenter/default.aspx

… then search for Office Professional Plus 2016 Key Management Service Host to obtain the package:

Office Professional Plus/Standard 2016 32 Bit English KMS

Extract the ISO package to your KMS server:

SW_DVD5_Office_Professional_Plus_2016_W32_English_KMS_MLF_X20-42865.iso

Then execute kms_host.vbs:

The Volume Activation Tools wizard will now launch:

Proceed through the wizard and install the unique Office 2016 KMS key:

Activate the product key:

Restart the Software Protection service:

At this point, the KMS server should now be able to activate Office 2016 desktops. Note that you need atleast 5 Office 2016 desktops with a unique CMIDs before the KMS server will activate the installations.  The following information entry in the Key Management Service logs indicate the threshold has not been met:

An activation request has been processed.

Info:

0xC004F042,5,WIN10P-023.domain.com,fa366b19-c48b-4ef8-a1bb-2f4718b477b3,2015/12/23 13:01,0,2,24510,d450596f-894d-49e0-966a-fd39ed4c4c64

Once the threshold of 5 has been met, the following informational log will be written:

An activation request has been processed.

Info:

0x0,5,WIN10P-022.domain.com,e35750c1-aca7-417d-859e-490bf1e61bce,2015/12/23 15:30,0,2,24362,d450596f-894d-49e0-966a-fd39ed4c4c64

Also note that I did not find the Volume Activation Management Tool useful for Office 2016 activations as attempting to install or activate installations would throw the following error:

A licensing provider for the specified product cannot be foundParameter name: product

I recently had to troubleshoot an issue with PDFs failing to launch within an Internet Explorer window which lead to a resolution that required two security features in Adobe Acrobat Reader DC 2015 to be disabled and thought that I’d write this post to demonstrate the process so I could reference it when I write the post describing that issue.  Note that I am not recommending to disable these features as it renders the reader much less secure so please carefully evaluate other alternatives if they exist.

The reader I’ll be modifying will be the Adobe Acrobat Reader DC 2015 Release | Version 2015.009.20079

The two features we’ll be disabling are:

Enable Protected Mode at startup

… and:

Enable Enhanced Security

… listed in the Security (Enhanced) category:

To disable the Enable Protected Mode at startup configuration, navigate to the following registry key:

HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\DC\Privledged

… then modify the bProtectedMode REG_DWORD value to 0 to disable and 1 to enable:

To disable the Enable Enhanced Security configuration, navigate to the following registry key:

HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\DC\TrustManager

… then modify the bEnhancedSecurityStandalone REG_DWORD value to 0 to disable and 1 to enable:

Perform the same change to bEnhancedSecurityInBrowser if you want the same change for PDFs launched in browsers.

To automate these configuration changes, you can either use a GPO that launches a batch file containing REGADD or use Group Policy Preferences to add/update the key.