Pages

Thursday, September 13, 2018

Attempting to request a certificate for Skype for Business Server 2015 from an internal Microsoft Enterprise CA throws the error: "A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file. 0x800b0101 (-2146762495 CERT_E_EXPIRED)”

Problem

You’re attempting to renew the Skype for Business Server 2015 front-end server with an internal Microsoft Enterprise Certificate Authority but receive the following error:

> Request CertificateRequest-CSCertificate -New -Type Default,WebServicesInternal -CA "DC1.corp.contoso.bm\Contoso CA" -Country "BM" -State "Hamilton" -City "Hamilton" -FriendlyName "Skype for Business Server 2015 Default certificate 9/12/2018" -KeySize 2048 -PrivateKeyExportable $False -Organization "Contoso" -OU "IT" -AllSipDomain -Verbose -Report "C:\Users\administrator\AppData\Local\Temp\Request-CSCertificate-[2018_09_12][13_59_43].html"Creating new log file "C:\Users\ccs.contosoCORP\AppData\Local\Temp\Request-CSCertificate-[2018_09_12][13_59_43].xml".Create a certificate request based on Skype for Business Server configuration for this computer.Creating new log file "C:\Users\ccs.contosoCORP\AppData\Local\Temp\Request-CSCertificate-[2018_09_12][13_59_43].html". WARNING: Request-CSCertificate failed. WARNING: Detailed results can be found at "C:\Users\ccs.contosoCORP\AppData\Local\Temp\Request-CSCertificate-[2018_09_12][13_59_43].html".Command execution failed: Error Parsing Request A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file. 0x800b0101 (-2146762495 CERT_E_EXPIRED)

image

Solution

One of the reasons why this error would be thrown if you are using an internal Microsoft Enterprise CA is if the issuing Root CA’s certificate has expired. If you are able to confirm that this is the cause then simply log onto the Root CA’s Certificate Authority administration console and renew the certificate then request a new certificate:

image

Tuesday, August 21, 2018

Attempting to upgrade a HP VC FlexFabric-20/40 F8 Module firmware for a HP C7000 chassis fails with "Package Signature: Invalid"

Problem

You’re attempting to upgrade a HP VC FlexFabric-20/40 F8 Module from firmware version 4.45 2015 to 4.62 Feb 2018 (https://support.hpe.com/hpsc/swd/public/detail?sp4ts.oid=6894628&swItemId=MTX_7fae1562133f483abb29f204b7&swEnvOid=4184#):

image

You download the HP Virtual Connect Support Utility and use the update command to upgrade the firmware but the process fails with:

Error: The signature verification of specified package has failed

image

Using the packageinfo command on the vcfwall462.bin file returns the same Package Signature: Invalid output:

image

Downloading the older 4.50 firmware (https://support.hpe.com/hpsc/swd/public/detail?sp4ts.oid=6894628&swItemId=MTX_1f352fb404f5410d9b2ca1b56d&swEnvOid=4184#) and using the packageinfo command display a Package Signature: Valid output:

image

The Active Onboard Administrator firmware version of the chassis is at version 4.70 May 18, 2017:

image

Solution

One of the reasons why the upgrade would exhibit such a behavior is if you are using an older version of the HP Virtual Connect Support Utility. In the case of this example, the older version 1.11.1 was used and updating the utility to version 1.13.0 (https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX_7df0afcd8cef4984a78f4a888c#tab-history) corrects the issue:

image

image

Friday, July 13, 2018

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.

clip_image002

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

clip_image002[5]

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"

clip_image002[7]

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.

clip_image002[9]

Thursday, July 12, 2018

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:

imageimage

The process completes with warnings:

image

Viewing the logs displays the following warning:

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

image

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.

image

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.

image

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

This certificate has an invalid digital signature.

image

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

image

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):

image

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

image

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

image

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

image

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:

image

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

image

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:

image

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.

image

image

Tuesday, July 10, 2018

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.

image

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

imageimage

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:

image

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

image

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

image

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:

image

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:

image

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

image

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

imageimage

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.

image

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.

Sunday, July 8, 2018

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:

image

Note that this is a mail flow rule:

imageimage

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.

Thursday, July 5, 2018

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:

image

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:

image

image

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

image

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

image

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:

image

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

image

Delete the collection and recreate it:

image

image