Thursday, May 25, 2017

User attempting to access Microsoft Dynamics CRM Server 2016 receives a: “Server Error 404 - File or directory not found.” web page

Problem

You’ve recently deployed a new Microsoft Dynamics CRM Server 2016 environment:

image

… and had accounts created for the users in the organization but noticed that some users receive the following web page when attempting to access the portal via IFD and ADFS:

Server Error

404 - File or directory not found.

The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.

image

You’ve confirmed that the user is enabled in CRM:

image

You proceed to navigate to the ADFS sign page that the CRM deployment uses and sign in as the user:

image

What you quickly notice is that the following error is displayed when you sign in with the user’s credentials:

No Microsoft Dynamics CRM user exists with the specified domain name and user ID

A Microsoft Dynamics CRM user record does not exist with the specified domain name and user ID.

image

Solution

Note that I am by no means an expert with CRM but I made a “best effort” attempt at troubleshooting the issue and was able to identify the following:

  1. The user account appears to be valid in the CRM portal because it pulled the correct information for the user
  2. Although the account is displayed in the CRM portal, it appears it is not tied to a CRM record, which appears to suggest the Active Directory identity does not map to a CRM identity
  3. Disabling and re-enabling the account does not correct the issue

What ended up enabling me to correct this problem was to:

  1. Create a new temporary Active Directory user, which would not be created in the CRM directory (I could not use an existing user because they would already be created in CRM)
  2. Quickly change the User Name field of the user experiencing the issue to the temporary user account
  3. Save and Close the account properties
  4. Change the User Name field of the user experiencing the issue from the temporary user account back to their identity
  5. Save and Close the account properties

This appears to force CRM to map the user’s Active Directory identity to a CRM user record.  Below are a few screenshots that show the process:

image

image

Once the above has been saved and closed, reopen the account properties and change the User Name back to the correct identity.

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
https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

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

KB4012598

Windows Vista / Windows Server 2008 NA NA NA NA

KB4012598

Windows 7 / Windows Server 2008 R2

KB4012212

KB4012215

KB4015549

KB4019264

NA
Windows Server 2012

KB4012214

KB4012217

KB4015551

KB4019216

NA

Windows 8.1 / Windows Server 2012 R2

KB4012213

KB4012216

KB4015550

KB4019215

NA
Windows 10 1507 / Windows 10 LTSB 2015 NA

KB4012606

KB4015221

KB4019474

NA

Windows 10 1511

NA

KB4013198

KB4015219

KB4019473

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

KB4015438

KB4015217

KB4019472

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:

image

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

image

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:

https://www.catalog.update.microsoft.com/Search.aspx?q=KB4019215

image

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

https://www.catalog.update.microsoft.com/Search.aspx?q=KB4012213

image

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

Problem

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:

image

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

image

Solution

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:

image

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

image

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

image

image

image

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

image

image

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

image

Type: Replace

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

Expression: "/"

image

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

image

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

image

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

image

Bind a new Request Policy to the virtual server:

image

image

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:

image

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

image

Monday, May 1, 2017

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

Problem

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
https://gallery.technet.microsoft.com/office/Generate-Health-Report-for-19f5fe5f

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

image

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 webmail.contoso.com failed with the following error message
: WinRM cannot
process the request. The following error occurred while using Kerberos authentication: Cannot find the computer
webmail.contoso.com. 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

Fail

image

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

Solution

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:

image

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 webmail.contoso.com failed with the following error message
: WinRM cannot
process the request. The following error occurred while using Kerberos authentication: Cannot find the computer
webmail.contoso.com. Verify that the computer exists on the network and that the name provided is spelled
correctly.

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

image

Friday, April 28, 2017

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

Problem

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

image

image

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

image

imageimage

Navigating into the Sessions tab displays these foreign domain accounts:

image

… and navigating into the Filters menu displays these accounts:

image

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

image

However, you receive the following messages:

Cannot retrieve machines.

No details are available.

image

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

image

Solution

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:

image

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

image

In the Value field:

image

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

image

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

image

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

image

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

image

image

image

Searching for these accounts will now work as expected:

image