Problem

You’ve completed deploying the Avaya Communicator for Microsoft Lync (version 6.4.0.2.50) client side integration with Skype for Business Server 2015 to replace the previous Lync Server 2013 and Avaya AES server’s RCC functionality but noticed that you are unable to change the Extension in the Avaya Communication for Microsoft Lync because it is greyed out once it has been configured:

Solution

I’m not exactly sure if this is by-design but one of the ways I found to workaround this was change the Choose the Device for Calls: setting to another option (in this case it is the Computer setting):

Then change it back to the previous Desk Phone option and you will then notice that the Extension field is no longer greyed out:

Problem

You’ve successfully completed upgrading your Lync Server 2010 or 2013 environment to Skype for Business Server 2015 but noticed that you receive the following error when attempting to use the SKYPE DIRECTORY tab to search the Skype directory:

Search for Skype contacts by name, Skype Name, email address, phone number, and location.

An error occurred during the search. Please try again, and contact your support team if the problem continues.

You’ve confirmed that the Edge server properties in the Topology Builder has the following configuration enabled:

Enable Skype-Skype federation search for this Edge pool (port 4443)

Choose this option, Skype-Skype federation will have federation search enabled by default.

You’ve successfully recreated the Skype Public Provider with:

New-CsPublicProvider -Identity Skype -ProxyFqdn federation.messenger.msn.com –IconUrl https://images.edge.messenger.live.com/Messenger_16x16.png -NameDecorationRoutingDomain msn.com -NameDecorationExcludedDomainList "msn.com,outlook.com,live.com,hotmail.com" -VerificationLevel UseSourceVerification -Enabled $true -EnableSkypeIdRouting $true -EnableSkypeDirectorySearch $true

You’ve noticed that the SKYPE DIRECTORY search feature works when you are internally logged in:

Using the Remote Connectivity Analyzer tool online at https://testconnectivity.microsoft.com/ returns green status with no errors.

Solution

This issue threw me off for an hour because all the external tests I ran came back in good health yet it was apparently there was something wrong with the Edge server because searching the Skype directory worked internally.  As I began running out of ideas, I decided to check the TMG publishing rule for the Web Services and to my surprise threw the following error when I attempted to test the rule:

All of the required secure 4443 port publishing tests failed with the error:

Category: Destination server certificate error

Error details: 0x80090322 – The target principal name is incorrect.

Action: Go to http://go.microsoft.com/fwlink/?LinkId=115965

To confirm that external web services was indeed broken, I attempted to browse to the URL:

https://<domain>/groupexpansion/service.svc

… and was able to confirm I did not get a authentication prompt. After spending a bit of time reviewing the TMG publishing rule then replacing the external web services certificate to use an internally generated certificate rather than the same certificate used on the TMG that was published by an external CA, the tests were finally in good health:

Correcting the issue with SfB’s Web Services fixed the Skype directory lookup error when logging in through the Edge server:

Hope this helps anyone out there who may come across this issue as the root cause wasn’t obvious because publishing the Web Services through TMG meant using the Remote Connectivity Analyzer tool online at https://testconnectivity.microsoft.com/ returns green if the TMG is able to listen to traffic but not successfully communicate to the Lync front-end pool.

I’ve received quite a few requests from clients over the past few months requesting to secure their NetScaler published services to score an A+ on Qualys SSL Labs:

https://www.ssllabs.com/ssltest/

I’m a bit late to writing this blog post as there are plenty of other excellent posts that demonstrate the process so in an effort to add a bit more value to the community, this post will demonstrate the process on a NetScaler VPX NS11.0 63.16.nc via the command line.

Without any additional configuration, NetScaler published services such as Citrix XenApp/XenDesktop typically scores a C:

Note that the following vulnerabilities exist as shown in the screenshot above:

• SSL 3 enabled
• No support for TLS 1.2
• Server accepts RC4 cipher, but only with older protocol versions
• Server does not support Forward Secrecy with the reference browsers

Step #1 – Turn off SSLv3 and enable TLSv11 + TLSv12

The first step is to turn off SSLv3 and enable TLSv11 and TLSv12 on your Load Balancing Virtual Server(s) and NetScaler Gateway Virtual Servers.

The following screenshots shows where the settings are in the GUI for the Load Balancing Virtual Server named StoreFront-lbvip:

The command to execute are as follows:

set ssl vserver StoreFront-lbvip -ssl3 disabled

set ssl vserver StoreFront-lbvip -tls11 enabled

set ssl vserver StoreFront-lbvip -tls12 enabled

With the commands above executed, the protocols should now be displayed as such:

Repeat the same process for the NetScaler Gateway Virtual Servers.

The following screenshots shows where the settings are in the GUI for the NetScaler Gateway Virtual Servers named www.contoso.com_externaland www.contoso.com_internal:

The command to execute are as follows:

set ssl vserver www.contoso.com_external -ssl3 disabled

set ssl vserver www.contoso.com_external -tls11 enabled

set ssl vserver www.contoso.com_external -tls12 enabled

With the commands above executed, the protocols should now be displayed as such:

Step #2 – Create new custom Ciphers

The set of SSL Ciphers will allow us to score an A+ SSL scan on a NetScaler VPX appliance:

• TLS1-ECDHE-RSA-AES256-SHA
• TLS1-ECDHE-RSA-AES128-SHA
• TLS1-DHE-RSA-AES-256-CBC-SHA
• TLS1-DHE-RSA-AES-128-CBC-SHA
• TLS1-AES-256-CBC-SHA
• TLS1-AES-128-CBC-SHA
• SSL3-DES-CBC3-SHA

Execute the following to create a group named Custom-VPX-Cipher with the ciphers listed above:

add ssl cipher Custom-VPX-Cipher

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-RSA-AES256-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-RSA-AES128-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-DHE-RSA-AES-256-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-DHE-RSA-AES-128-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-AES-256-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-AES-128-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName SSL3-DES-CBC3-SHA

With the above commands successfully executed, we should now see the following Cipher Group created:

Step #3 – Bind new custom Ciphers to Load Balancing Servers

With the new cipher group created, proceed with binding them to the Load Balancing Virtual Server(s) and NetScaler Gateway Virtual Server(s):

bind ssl vserver StoreFront-lbvip -cipherName Custom-VPX-Cipher
bind ssl vs StoreFront-lbvip -eccCurveName ALL

bind ssl vserver www.contoso.com_external -cipherName Custom-VPX-Cipher
bind ssl vs www.contoso.com_external -eccCurveName ALL

bind ssl vserver www.contoso.com_internal -cipherName Custom-VPX-Cipher
bind ssl vs www.contoso.com_internal -eccCurveName ALL

----------------------------------------------------------------------------------------------------------------------------------------------

Note that I’ve found the binding process a bit finicky at times and had to unbind the cipher groups so if this is necessary, use the following commands:

unbind ssl vserver StoreFront-lbvip -cipherName DEFAULT

unbind ssl vserver www.contoso.com_external -cipherName DEFAULT

unbind ssl vserver www.contoso.com_internal -cipherName DEFAULT

----------------------------------------------------------------------------------------------------------------------------------------------

With the new cipher group binded to the virtual servers, we can use the following commands to review the bindings:

show ssl vserver StoreFront-lbvip

show ssl vserver www.contoso.com_external

show ssl vserver www.contoso.com_internal

Note that navigating to the ciphers binding in the GUI may throw the following warning:

No usable ciphers configured on the SSL vserver/service

I’ve done a bit of research on this and it appears we can safely ignore it.

Step #4 – Create a Deffie-Hellman (DH) key for Forward Secrecy

The following screenshots shows where to create the Deffie-Hellman (DH) key in the GUI of the NetScaler:

NetScaler > Traffic Management > SSL

The command to execute to create the Deffie-Hellman (DH) key is as follows:

create ssl dhparam /nsconfig/ssl/dhkey2048.key 2048 -gen 2

Note that the process could take a few minutes before completing so wait until the green cursor display changes to a >:

Reviewing the /nsconfig/ssl directory on the NetScaler should now show the dhkey2048.key key that was created:

Step #5 – Assign Deffie-Hellman (DH) key for Forward Secrecy to Virtual Server

With the Deffie-Hellman (DH) key successfully created, proceed with assigning it to the virtual servers.

The following screenshots shows where the settings are in the GUI:

Execute the following command to assign the key:

set ssl vserver StoreFront-lbvip -dh ENABLED -dhFile "/nsconfig/ssl/dhkey2048.key" -dhcount 1000

Repeat the process for the NetScaler Gateway Virtual Servers:

set ssl vserver www.contoso.com_external -dh ENABLED -dhFile "/nsconfig/ssl/dhkey2048.key" -dhcount 1000

set ssl vserver www.contoso.com_internal -dh ENABLED -dhFile "/nsconfig/ssl/dhkey2048.key" -dhcount 1000

Step #6 – Create a Rewrite Action and Policy for Strict Transport Security

Execute the following to create a Rewrite Action for Strict-Transport-Security:

add rewrite action act_sts_header insert_http_header Strict-Transport-Security q/"max-age=157680000"/

With the command above successfully executed, you should now see the following action created:

Execute the following to assign the Rewrite Action for to a policy:

add rewrite policy pol_sts_header TRUE act_sts_header

With the command above successfully executed, you should now see the following policy created with the action assigned:

Step #7 –  Bind the Strict Transport Security policy to the Virtual Servers

With the Strict Transport Security policy created, proceed with binding them to the virtual servers with the following commands:

bind vpn vserver www.contoso.com_external -policy pol_sts_header -priority 100 -gotoPriorityExpression END -type RESPONSE

bind vpn vserver www.contoso.com_internal -policy pol_sts_header -priority 100 -gotoPriorityExpression END -type RESPONSE

bind lb vserver StoreFront-lbvip -policy pol_sts_header -priority 100 -gotoPriorityExpression END -type RESPONSE

With the command above successfully executed, we should now see the policy binded to the virtual servers:

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

Having completed all the steps outlined above should now allow the NetScaler site to score an A+:

One of the frequent issues I’ve noticed the clients I work are coming across is the use of devices that have 3K or 4K resolution. These devices look great when running the native operating system but render connections to VMware Horizon View desktops unusable due to the small display size of the virtual desktop. Most administrators who have come across this issue most likely would have made an attempt to change the DPI of the virtual desktop only to find that the configuration screen is locked:

The way I got around this with my 3K display Mac a few years ago was to simply change the Windows virtual desktop resolution back to a lower setting then connect to the VDI but this defeats the purpose of having a high resolution display. Fast forward to a few years later when a client asked me to look into this again, it looks like VMware has included an experimental (unsupported) registry key addition for VMware Horizon View Client 3.4 or newer that allows DPI scaling so that the display is sized appropriately to the 3K or 4K device connecting to the desktop.

I’ve noticed that there appears to be several places where this registry key should be added depending on the operating system so I’ve included the 3 paths to check:

32-Bit Operating System:

HKCU\Software\VMware, Inc.\VMware VDM\Client

REG ADD "HKCU\Software\VMware, Inc.\VMware VDM\Client" /v EnableSessionDPIScaling /t REG_DWORD /d 1

64-Bit Operating System:

HKCU\Software\Wow6432Node\VMware, Inc.\VMware VDM\Client\

REG ADD "HKCU\Software\Wow6432Node\VMware, Inc.\VMware VDM\Client\" /v EnableSessionDPIScaling /t REG_DWORD /d 1

Surface Pro 3 64-Bit Operating System:

HKCU\Software\Policies\VMware, Inc.\VMware VDM\Client

REG ADD "HKCU\Software\Policies\VMware, Inc.\VMware VDM\Client" /v EnableSessionDPIScaling /t REG_DWORD /d 1

-------------------------------------------------------------------------------------------------------------------------------------------------------------

Hope this helps anyone who may be experiencing this issue.

Problem

You’ve just completed deploying Citrix Command Center 5.2 45.4 and attempt to add your NetScaler pair to the device list but the process fails with the following error:

Discovery failed for <NSIP>

Error: Unable to Ping using SNMP after enabling SNMP

Solution

One of the reasons why this error would be thrown is if the Citrix Command Center server is unable to access the NetScaler via UDP Port 161 as shown in the following firewall log capture:

To correct the issue, simply allow UDP port 161 from the Citrix Command Center to the NetScaler and initiate the add device process again:

Problem

You attempt to use the cmdlet Connect-MsolService in Windows Azure Active Directory Module for Windows PowerShell to connect to Azure but receive the following error:

PS C:\> Connect-MsolService
Connect-MsolService : Method not found: 'Void
System.Runtime.InteropServices.Marshal.PtrToStructure(IntPtr, !!0)'.
At line:1 char:1
+ Connect-MsolService
+ ~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [Connect-MsolService], Mis
   singMethodException
    + FullyQualifiedErrorId : System.MissingMethodException,Microsoft.Online.A
   dministration.Automation.ConnectMsolService

PS C:\>

Solution

One of the reasons why this error would be thrown is if you have an outdated Microsoft .NET Framework 4.5 on the operating system you are trying to connect from. If you are using Microsoft .NET Framework 4.5 as shown in the screenshot below then proceed by downloading Microsoft .NET Framework 4.5.2 and install it to correct the problem:

One of the more common questions I get asked by clients and colleagues is how to use group policy to configure UAC settings for Windows clients that mirror the 4 level presets that is available from within a Windows 7 desktop.  While I don’t have the configuration for levels 1 and 2, I do have the settings for 3 and 4 so I thought I’d write this quick blog post for others and my self to reference.

Level 3 UAC

To configure a Windows 7 desktop with level 3 UAC settings as shown in the following screenshot:

Configure the following settings in the Computer Configuration > Policies > Windows Settings > Security Settings > Local Polices > Security Options:

Level 4 UAC

To configure a Windows 7 desktop with level 4 UAC settings as shown in the following screenshot:

Configure the following settings in the Computer Configuration > Policies > Windows Settings > Security Settings > Local Polices > Security Options:

Hope this helps anyone who may be looking for this information.

Problem

You’re attempting to configure the email server settings in Citrix Command Center but notice that you receive the following error when you save the configuration:

Error

Connection to mail server failed, provide accurate mail settings

Solution

While there could be several reasons why this error is thrown, one of the more common causes I’ve seen at clients is that they’ve configured their anonymous receive connector correct to receive mail but had forgotten to uncheck the Require that all senders are authenticated option:

… for the Microsoft Exchange distribution group they’ve specified in the To Address:

If Require that all senders are authenticated option for the distribution group is required to be enabled then a receive connector that requires authentication should be created and user credentials should be filled in for the Configure Email Server Settings.

Problem

You’ve configured a new Network Policies policy on your Microsoft NPS server:

… with the following settings that will authenticate devices with machine certificates:

You configure the SSID on the wireless client with the certificate with the following settings:

… but notice that you receive the following error when attempting to connect:

Reviewing the INXXXX.log file in the directory C:\Windows\System32\LogFiles on the NPS server show that the wireless client authentication makes the connection attempt and the policy is matched:

"DC03","IAS",07/07/2016,20:32:46,3,,"contoso.internal/contoso/Computers/Desktops/Victoria_Place/IT/WKS-MXL2451S3K",,,,,,,,9,"10.80.9.249","contosobm-wlc2500-1",,,,,,,5,"Secure Wireless Connections Machine Authentication",262,"311 1 10.70.1.3 07/07/2016 23:09:55 79",,,,"Microsoft: Smart Card or other certificate",,,,,"577ee697/60:57:18:a7:ea:18/70380",,,,,,,,,,,,,,,,,,,,,,,,,"Use Windows authentication for all users",1,,,,

Reviewing the Security event logs on the NPS server show the following event ID 6273 Audit Failure event from the Microsoft Windows security auditing source:

Network Policy Server denied access to a user.

Contact the Network Policy Server administrator for more information.

User:
    Security ID:            contoso\WKS-MXL2451S3K$
    Account Name:            host/WKS-MXL2451S3K.contoso.internal
    Account Domain:            contoso
    Fully Qualified Account Name:    contoso.internal/contoso/Computers/Desktops/Victoria_Place/IT/WKS-MXL2451S3K

Client Machine:
    Security ID:            NULL SID
    Account Name:            -
    Fully Qualified Account Name:    -
    OS-Version:            -
    Called Station Identifier:        d8-b1-90-d0-6c-b0:corp-data
    Calling Station Identifier:        60-57-18-a7-ea-18

NAS:
    NAS IPv4 Address:        10.80.9.249
    NAS IPv6 Address:        -
    NAS Identifier:            contosobm-wlc2500-1
    NAS Port-Type:            Wireless - IEEE 802.11
    NAS Port:            13

RADIUS Client:
    Client Friendly Name:        contosobm-wlc2500-1
    Client IP Address:            10.80.9.249

Authentication Details:
    Connection Request Policy Name:    Use Windows authentication for all users
    Network Policy Name:        Secure Wireless Connections Machine Authentication
    Authentication Provider:        Windows
    Authentication Server:        SVRARDC03.contoso.internal
    Authentication Type:        EAP
    EAP Type:            Microsoft: Smart Card or other certificate
    Account Session Identifier:        35373765653762652F36303A35373A31383A61373A65613A31382F3730333831
    Logging Results:            Accounting information was written to the local log file.
    Reason Code:            262
    Reason:                The supplied message is incomplete.  The signature was not verified.

Solution

The key indicator of what would be causing this issue is the following line in the security event entry:

Reason:                The supplied message is incomplete.  The signature was not verified.

This usually indicates that the certificate presented by the NPS (RADIUS) server is not trusted by the wireless client.  The wireless client in this situation was not joined to the domain and since the certificate used by the server to verify its identity:

… is signed by an internal Microsoft CA, the wireless client did not trust it.  To correct the issue, simply export the Root and any intermediate CA certificates and import it onto the wireless client’s local computer store.

One of the most common questions I’ve been asked by clients is whether there is a way to audit administrators granting Full Access permissions to mailboxes in Exchange and the answer to that is yes because every action made within the Exchange Admin Center or Exchange Management Console can be logged by a feature named Administrator Audit Logging which basically logs every mirror Exchange cmdlet executed that isn’t a Get-.

Enable Administrator Audit Logging

The first step in the process of providing auditing logs is to execute the following cmdlet to ensure that logging is turned on:

Get-AdminAuditLogConfig | FL

Notice that the AdminAuditLogEnabled is set to True while the LogLevel is set to Verbose.  If the configuration is set to any other setting, execute the following to change it:

Set-AdminAuditLogConfig -AdminAuditLogEnabled $true
Set-AdminAuditLogConfig -LogLevel Verbose

More information about the Set-AdminAuditLogConfig can found at the following TechNet article: https://technet.microsoft.com/en-us/library/dd298169(v=exchg.160).aspx

Audit Option #1 - Review Admin Audit Log Report

Once administrator audit logging is enabled, we can review the Compliance Management > auditing > Admin Audit Log Report from within the Exchange Admin Center:

… configure a Start date and End date to narrow the return results:

Then sort the CMDLET column by alphabetical order and look for the cmdlet:

Add-MailboxPermission

or

Remove-MailboxPermission

… to review when and which administrator made the changes:

Audit Option #2 – Using PowerShell to search admin audit log

Another method for reviewing the admin audit log is to use PowerShell to search it and the cmdlet that allows us to accomplish this is Search-AdminAuditLog (TechNet: https://technet.microsoft.com/en-us/library/ff459250(v=exchg.160).aspx). The following cmdlets searches for either Add or Remove of mailbox permissions:

Search-AdminAuditLog -cmdlets Add-MailboxPermission

Search-AdminAuditLog -cmdlets Remove-MailboxPermission

Note that executing Search-AdminAuditLog without any parameters will only parse through 1,000 entries which may not cover a wide range of days so to ensure that specific dates are covered, include the StartDate and EndDate switches as such:

Search-AdminAuditLog -cmdlets Add-MailboxPermission -StartDate 01/24/2016 –EndDate 07/26/2016

Audit Option #3 - Review Admin Audit Log Report

The last option available is to review the event logs Applications and Services Logs > MSExchange Management logs in the Event Viewer:

Simply right click on MSExchange Management select Find…:

Then search for Add-MailboxPermission:

---------------------------------------------------------------------------------------------------------------------------------------------------------------

Hope this helps anyone out there looking for a way to audit actions performed within Exchange.

Problem

You’ve just completed configuring a new Citrix XenDesktop site on your first delivery controller and proceed to install XenDesktop onto the second delivery controller then select the Scale your deployment – Connect this Deliver Controller to an existing Site to connect the second delivery controller to the site:

You proceed to specify the first delivery controller’s FQDN:

… but the process does not complete and displays the following message:

There was a problem communicating with the server

Clicking on the View details button displays the following:

Error Id: XDDS:CCA074AC

Exception:

Citrix.Console.Models.Exceptions.CommunicationErrorException There was a problem communicating with the server.

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.PowerShellInteraction.SdkServiceBase.GetDatabaseScript(ICmdletExecutionHost cmdletExecutionHost, String instanceAddress, SdkScriptType sdkScriptType, String serviceGroupName, String controllerSid, Boolean databaseIsLocal, String databaseName, DataStore dataStore)

at Citrix.Console.PowerShellSdk.DatabaseService.Scripts.GenerateSchemasScript.RunScript()

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

at Citrix.Console.PowerShellSdk.DatabaseService.PSDatabaseService.AddControllerToDatabases(IEnumerable`1 databaseCredentials, String configServiceAddress, ScriptExecutionContext context, String controllerToAddAddress)

at Citrix.Console.PowerShellSdk.SiteService.Scripts.JoinExistingSiteScript.RunScript()

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

at Citrix.Console.DeliveryCenter.UI.Dialogs.JoinExistingSiteDialogViewModel.OkBackgroundOperation(IProgressReporter progressReporter)

at Citrix.Console.Common.OperationTimer.TimeBlock(Action operation)

at Citrix.Console.CommonControls.ProgressDisplay.GenericProgressOperationWithFeedBack.PerformOperationInternal()

at Citrix.Console.CommonControls.ProgressDisplay.ProgressWindowOperation.PerformOperation()

at Citrix.Console.CommonControls.ProgressDisplay.ProgressWindowViewModel.PerformAction(Action operationComplete)

DesktopStudio_ErrorId : CommunicationError

Sdk Error Message : An invalid URL was given for the service. The value given was 'SVR-CTXDC-02.ccs.int'.

The reason given was: Failed to connect to back-end server 'SVR-CTXDC-02.ccs.int' on port 80 using binding WSHttp. The server may be off-line or may not be running the appropriate service

The HTTP service located at http://svr-ctxdc-02.ccs.int/Citrix/AdIdentityContract/v2 is unavailable. This could be because the service is too busy or because no endpoint was found listening at the specified address. Please ensure that the address is correct and try accessing the service again later.

The remote server returned an error: (503) Server Unavailable..

Sdk Error ID : Citrix.XDPowerShell.Status.CommunicationError,Citrix.ADIdentity.Sdk.DataStore.Commands.GetAcctDBSchemaCommand

ErrorCategory : ResourceUnavailable

DesktopStudio_PowerShellHistory : JoinExistingSiteScript

8/22/2016 9:44:04 PM

Get-ConfigDBConnection -AdminAddress "svr-ctxdc-01.ccs.int"

Get-AcctDBSchema -AdminAddress "SVR-CTXDC-02.ccs.int" -DatabaseName "CitrixBakery LaneSite" -ScriptType "Instance"

Get-AcctDBSchema : An invalid URL was given for the service. The value given was 'SVR-CTXDC-02.ccs.int'.

The reason given was: Failed to connect to back-end server 'SVR-CTXDC-02.ccs.int' on port 80 using binding WSHttp. The server may be off-line or may not be running the appropriate service

The HTTP service located at http://svr-ctxdc-02.ccs.int/Citrix/AdIdentityContract/v2 is unavailable. This could be because the service is too busy or because no endpoint was found listening at the specified address. Please ensure that the address is correct and try accessing the service again later.

The remote server returned an error: (503) Server Unavailable..

+ CategoryInfo : InvalidOperation: (:) [Get-AcctDBSchema], InvalidOperationException

+ FullyQualifiedErrorId : Citrix.XDPowerShell.Status.CommunicationError,Citrix.ADIdentity.Sdk.DataStore.Commands.GetAcctDBSchemaCommand

Inner Exception:

System.InvalidOperationException An invalid URL was given for the service. The value given was 'SVR-CTXDC-02.ccs.int'.

The reason given was: Failed to connect to back-end server 'SVR-CTXDC-02.ccs.int' on port 80 using binding WSHttp. The server may be off-line or may not be running the appropriate service

The HTTP service located at http://svr-ctxdc-02.ccs.int/Citrix/AdIdentityContract/v2 is unavailable. This could be because the service is too busy or because no endpoint was found listening at the specified address. Please ensure that the address is correct and try accessing the service again later.

The remote server returned an error: (503) Server Unavailable..

at System.Management.Automation.MshCommandRuntime.ThrowTerminatingError(ErrorRecord errorRecord)

Inner Exception:

System.ServiceModel.CommunicationException Failed to connect to back-end server 'SVR-CTXDC-02.ccs.int' on port 80 using binding WSHttp. The server may be off-line or may not be running the appropriate service

at Citrix.Fma.Sdk.CommonCmdlets.AdminConnection`1..ctor(ConnectionSpec connectionSpec)

at Citrix.Fma.Sdk.CommonCmdlets.AdminConnection`1.GetAdminConnection(String serverPortString, String endpointAddress, Nullable`1 binding)

at Citrix.Fma.Sdk.CommonCmdlets.CommonCmdletBase.CreateProxy(String adminAddress, String endpointAddress, Nullable`1 adminBinding)

at Citrix.Fma.Sdk.CommonCmdlets.WcfCmdletBase`1.OpenConnection(Boolean terminateOnFailure)

Inner Exception:

System.ServiceModel.ServerTooBusyException The HTTP service located at http://svr-ctxdc-02.ccs.int/Citrix/AdIdentityContract/v2 is unavailable. This could be because the service is too busy or because no endpoint was found listening at the specified address. Please ensure that the address is correct and try accessing the service again later.

Server stack trace:

at System.ServiceModel.Security.IssuanceTokenProviderBase`1.DoNegotiation(TimeSpan timeout)

at System.ServiceModel.Security.SspiNegotiationTokenProvider.OnOpen(TimeSpan timeout)

at System.ServiceModel.Security.WrapperSecurityCommunicationObject.OnOpen(TimeSpan timeout)

at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)

at System.ServiceModel.Security.CommunicationObjectSecurityTokenProvider.Open(TimeSpan timeout)

at System.ServiceModel.Security.SymmetricSecurityProtocol.OnOpen(TimeSpan timeout)

at System.ServiceModel.Security.WrapperSecurityCommunicationObject.OnOpen(TimeSpan timeout)

at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)

at System.ServiceModel.Channels.SecurityChannelFactory`1.ClientSecurityChannel`1.OnOpen(TimeSpan timeout)

at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)

at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.DoOperation(SecuritySessionOperation operation, EndpointAddress target, Uri via, SecurityToken currentToken, TimeSpan timeout)

at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.GetTokenCore(TimeSpan timeout)

at System.IdentityModel.Selectors.SecurityTokenProvider.GetToken(TimeSpan timeout)

at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.OnOpen(TimeSpan timeout)

at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)

at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)

at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)

Exception rethrown at [0]:

at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)

at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

at System.ServiceModel.ICommunicationObject.Open()

at Citrix.Fma.Sdk.CommonCmdlets.AdminConnection`1..ctor(ConnectionSpec connectionSpec)

Inner Exception:

System.Net.WebException The remote server returned an error: (503) Server Unavailable.

at System.Net.HttpWebRequest.GetResponse()

at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)

You notice the following error while parsing through the log output:

DesktopStudio_ErrorId : CommunicationError

Sdk Error Message : An invalid URL was given for the service. The value given was 'SVR-CTXDC-02.ccs.int'.

The reason given was: Failed to connect to back-end server 'SVR-CTXDC-02.ccs.int' on port 80 using binding WSHttp. The server may be off-line or may not be running the appropriate service

The HTTP service located at http://svr-ctxdc-02.ccs.int/Citrix/AdIdentityContract/v2 is unavailable. This could be because the service is too busy or because no endpoint was found listening at the specified address. Please ensure that the address is correct and try accessing the service again later.

The remote server returned an error: (503) Server Unavailable..

Solution

One of the reasons why this error would be thrown is if the following 2 services is not started:

1. Citrix AD Identity Service
2. Citrix App Library

Simply starting the 2 services and rerunning the Connect this Deliver Controller to an existing Site will allow you to connect the new delivery controller to the site.

Problem

You’ve noticed that the following error is thrown when you attempt to connect to a VMware Horizon View virtual desktop through the security server with the VMware Horizon Client:

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

The following information is logged in the events:

Severity: Audit failure

Module: Connection Server

Message: Unable to launch from Pool <desktopPoolName> for user domain\username

More Information: Unable to launch from Pool <desktopPoolName> for user domain\username: No co-management availability for protocol PCoIP

Attempting to use the Blast protocol from the View client will present a black screen:

… then thrown the following error:

The connection to the remote computer ended

Attempting to use the browser to login:

… will briefly present a triangle and exclamation mark for the desktop:

Then display the following error:

An error has occurred: {"code":"ETIMEDOUT","errno":"ETIMEDOUT","syscall":"connect","address":"10.34.30.60","port":22443}

Solution

One of the reasons why these errors would be thrown is if the following ports are not opened between the Security servers to the virtual desktops:

• TCP/UDP 4172
• TCP 22443
• TCP 32111
• UDP 22443
• TCP 9427

Verify the ports above and all other ports identified in the following KB:

VMware View ports and network connectivity requirements (1027217)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1027217

Problem

You’ve used the Connect-MsolService cmdlet to connect to the WAAD instance then attempt to execute the Set-MsolADFSContext -computer <ADFSserver>.domain.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.

Problem

You’ve installed or upgraded to the latest VMware Horizon Agent onto a Windows 7 virtual desktop:

… but quickly noticed that you are no longer able to RDP to the virtual machine as the following error message is thrown:

This computer can’t connect to the remote computer.

Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator.

Proceeding to review the System logs on the Windows 7 virtual desktop displays the following error message every time you attempt to remote desktop to the machine:

Log Name: System

Source: Schannel

Event ID: 36871

Level: Error

One of the common troubleshooting steps that typically show up during searches on the internet is to Enable the Require use of specific security layer for remote (RDP) connections and set the Security Layer to Negotiate as shown in the following screenshot:

Unfortunately, the solution above does not correct the problem.

Windows 10 virtual desktops does not appear to exhibit this issue.

Solution

One of the reasons why installing the Horizon View 7 agent would cause this issue is because the installation appears to disable TLS 1.0 on the Windows 7 desktop if it is not already disabled.  You can confirm this by launching the registry editing on the desktop and navigating to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server\

Note that the Enabled REG_DWORD in the screenshot above is set to 0 which is disabled.  You can quickly get RDP to work again by changing the value to 1 but this is not the best solution as it is best practice to leave TLS 1.0 off.

----------------------------------------------------------------------------------------------------------------------------------------------------------------

**Note that downgrading the View agent to 6.2 would actually remove the TLS 1.0 key in the registry thus re-enabling it and causing RDP to work again:

----------------------------------------------------------------------------------------------------------------------------------------------------------------

The proper steps to correct this issue is to ensure that the patch supplied in the following KB article is installed onto the Windows 7 desktop:

Update to add RDS support for TLS 1.1 and TLS 1.2 in Windows 7 or Windows Server 2008 R2
https://support.microsoft.com/en-us/kb/3080079

Download the .msu file:

Complete the install:

… and RDP should now work again.

I’ve been asked the several times in the past by colleagues about what is the best way to remotely configure the Startup type and Service status of a Windows desktop or server so I thought it would be good to write a blog post so I could direct these questions to.

The method I use to remotely configure a service is the sc command as described in the following TechNet article:
https://technet.microsoft.com/en-us/library/bb490995.aspx

#1 – Review a service’s properties (Startup type)

To review a remote computer’s service’s property, execute the following:

sc \\<computerName> qc wsearch

The following is an example of the output:

C:\>sc \\tmrsvd-048 qc wsearch

[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: wsearch

TYPE : 10 WIN32_OWN_PROCESS

START_TYPE : 2 AUTO_START (DELAYED)

ERROR_CONTROL : 1 NORMAL

BINARY_PATH_NAME : C:\Windows\system32\SearchIndexer.exe /Embedding

LOAD_ORDER_GROUP :

TAG : 0

DISPLAY_NAME : Windows Search

DEPENDENCIES : RPCSS

SERVICE_START_NAME : LocalSystem

C:\>

Note that the above output would tell you the Startup Type.

#2 – Review a service’s status (Service status)

To review a remote computer’s service’s status, execute the following:

sc \\<computerName> query wsearch

The following is an example of the output:

C:\>sc \\tmrsvd-024 query wsearch

SERVICE_NAME: wsearch

TYPE : 10 WIN32_OWN_PROCESS

STATE : 4 RUNNING

(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)

WIN32_EXIT_CODE : 0 (0x0)

SERVICE_EXIT_CODE : 0 (0x0)

CHECKPOINT : 0x0

WAIT_HINT : 0x0

C:\>

Note that the above output would tell you the Service status (whether it is running or stopped).

#3 – Configure a service’s Startup Type

To configure a remote computer’s service’s Startup Type, execute the following:

sc \\<computerName> config wsearch start=<startup Type>

The startup type options are as follows:

1. auto
2. demand
3. disabled
4. delayed-auto

**Note that demand is manual.

More information about the switches can be found in the following TechNet article:
https://technet.microsoft.com/en-us/library/cc990290(v=ws.11).aspx

The following is an example of the output:

C:\>sc \\tmrsvd-075 config wsearch start=delayed-auto

[SC] ChangeServiceConfig SUCCESS

#4 – Starting or stopping a service

To start or stop a remote computer’s service, execute the following:

sc \\<computerName> <start or stop> wsearch

More information about the switches can be found in the following TechNet article:
https://technet.microsoft.com/en-us/library/cc742126(v=ws.11).aspx

The following is an example of the output:

C:\>sc \\tmrsvd-075 stop wsearch

SERVICE_NAME: wsearch

TYPE : 10 WIN32_OWN_PROCESS

STATE : 3 STOP_PENDING

(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)

WIN32_EXIT_CODE : 0 (0x0)

SERVICE_EXIT_CODE : 0 (0x0)

CHECKPOINT : 0x1

WAIT_HINT : 0x7530

C:\>

C:\>sc \\tmrsvd-075 start wsearch

SERVICE_NAME: wsearch

TYPE : 10 WIN32_OWN_PROCESS

STATE : 2 START_PENDING

(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)

WIN32_EXIT_CODE : 0 (0x0)

SERVICE_EXIT_CODE : 0 (0x0)

CHECKPOINT : 0x4

WAIT_HINT : 0x7530

PID : 4172

FLAGS :

C:\>

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

With the commands above, we can create a batch file to bulk configure a set of computers as such:

rem --Used to set service to auto delayed start and then start the service--

sc \\computer-071 config wsearch start=delayed-auto
sc \\computer-071 start wsearch
sc \\computer-072 config wsearch start=delayed-auto
sc \\computer-072 start wsearch
sc \\computer-073 config wsearch start=delayed-auto
sc \\computer-073 start wsearch
sc \\computer-074 config wsearch start=delayed-auto
sc \\computer-074 start wsearch
sc \\computer-075 config wsearch start=delayed-auto
sc \\computer-075 start wsearch

rem --Used to check service--

sc \\computer-024 query wsearch
sc \\computer-024 qc wsearch
sc \\computer-075 query wsearch
sc \\computer-075 qc wsearch

Hope this helps anyone looking for an easy way to configure a remote computer’s service.

While most enterprise organizations typically have deployment applications such as SCCM for new or upgrades of applications, some smaller companies may not and tasks such as upgrading the VMware Horizon View agent may become quite labour intensive if the environment uses full clone desktops that exceed a count of, say, 20. This was the scenario I faced recently at a small organization and rather than manually logging into each full clone virtual desktop to upgrade the VMware Horizon View agent, I decided to use Group Policy GPO for the task.

The first item we need prior to setting up the GPO is to obtain the command that performs a silent install of the VMware Horizon View agent and this command can be found in the following KB:

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1019862

The install switches is shown in line item #4:

4. Open a command prompt on the desktop and run this command:

VMware-viewagent.exe /S /V"/qn REBOOT=Reallysuppress"

Note: REBOOT=Reallysuppress suppresses a reboot after the install. If you remove REBOOT=Reallysuppress, the machine automatically reboots after the install.

Since we would like to automatically install the VMware View Agent without any administrator intervention, we will remove the REBOOT=Reallysuppress switch so an auto reboot would be triggered after the install.

As a result, the switches added to the installation executable we’ll be running would be as such: VMware-viewagent.exe /S /V"/qn

Placing the VMware View Agent executable onto a share named ViewAgentShare on a file server named fileserver would look as such:

\\fileserver\ViewAgentShare\VMware-viewagent-x86_64-7.0.2-4368292.exe /S /V"/qn

With the above prepared, the next step is to create a GPO, navigate to Computer Configuration > Policies > Windows Settings > Scripts (Startup/Shutdown),double click on Startup then create a batch file as shown in the screenshot below:

Once the GPO has been created, proceed to create an OU for the VMware Horizon View agent deployment, place the full clone virtual desktops’ computer objects into the OU, restart the actual VDI and you should see the agent being silently installed.

The only caveat with this method is that you will need to move the computer object out of the deployment OU once the deployment has started or before the desktop reboots or it would attempt to perform another silent install after the restart.

Hope this helps anyone looking for a quick way to deploy a new or upgrade an existing VMwar View agent.

I ran into an interesting problem at a client this week when I had to request a new certificate from their 2-tier, standalone Root CA and subordinate Enterprise CA, certificate authority infrastructure where a certificate template that we created by duplicating the Web Server template naming it Web Server Exportable then published would not show up in web enrollment request options.  The following are screenshots of the behavior of the web enrollment page after removing all of the published certificate templates and leaving the one I want to use:

https://<subordinateCA>/certserv

No certificate templates could be found. You do not have permission to request a certificate from this CA, or an error occurred while accessing the Active Directory.

Note the (No templates found!)listedin the Certificate template: drop down box:

After troubleshooting for a couple hours and attempting the following solutions found on the internet:

Verified the following KB was not the issue: https://support.microsoft.com/en-us/kb/811418

1. Check to ensure the security permissions for the certificate template was set appropriately
2. Ensure that Supply in the request was selected under the Subject Name tab
3. Created a new application pool and assigned the Certsrv directory to it
4. Ensure certificate template compatibility was the same or below the domain and forest functional level
5. Changed the application pool’s advanced settings identity from ApplicationPoolIdentity to NetworkService

... which did not correct my issue, I went ahead and opened a case with Microsoft.

What we noticed was that we would be able to get the published template to show up if we changed the name from Web Server Exportable to Web_Server_Exportable,using a a different name.  This lead the engineer to suspect that there might be something lingering in AD that was causing the template with the original name not to show up in the web enrollment webpage.  To troubleshoot, we exported the Configuration container information to a text file via the ldifde command as such:

ldifde -f out.txt -d "CN=Configuration,DC=ad,DC=domain,DC=bm"

We then did a find on the exported out.txt file and immediately found an entry for WebServerExportable:

What we found was that another certificate authority in Active Directory which was an Enterprise Root CA  had a template published with the same name.  Logging onto that server and launching the Certificate Authority administration console showed the following:

The template listed as <Unknown> was what caused the template on the other CA to not be displayed so we went ahead and removed the template, forced an Active Directory replication with repadmin /syncall /AdePq, reran the ldifde export to confirm the template was no longer listed under this CA, then confirmed that the template is now shown in the web enrollment page.

Hope this post helps anyone who may come across a situation similar to this.

Ran into an interesting problem this week that seemed trivial but ended up causing quite a bit of headache so I thought it would be great to write this short blog post in case someone else runs into the same issue.

Problem

You’ve noticed that one of your file servers contain a file that has a name too long to move or copy to another destination because the following message is presented when an attempt is made:

The file name(s) would be too long for the destination folder. You can shorten the file name and try again, or try a location that has a short path.

Reviewing the file name shows that it is extremely long:

This file name is so long that the server doesn’t provide the choice to rename it and it would fail even if an attempt is made to copy it onto the C drive:

Note the only options available in the screenshot above when you right click on the file are:

• Open with
• Send to
• Compressed (zipped) folder
• Desktop (create shortcut)
• Mail recipient

Attempting to use the command prompt to rename the file would throw the following error:

The filename or extension is too long.

Other troubleshooting steps that were tried but yield the same results are as follows:

1. Copy and paste to a higher level folder (no surprise as copying it to the C drive which would have generated the shortest path did not work)
2. Copying to the desktop
3. Copying to another network drive
4. Renaming a top level folder
5. Attempting to open the file with Adobe Acrobat so we could resave it

Solution

After trying to other steps such as renaming the top level folders and not being able to, what we found was that if we used an application such as WinRAR to compress the file into a .rar file, we would then be able to rename it to a shorter file name within the compressed file, then extract the new renamed file back onto the file server.

Hope this helps anyone who may encounter such an issue on their file server.

Problem

I’ve had a several clients call me in regards to a common issue when upgrading VMware Horizon View to veresion 7.0.x where their vCenter Servers status is labeled with the red colour and the Status is listed as UntrustedCertificate but clicking on the Verify button does nothing:

Status: Untrusted Certificate Verify

For self-signed certificate, click ‘Verify’. If the vCenter Server certificate can be validated, make sure that the trusted store on the Connection Server system has the correct Certification Authorities.

SSL Certificate: Invalid

I find that this issue throws a lot of administrators off because previous versions simply allow you to click on the Verify button, accept the self-signed certificate, and you’re on your way but version 7 appears to render the button clickable but does nothing when you click on it other than give you a click symbol as if it was doing something:

Solution

The reason why this would happen is if the vCenter in the environment is running an earlier release of vCenter Server 5.0, 5.1, and 5.5 where only TLSv1.0 is supported. VMware Horizon 7 and later components have TLSv1.0 disabled and thus causes this strange behavior to occur.  More information can be found in the deployment guide here:

View Installation
VMware Horizon 7 Version 7.0
VMware Horizon 7 Version 7.0.1
VMware Horizon 7 Version 7.0.2
http://pubs.vmware.com/horizon-7-view/topic/com.vmware.ICbase/PDF/view-70-installation.pdf

To resolve this issue, either upgrade vCenter Server to 6.0 Update 1B or workaround the issue by re-enabling TLSv1.0 on the VMware View Composer as outlined in the following KB:

Unable to verify vCenter certificate in VMware View Administrator (2144967)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2144967

Re-enable TLSv1.0 on enable VMware View Composer

To re-enable TLSv1.0 on enable VMware View Composer:

1. Click Start> Run, type regedit, and click OK. The Registry Editor window opens.

2. Navigate to HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS1.0\Client
Note: If this key does not already exist, create the key.

3. Delete the value Enabled if it exists.

4. Edit the DWORD value DisabledByDefault and set it to 0.

5. Restart the VMware View Composer service. TLSv1.0 connections from View Composer to vCenter are now enabled.

6. Navigate to HKLM\SOFTWARE\VMware,Inc.\VMware View Composer.

7. Create or edit the String value EnableTLS1.0 and set it to 1.

8. If the View Composer host is a 64-bit machine, navigate to HKLM\SOFTWARE\WOW6432Node\VMware,Inc\VMware View Composer.

9. Create or edit the String value EnableTLS1.0 and set it to 1.

10. Restart the VMware Horizon View Composer service.TLSv1.0 connections from View Composer to ESXi hosts are now enabled.

Re-enable TLSv1.0 on enable VMware Connection Server

To re-enable TLSv1.0 on enable VMware Connection Server:

1. Start the ADSI Edit utility on your View Connection Server host.

2. In the console tree, select Connect to.

3. In the Select or type a Distinguished Name, type the distinguished name DC=vdi,DC=vmware, DC=int.

4. In the Computer pane, select or type localhost:389 or the fully qualified domain name (FQDN) of the View Connection Server host followed by port 389.

5. Expand the ADSI Edit tree, expand OU=Properties, select OU=Global, and double-click CN=Common.

6. In the Properties dialog box, edit the pae-ClientSSLSecureProtocols attribute to add this entry:
\LIST:TLSv1.2,TLSv1.1,TLSv1

7. Click OK.

8. Restart the VMware Horizon View Connection Server service on each connection server instance.

Problem

You’re attempting to install the latest cumulative update onto your Exchange 2016 server (Microsoft Exchange Server 2016 Cumulative Update 3 in this example) but notice that the process fails at:

Step 4 of 11: Mailbox role: Transport service

… with the following error message:

Error:
The following error was generated when "$error.Clear();
          Install-ExchangeCertificate -services IIS -DomainController $RoleDomainController
          if ($RoleIsDatacenter -ne $true -And $RoleIsPartnerHosted -ne $true)
          {
            Install-AuthCertificate -DomainController $RoleDomainController
          }
        " was run: "System.Security.Cryptography.CryptographicException: The certificate is expired.
   at Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target, Boolean reThrow, String helpUrl)
   at Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)
   at Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.InternalProcessRecord()
   at Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__b()
   at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)".

The installation does not proceed and you are forced to close the installer.  Attempting to run the installer again will restart the process but fail with the same error message.

Solution

One of the reasons why this error would be thrown is if you have an expired certificate still binded in IIS as shown in the following screenshot where one of the two https directories have the updated certificate but the other one does not:

To correct the issue, simply update the binding or bindings with a non-expired certificate and rerun the installation.  Note that it is ok to have the expired certificate in the local store of the server but it should not be binded.