Wednesday, May 17, 2017

Determining whether servers and desktops are protected from WannaCrypt / WannaCry Ransomware

It has been a busy week for most of my clients after the media published articles indicating that major organizations such as the NHS were infected by the WannaCry ransomware cryptoworm. Although a patch for this vulnerability was released as early as March 2017, some of my clients either had a portion of their servers unpatched or all of them since I’ve found it is not uncommon for companies to miss months of patching due to various business related reasons.  There has been a lot of information made available since last week but I’ve found that there are bits and pieces of important ones scattered on different sites so I wanted to write this post to include the information provided by Microsoft that I found useful when assisting clients to determine whether they are protected.

The Microsoft First Patch Released

The first available patch Microsoft made available for this vulnerability was released in March 2017 known as Security Update MS17-010, SMBv1 and information about this could be found at the following Security TechCenter bulletin:

Microsoft Security Bulletin MS17-010 - Critical

Installing the patch above would protect the cryptoworm from spreading to other servers via the legacy SMBv1 protocol and an alternative workaround would be to disable SMBv1 all together which Microsoft recommends to do if the customer was running Windows Vista or later.

Versions of Windows Affected

All version of Windows are affected by the vulnerability and the following table provides the KBs required to protect the operating system:

  • If one of updates is installed on the system, the system is protected.
  • The vulnerability has been fixed in the March 2017 Security update but the March, April and May rollup also includes all previous updates including March security update)
Operating System 2017 March (Security Only) 2016 March (Monthly Quality) 2016 April (Monthly Quality) 2017 May (Monthly Quality) Independent Update
Windows XP / Windows Server 2003 / Windows 8 NA NA NA NA


Windows Vista / Windows Server 2008 NA NA NA NA


Windows 7 / Windows Server 2008 R2





Windows Server 2012






Windows 8.1 / Windows Server 2012 R2





Windows 10 1507 / Windows 10 LTSB 2015 NA





Windows 10 1511





Windows 10 1607 / Windows 10 LTSB 2016 / Windows Server 2016 NA





Determining whether patch is installed

On a Windows Server 2012 or 2008 server, you can use the wmic qfe list command to determine whether the patch is installed.  The following are the commands to execute on a Windows Server 2012 R2 or Windows 8.1 operating system when determining whether the required patch is installed:

wmic qfe list | find "KB4012213"

wmic qfe list | find "KB4012216"

wmic qfe list | find "KB4015550"

wmic qfe list | find "KB4019215"

**Note that if the KB after the find is case sensitive so use capital letters.

If the patches are not installed then no output would be written as shown in the following screenshot:


If the patch is found then the following output will be displayed:


Patching the Operating System Vulnerability

As mentioned in the Versions of Windows Affected section, the operating system is protected as long as one of the patches is installed so it is always advisable to install the latest rollup package rather than any of the previous rollups or security patch only.  However, if downloading a 200MB+ rollup package for a Windows Server 2012 operating system:


… is a problem for whatever reason then the alternative option is to download the security patch only which is around 37MB in size:


Alternative to Patching

If downloading and installing the appropriate patch is not an option then disabling SMBv1 could be an interim solution.  The following are instructions for how to disable SMBv1:

Windows Vista and later

Windows 8.1 or Windows Server 2012 R2 and later

  • For client operating systems:
  1. Open Control Panel, click Programs, and then click Turn Windows features on or off.
  2. In the Windows Features window, clear the SMB1.0/CIFS File Sharing Support checkbox, and then click OK to close the window.
  3. Restart the system.
  • For server operating systems:
  1. Open Server Manager and then click the Manage menu and select Remove Roles and Features.
  2. In the Features window, clear the SMB1.0/CIFS File Sharing Support check box, and then click OK to close the window.
  3. Restart the system.

The following are links to articles that outline the impact of disabling SMBv1:

Tuesday, May 9, 2017

Unable to change Domain field when logging into VMware Horizon View with factor authentication enabled


You’re attempting to log into VMware Horizon View where 2 factor authentication is enabled and you use your email address or UPN as the User name:


However, you notice that you are unable to change the Domain field as the drop down box is greyed out and locked:



I am unsure as to whether this problem is specific to the SecurEnvoy 2 factor authentication software this environment had but a way to get around this is to use the format domain\username for the User name field instead:


Using this login format will unlock the domain drop down box so you can now select the domain:


Friday, May 5, 2017

Blocking a URL subdirectory and redirecting to request to the root with Citrix NetScaler

I’ve been asked several times in the past about how to block subdirectories when a website is published with a NetScaler and the most recent request was for blocking Exchange Server 2016 /ecp access.  As most Exchange administrators are aware, Exchange 2013 and 2016 allows an administrator to manage Exchange via the OWA URL but with the /ecp subdirectory.  This isn’t usually a concern when accessed via the internal corporate network but administrators get nervous when it is available via the internet.  With this recent request, I thought it would be a good idea use it as an example to demonstrate what the configuration would look like. 

**Note that this post is not endorsing the idea to block the ECP URL because I am unsure as to whether Exchange 2016 fully supports this without breaking any features for regular users as it did in Exchange 2013.  There has been several forum posts that appear to suggest it is ok but I’ll leave it up to others to decide to do it or not.

Step #1 – Create Pattern Set

Begin by creating a pattern set to match the ecp string with the following command:

add policy patset deny_ecp_url

Alternatively, you can create this via the GUI as well:

AppExpert > Pattern Sets > Add




Open the properties of the newly created Pattern Set, click on the Insert button and create the ecp pattern:



Step #2 – Create Rewrite Action

With the Pattern Set created, proceed with creating a Rewrite Action to replace /ecp with the root with the following command:

add rewrite action rw_deny_ecp_url_act replace HTTP.REQ.URL.PATH_AND_QUERY "\"/\""

Alternatively, you can create this via the GUI as well:

AppExpert > Rewrite > Actions


Type: Replace

Expression to choose target location*: HTTP.REQ.URL.PATH_AND_QUERY

Expression: "/"


Step #3 – Create Rewrite Policy

With the Rewrite Action created, proceed with creating a Rewrite Policy with the previous Rewrite Action assigned via the following command:

add rewrite policy rw_deny_ecp_url_pol "HTTP.REQ.URL.PATH.GET(1).TO_LOWER.EQUALS_ANY(\"deny_ecp_url\")" rw_deny_ecp_url_act

Alternatively, you can create this via the GUI as well:

AppExpert > Rewrite > Policies


Action: rw_deny_ecp_url_act

Undefined-Result Action*: –Global-undefined-result-action

Expression*: HTTP.REQ.URL.PATH.GET(1).TO_LOWER.EQUALS_ANY("deny_ecp_url")


Step #4 – Bind Rewrite Policy to Virtual Server

With the Rewrite Policy created, we can now bind it to the virtual server that publishes the Exchange OWA website via the following command:

bind lb vserver <virtualServerName> -policy rw_deny_ecp_url_pol -priority 100 -gotoPriorityExpression END -type REQUEST

Alternatively, you assign the policy via the GUI as well:

Traffic Management > Load Balancing > Virtual Servers


Bind a new Request Policy to the virtual server:



With the new policy binded to the virtual server, any requests to the /ecp directory should redirect the user to the regular OWA login page:


Which means they would never be able to reach this page:


Monday, May 1, 2017

Attempting to run Test-ExchangeServerHealth.ps1 throws the error: "Mail flow test: WARNING: Connecting to remote server failed with the following error message..."


You attempt to run the Test-ExchangeServerHealth.ps1 health check script found at the following Microsoft TechCenter:

Generate Health Report for an Exchange Server 2016/2013/2010 Environment

… but notice that the report generated is indicating that the mail flow test is failing for your Exchange servers:


Executing the cmdlet interactively in the console displays the following error:

------ Checking CONTOSOBMEXMB01
DNS Check: Pass
Ping Check: Pass
Uptime (hrs): 571
Server version: Exchange 2016
Roles: Mailbox
Mailbox Server Role Services: Pass
Client Access Server Role Services: Pass
Unified Messaging Server Role Services: Pass
Hub Transport Server Role Services: Pass
Total Queue: 0
Mailbox databases mounted: Pass
MAPI connectivity: Success
Mail flow test: WARNING: Connecting to remote server failed with the following error message
: WinRM cannot
process the request. The following error occurred while using Kerberos authentication: Cannot find the computer Verify that the computer exists on the network and that the name provided is spelled
correctly. For more information, see the about_Remote_Troubleshooting Help topic.
WARNING: Cannot validate argument on parameter 'Session'. The argument is null or empty. Provide an argument that is
not null or empty, and then try the command again.
Remove-PSSession : Cannot validate argument on parameter 'Id'. The argument is null. Provide a valid value for the
argument, and then try running the command again.
At C:\PS-Scripts\Test-ExchangeServerHealth.ps1:450 char:22
+     Remove-PSSession $session.Id
+                      ~~~~~~~~~~~
   + CategoryInfo          : InvalidData: (:) [Remove-PSSession], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationError,Microsoft.PowerShell.Commands.RemovePSSessionCommand



Manually executing the Test-Mailflow cmdlet on the servers complete without any issues.


One of the reasons why this error would be thrown is if you have entered the FQDN that represents your load balanced CAS servers for the PowerShell (Default Web Site) Internal URL field:


Changing the field as shown in the screenshot above causes the script to connect to the virtual name to execute PowerShell cmdlets, which is what causes the following error which complains that the the virtual name does not map to a computer account in Active Directory to be thrown:

Mail flow test: WARNING: Connecting to remote server failed with the following error message
: WinRM cannot
process the request. The following error occurred while using Kerberos authentication: Cannot find the computer Verify that the computer exists on the network and that the name provided is spelled

To correct the issue, change the Internal URL field back to the internal FQDN name of the server:


Friday, April 28, 2017

Unable to search for users outside of the domain the Citrix XenDesktop 7.11 Citrix Director server is joined to


You’ve noticed that your Citrix XenDesktop 7.11 environment with Citrix Director installed:



… is unable to look up users from another domain that there is a forest trust configured to:



Navigating into the Sessions tab displays these foreign domain accounts:


… and navigating into the Filters menu displays these accounts:


Clicking on the listed accounts from the foreign domain opens the properties of the account:


However, you receive the following messages:

Cannot retrieve machines.

No details are available.


Clicking on the user icon on the top left corner displays the following message:

User details cannot be retrieved from Active Directory.

Cannot find the user. View Director server event logs for further information (Refer Citrix KB article CTX130320).



A default install of Citrix Directory requires additional configuration to allow it to look up accounts in other domains that have forest trusts configured and the following demonstrates the process.

Begin by launching the Internet Information Services (IIS) Manager on the Citrix Director server then navigate to: Sites > Default Web Site > Director and open up the Application Settings configuration:


Select the Connector.ActiveDirectory.Domains line item and then click Edit:


In the Value field:


Append the additional domain that there is a forest trust configured and contains accounts you would like Citrix Director to lookup:


Note the additional domain at the end of the string (user);(server),:


A restart of IIS is not required so proceed to log back into the Citrix Director console:


You should now notice that the problematic accounts from the foreign domain will now display information:




Searching for these accounts will now work as expected:


Monday, April 24, 2017

Attempting to install the Citrix XenDesktop 7.11 VDA agent fails with: Installation of MSI File ‘IcaWS_x64.msi’ failed with code ‘InstallPackageOpenFailed’ (1619).”


You’re attempting to the Citrix XenDesktop 7.11 VDA agent on a Windows 7 desktop but the installation immediately fails with the following error message:

Installation of MSI File ‘IcaWS_x64.msi’ failed with code ‘InstallPackageOpenFailed’ (1619).


Clicking on the View Details link displays the following:

Error Id: XDMI:B70F91CB


Citrix.MetaInstaller.MetaInstallerException Installation of MSI File 'IcaWS_x64.msi' failed with code 'InstallPackageOpenFailed' (1619).

at Citrix.MetaInstaller.Msi.InstallProduct(InstallationContext context, String msiPath, String parameters)

at Citrix.MetaInstaller.MsiComponent.Install(InstallationContext context)

at Citrix.MetaInstaller.InstallationManager.InstallComponent(IInstallableComponent component, InstallationContext installContext)


Reviewing the installation logs has the following information at the end of the log:

16:32:18.9638 $ERR$ : XenDesktopSetup:MSI file C:\Windows\TEMP\Ctx-AD3A7E10-3F36-4A0C-BE5F-B348771B0200\Extract\Image-Full\x64\Virtual Desktop Components\WS\IcaWS_x64.msi not found on media.

16:32:18.9658 : XenDesktopSetup:About to install MSI File 'C:\Windows\TEMP\Ctx-AD3A7E10-3F36-4A0C-BE5F-B348771B0200\Extract\Image-Full\x64\Virtual Desktop Components\WS\IcaWS_x64.msi' using params 'INSTALLDIR="C:\Program Files\Citrix" ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="1" MSIRMSHUTDOWN="2"' log file is 'C:\Users\tluk\AppData\Local\Temp\Citrix\XenDesktop Installer\MSI Log Files\IcaWS_x641895175363.txt'

16:32:18.9658 : XenDesktopSetup:Starting synchronous process 'msiexec' with args '/i "C:\Windows\TEMP\Ctx-AD3A7E10-3F36-4A0C-BE5F-B348771B0200\Extract\Image-Full\x64\Virtual Desktop Components\WS\IcaWS_x64.msi" /lv "C:\Users\tluk\AppData\Local\Temp\Citrix\XenDesktop Installer\MSI Log Files\IcaWS_x641895175363.txt" /quiet INSTALLDIR="C:\Program Files\Citrix" ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="1" MSIRMSHUTDOWN="2" CLOUD=False REBOOT=ReallySuppress'

16:32:19.0158 : XenDesktopSetup:Process output: T h i s i n s t a l l a t i o n p a c k a g e c o u l d n o t b e o p e n e d . V e r i f y t h a t t h e p a c k a g e e x i s t s a n d t h a t y o u c a n a c c e s s i t , o r c o n t a c t t h e a p p l i c a t i o n v e n d o r t o v e r i f y t h a t t h i s i s a v a l i d W i n d o w s I n s t a l l e r p a c k a g e .

16:32:19.0168 : XenDesktopSetup:Process output:

16:32:19.0178 : XenDesktopSetup:Process output:

16:32:19.0188 : XenDesktopSetup:Process completed with error code 1619

16:32:19.0188 $ERR$ : XenDesktopSetup:Installation of MSI File 'IcaWS_x64.msi' failed with code 'InstallPackageOpenFailed' (1619).

16:32:19.0198 $ERR$ : XenDesktopSetup:InstallComponent: Failed to install component 'ICA for Workstation Services'. Installation of MSI File 'IcaWS_x64.msi' failed with code 'InstallPackageOpenFailed' (1619).

16:32:19.0198 $ERR$ : XenDesktopSetup:Recording installation failure. Installation of MSI File 'IcaWS_x64.msi' failed with code 'InstallPackageOpenFailed' (1619).

16:32:19.0208 PROC : XenDesktopSetup:InstallComponent: Exit

16:32:19.0208 : XenDesktopSetup:Install tasks for this session have finished.

16:32:19.0208 : XenDesktopSetup:Installation failed

16:32:19.0638 : XenDesktopSetup:InstallationManager returned Failed



This error actually threw me off for quite a few hours because the client called me to troubleshoot the issue over the phone which meant I wasn’t able to run the install myself.  After downloading different versions of the VDA agent, disjoining the template from the domain to eliminate GPO related issues, reviewing Windows hotfixes and patching the Windows 7 desktop to the latest version, what ended up being the issue was that the client used the server version of the the VDA agent:



The installation completed as soon as the client downloaded the correct VDA agent: