Skype for Business front-end server logs the event ID error 32054: “Storage Service had an EWS Autodiscovery failure.”

Problem

You’ve received complaints from users that they are experiencing out of sync messages between devices such as their mobile phones compared to the Skype for Business clients.  Logging onto the Skype for Business front-end server and reviewing the Lync Server logs show that event ID 32054 errors are logged and refer to the users who have complained about the issue:

Log Name: Lync Server
Source: LS Storage Service
Event ID: 32054

Storage Service had an EWS Autodiscovery failure.

StoreWebException: code=ErrorEwsAutodiscover, reason=GetUserSettings failed, smtpAddress=ssteele@contoso.com, Autodiscover Uri=https://autodiscover.contoso.com/autodiscover/autodiscover.svc, Autodiscover WebProxy=<NULL>, WebExceptionStatus=NameResolutionFailure ---> System.Net.WebException: The remote name could not be resolved: 'autodiscover.contoso.com'

   at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)

   at System.Net.HttpWebRequest.GetRequestStream()

   at Microsoft.Exchange.WebServices.Autodiscover.AutodiscoverRequest.InternalExecute()

   --- End of inner exception stack trace ---

   at Microsoft.Rtc.Internal.Storage.Exchange.ExchangeContext.SendGetUserSettingsRequest(StoreContext ctx, String smtpAddress)

   at Microsoft.Rtc.Internal.Storage.Exchange.ExchangeContext.GetUserEwsSettings(StoreContext ctx, String smtpAddress, CacheMode cacheMode)

Cause: Autodiscovery Uri was not correctly configured or unreachable, that there is a problem with the Proxy, or other errors.

Resolution:

Check event details.  Check autodiscovery Uri is properly configured and reachable. Check that proxy setting is properly configured and reachable.  Validate Skype for Business to Exchange Autodiscovery configuration by following the trouble shooting guide. If problem persists, notify your organization's support team with the event details.

Solution

One of the reasons why this event error would be logged causing the out of sync messages is if the Exchange autodiscover URL is unreachable as indicated in the event ID details:

StoreWebException: code=ErrorEwsAutodiscover, reason=GetUserSettings failed, smtpAddress=ssteele@contoso.com, Autodiscover Uri=https://autodiscover.contoso.com/autodiscover/autodiscover.svc, Autodiscover WebProxy=<NULL>, WebExceptionStatus=NameResolutionFailure ---> System.Net.WebException: The remote name could not be resolved: 'autodiscover.contoso.com'

The environment where I encountered this issue did not use the standard Exchange autodiscover URL and therefore caused this issue for their SfB users.  One of the workarounds for this issue is to manually configure Skype for Business to use a different autodiscover URL but before doing so, confirm that there isn’t already an existing manually created configuration by executing the cmdlet:

Get-CsOAuthConfiguration

Note that a standard configuration should provide output similar to the above.  Having confirmed that the existing configuration is standard, proceed to execute the following cmdlet to manually configure a reachable Exchange autodiscover URL:

Set-CsOAuthConfiguration -ExchangeAutodiscoverUrl "https://<TheAutoDiscoverDomain>/autodiscover/autodiscover.svc" -Realm "<theSIPdomain>" -Exchange AutodiscoverAllowedDomains "*.<sipDomain>.com"

The event log errors should clear and the following information event will be logged once the SfB front-end server is able to reach the Exchange autodiscover service via the newly configured autodiscover URL.

Log Name: Lync Server
Source: LS Autodiscover
Event ID: 32007
Level: Information

Autodiscover OAuth configuration was successfully retrieved.

Unable to assign a newly requested certificate to a Skype for Business Edge server

Problem

You’ve just used the Skype for Business Server 2015 – Deployment Wizard to request a certificate for the internal interface of the Lync Edge server:

The process completes with warnings:

Viewing the logs displays the following warning:

Warning: The chain of the certificate "CA6EEEC4F50136BCDF70F2A6369C3189F4B7F980" is invalid.

Clicking the Next button displays the following message:

A certificate with thumbprint CA6EEEC4F50136BCDF70F2A6369C3189F4B7F980 has been added to the local certificate store.

The certificate has been issued by the online certification authority and is installed to the local certificate store, however it is not valid. Make sure that the Root certificate, and necessary certificate chain is installed on this server.

You notice that it is not available to be assigned and launching the properties of the certificate display the following:

The integrity of this certificate cannot be guaranteed. The certificate may be corrupted or may have been altered.

Clicking on the Certification Path tab displays the following Certificate status:

This certificate has an invalid digital signature.

Clicking on the Root CA shows This certificate is OK for the Certificate status indicating there are no issues with the Root Certificate Authority:

However, opening the properties of the Root certificate displays properties that does not appear to be expected root CA. In this example, I noticed that the Valid from date was incorrect (it appeared to belong to the old root CA’s certificate):

The Signature algorithm and Signature hash algorithm was also incorrect because I had upgraded them to sha256:

What I did was launch the Certification Authority management console on the root CA and locate the issued certificate:

The properties showed that the status was in a healthy state:

Opening the properties of the root CA certificate confirmed my suspicion that the Skype for Business Edge server is displaying a different root CA as the issuer of the certificate because the Valid from dates were different:

The Signature algorithm and Signature hash algorithm was shown and expected to be sha256:

Solution

One of the causes of such an issue is if you haven’t updated the root certificate in the Trusted Root Certification Authorities on the Skype for Business Edge server:

In this example, the server had the older sha1 certificate but not the newer sha256 so it seemingly decided to display the newly issued certificate as one created by the old CA. To correct this problem, export and import the new sha256 root certificate into the Trusted Root Certification Authorities on the Skype for Business Edge server and the newly issued certificate for the Edge server will be displayed properly so you can assign to the Edge service.

Minimizing and restoring Windows Server 2016 RDS RemoteApp causes a frozen black screen to be displayed

Update: July 11, 2018

The support engineer gave me a call back yesterday and said this is apparently a known issue at Microsoft and a patch is supposed to be released at some point.  He could not provide an exact ETA but said possibly in August 2018.

Problem

You’ve deployed a new Windows Server 2016 RDS environment and published RemoteApps but received complains that when a user’s session times out after the configured idle limit, they receive the following Windows and unable to click the OK button:

Idle timer expired

Session has been idle over its time limit.

It will be disconnected in 2 minutes.

Click OK to stay connected.

The problem with the window above is that the RDS RemoteApp session has disconnected but the window indicating the end of the session is stuck behind this warning window. There is really nothing the user can do to get the window in the background to get on top of this one so they need to terminate the RDS session via the task bar.

One of the solutions that correct this issue is to disable the Use advanced RemoteFX graphics for RemoteApp configuration found:

Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment

Disabling this feature corrects the problem but it creates a new problem where if the user’s desktop launching the RemoteApp does not have the left most monitor as their primary monitor:

What happens with this setup for users is that they would launch the RemoteApp without any issues:

The application will work as expected but if the user minimizes it:

Then attempts to restore the RemoteApp, the application will attempt to be restored on the left non-primary monitor and display a black screen that the user cannot interact with:

This appears to only be a display issue because the user can right-click on the application in the task bar, close it, relaunch the application and not lose any work. What’s strange is that this does not appear to affect applications that are not maximized meaning if the application was launched and then minimized as such:

The application would restore without any issues. Another alternative workaround is to configure the left most monitor as the primary:

Another workaround I was able to find was to limit the amount of monitors for the RemoteApps with the Limit number of monitors configuration:

While this corrects the issue, it restricts the application to the primary monitor disallowing the user to drag the window to the left or any other monitor and this was likely going to be very annoying.

I had opened a case with Microsoft about two weeks back, which was closed because I couldn’t replicate it on my desktop (I always use my left most monitor as primary) but have been since reopened this week after figuring this out. The engineer hasn’t called me back yet but knowing the cause allowed me to find this forum post discussing the same problem on Windows 10:

[Windows 10 1709] Issues when maximizing RDP App

https://social.technet.microsoft.com/Forums/lync/en-US/831fda26-1336-4806-a3eb-8b989e023a52/windows-10-1709-issues-when-maximizing-rdp-app?forum=win10itprogeneral

I had this issue too. I found that re-enabling remotefx on session servers made the issue go away. But now window focus is messed up, when a new window pop up in a remote application it goes behind the main application until user clicks out of the app, the pop up will appear.

The environment I’m experiencing this problem uses Windows 7 as the desktop so I can confirm that this isn’t limited to Windows 10. There isn’t a resolution in the forum post so I hope to get to the bottom of this and share the resolution.

Creating an Exchange / Outlook warning banner for external recipients

Many of the clients I work with have been taken an interest in implementing warning banners for all emails received from outside of their organizations in an effort to combat the ever increasing phishing emails that make it through their SPAM filters.  A great write up by Joe Palarchio can be found here:

Office 365 – Providing Your Users Visual Cues About Email Safety
https://blogs.perficient.com/2016/04/04/office-365-providing-your-users-visual-cues-about-email-safety/

The blog post provides a great description for the configuration but many of the clients I work with felt the colours and border weren’t as prominent as they would like so I’d like to share the HTML code I use to generate the following banner for anyone who may want to use it:

Note that this is a mail flow rule:

The following is the HTML code:

<div style='border:dotted #003333 1.0pt;padding:1.0pt 1.0pt 1.0pt 1.0pt'>

<p class=MsoNormal style='background:#F4DF11'><span lang=EN-GB
style='font-size:10.0pt;font-family:"Cambria",serif;color:red;mso-ansi-language:
EN-GB;mso-fareast-language:EN-GB'>CAUTION:</span><span lang=EN-GB
style='font-size:10.0pt;font-family:"Cambria",serif;color:black;mso-ansi-language:
EN-GB;mso-fareast-language:EN-GB'> This email originated from outside of the
organization. Do not click links or open attachments unless you recognize the
sender and know the content is safe.</span><span lang=EN-GB style='font-size:
12.0pt;font-family:"Times New Roman",serif;mso-ansi-language:EN-GB;mso-fareast-language:
EN-GB'><o:p></o:p></span></p>

</div>
<BR>

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

Note that my experience with the implementation banner was well received by IT infrastructure teams but often poorly received by users because such a banner fills up the body preview on smart phones rendering that feature to become useless so it would be wise to pilot this with users before implementing it globally.

Creating a new Windows Server 2016 RDS Collection fails with: ".FQDN Unable to configure the RD Session Host server .FQDN. Invalid operation"

Problem

You need to add an additional RD Session Host Server to an existing RDS deployment then create a new RDS Collection with the server so you proceed to add the server:

Once you’ve successfully added the server, you proceed to add the server as a RD Session Host Servers in the Remote Desktop Services management console:

Once successfully added as a RD Session Host server, you proceed to create a new collection with the server:

The collection is successfully created by the add server operation fails with the following error message:

<ServerName>.FQDN Unable to configure the RD Session Host server <ServerName>.FQDN. Invalid operation

Solution

As per the following KB article:

You cannot create a session collection and an error occurs in Windows Server 2012
https://support.microsoft.com/en-us/help/3014614/you-cannot-create-a-session-collection-and-an-error-occurs-in-windows

… this can be caused by GPOs configuring one of the following two settings:

Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Security

Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Licensing

In this example, the environment had a GPO that configured the RDS Licensing server:

To correct the issue, move the computer object to another OU to prevent the GPO from being applied thus unconfiguring the licensing server:

Delete the collection and recreate it:

Poor multi-monitor performance using Dell Wyse 7020 Windows 10 IoT with VMware Horizon View 6.x to 7.x

This is a follow up to a previous post I wrote about poor VMware Horizon View video, keyboard and mouse performance when adding a 3^rd monitor to the Dell Wyse 7020 Windows 10 IoT thin client:

Adding a 3rd monitor to a Dell Wyse Z90QQ10 thin client connecting to a VMware Horizon View 6.2 virtual desktop causes slow video performance with mouse movement and typing delays

http://terenceluk.blogspot.com/2018/04/adding-3rd-monitor-to-dell-wyse-z90qq10.html

The poor performance issue began affecting our Microsoft Windows 2016 RDS services, which escalated the priority so I was finally able to take 2 days to troubleshoot the problem. I had also opened up a ticket with VMware and Dell prior to beginning troubleshooting the issue myself and the VMware EUC engineering said this was likely a Dell Wyse issue since it does not happen on a full thick PC while Dell never got back to me at all after a ticket was opened. I’ve never been impressed with Dell support for the Wyse devices but figured I’d give them a try but they have yet to call me days after the ticket was opened and I don’t have much confidence that I would receive a call back soon.

Before I begin, the following are the environment details:

Hardware

Thin Client: Dell Wyse Z90QQ10 Thin Client

Operation System: Windows 10 Enterprise 2015 LTSB

Monitors: 3 x Dell P2414Hb (1920 x 1080) and 3 x Dell U2417H (1920 x 1080)

View Horizon Client: VMware Horizon View Client 4.8.0 build-8547331

Troubleshooting

The first item I looked at the start of the troubleshooting was the PCoIP Client Session Variables configuration provided by VMware to apply to the Horizon View Client and in particular the Configure PCoIP client image cache size policy and Configure the PCoIP session bandwidth floor settings:

Both of these settings did not help with the problem so I moved on to upgrading the VDI’s virtual machine version (no improvement), increasing resources (no improvement) then reviewing the drivers available for the two video cards in the thin client but noticed that there was an 2 month newer update for the AMD Radeon HD 8330E but no update for the AMD Radeon E6460:

Realizing I’m not going to have much luck with the drivers or the Horizon View Client application tweaking, I started reviewing the display output connections of the thin client:

After trying different combinations to connect the 3 monitors, I concluded that the degrade in performance happens when both of the video cards are used. Independently using the video cards to display 2 monitors at a time was fine but using 1 output connector from each video card for 2 monitors degraded performance immediately. Having ran out of ideas, I decided to review the specifications to see if I had missed something:

https://www.dell.com/en-us/work/shop/wyse-endpoints-and-software/wyse-7000-series-thin-clients-high-performance-virtual-desktop/spd/wyse-z-class

What I immediately noticed was that the thin client actually supported 6 displays as indicated under the Display specifications:

Wyse 7020
DisplayPort: 2560 x 1600 @32bpp
Dual DisplayPort: 2560 x 1600 @32bpp
DVI-I: 1920 x 1200 @32bpp
Dual Display: 1920 x 1200 @32bpp
Four Displays (DVI & DisplayPort): (1) 1920x1200@32bpp, (3) 2560x1600 @32bpp
Four Displays (DisplayPort daisy-chain): 3840x2160@32bpp
Six Displays (DisplayPort daisy-chain): 2560x1600@32bpp

I have to admit that I don’t really follow the advancements of monitor outputs so I was unfamiliar with DisplayPort daisy-chain but taking it literally made me realize that I could potentially connect more than 2 monitors to the same video card. The Dell P2414Hb (1920 x 1080)

monitors we had in the office did not support daisy chaining so we ended up purchasing 3 x Dell U2417H (1920 x 1080) to test this capability and I immediately noticed that daisy chaining 3 monitors to the AMD Radeon HD 8330E video card provided optimal performance in Horizon View. I then went and tried to the do the same with the AMD Radeon E6460 and received an error indicating it only supported 2 monitors via a single daisy chained display port.

It was a bit absurd to find that this was the problem and I could not find any information about this anywhere on the internet so I hope this post would help anyone who may encounter the same problem. Below is a photo of the Dell Wyse 7020 back panel with the video cards labeled and a table of the test results:

AMD Radeon E6460

Port	Connection	Monitors	Resolution	Performance Results
Display Port	Daisy-Chain DP	2	1920 x 1080	Poor with mouse delays
Display Port	Daisy-Chain DP	3	1920 x 1080	Unsupported as only a maximum of 2 monitors is supported
DVI and Display Port	Direct connection	2 (1 on DP and 1 on DVI)	1920 x 1080	Good as expected

AMD Radeon HD 8330E

Port	Connection	Monitors	Resolution	Performance Results
Display Port	Daisy-Chain DP	2	1920 x 1080	Good
Display Port	Daisy-Chain DP	3	1920 x 1080	Good
Display Port	Daisy-Chain DP	4	1920 x 1080	Good
Display Port	Daisy-Chain DP	4 (1 on DP and 3 on other DP)	1920 x 1080	Good

**Any combination of mixing the AMD Radeon E6460 and HD 8330E resulted in poor performance and would generated the following low on memory message for the VMware Remote MKS service:

Close programs to prevent information loss

Your computer is low on memory. Save your files and close these programs:

VMware Remote MKS