One of the scripts I've used quite a lot over the past few years is the community driven vCheck PowerShell HTML framework script:

http://www.virtu-al.net/vcheck-pluginsheaders/vcheck/

Most if not all of my clients have this script setup to run daily so that reports could be sent to them to either identify potential issues before the start of the day or lingering issues that they may not have been aware about. I highly recommend implementing this in all vSphere environments at some capacity to gain insight into the hosts and vCenter.

One of the most common issues clients tend to face is how to set this script to run automatically in a Windows Task Scheduler so this post serves to demonstrate the way I usually set it up.

Begin by launching Task Scheduler on a server you would like to select to execute this task:

Select the folder you would like to create the task in, then right click in the window and select Create New Task...:

Enter a name for the task, select Run whether user is logged on or not and enable Run with highest privileges in the General tab:

Navigate to the Triggers tab and then click on the New... button:

Configure the trigger with the frequency you'd like the task to run:

Navigate to the Actions tab and then click on the New... button:

Fill in the following fields:

Action: Start a program

Program/script: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Add arguments (optional): -ExecutionPolicy Unrestricted -executionpolicy Bypass -file c:\vCheck-vSphere-master\vCheck.ps1

Note the following:

-ExecutionPolicy Unrestricted< this is to allow the script to run even though it is unsigned
-executionpolicy Bypass< this will bypass the prompts that are presented when the modules execute

Navigate to the Conditions tab and uncheck all the options:

Click on the OK button to save the configuration and enter the credentials of an account that you will be using as a service to run this task as well as connecting to vCenter.

Problem

You’ve recently set up a Windows 10 laptop with 3K or 10K resolution with the VMware Horizon Client version 4.3.0 build-4710077:

… and ensured that the Allow display scaling was enabled:

… but you noticed that the DPI settings for the virtual desktop you connect to is not sized properly and therefore have the icons and text so small that it is unusable.

Attempting to use registry keys to force DPI scaling that was applicable to the earlier version of the View Client as described here does not correct the issue either:

http://terenceluk.blogspot.co.uk/2016/06/workaround-for-addressing-display-size.html

Solution

I’ve only encountered the issue described above once and found that the only way I was able to correct it was to uninstall the VMware Horizon View Agent, then the VMware Tools and then reinstall the VMware Tools and VMware Horizon View Agent to correct the issue:

Note that the environment I encountered this issue in was using VMware Horizon View Agent version 6.1.1.2769635:

VMware-viewagent-x86_64-6.1.1-2769635.exe

… and View Horizon Connection server version 6.2.3-4126346:

Problem

You need to install the CAS (Client Access Server) role onto an existing Exchange 2010 server with SP3 Rollup 13 that has the mailbox role already installed.  You’ve downloaded Exchange 2010 SP3, unpacked it, run setup.exe:

… select the CAS role to be installed but receive the following message during the install:

Update Rollup 13 for Exchange Server 2010 Service Pack 3

The installed product does not match the installation source(s). Until a matching source is provided or the installed product and source are synchronized, this action can not be performed.

Solution

The solution to this is actually quite simple and that is to click on the Browse button and manually select the exchangeserver.msi file in the unpacked Exchange 2010 SP3 folder:

Manually selecting this file will allow the install to proceed:

It is important to reapply the rollup update to the server once the install is complete.  In the example above, the version listed via the following cmdlet is SP3 RU13:

Get-Command ExSetup | ForEach {$_.FileVersionInfo}

Exchange Server Updates: build numbers and release dates
https://technet.microsoft.com/en-us/library/hh135098(v=exchg.150).aspx

Problem

You’ve used the following TechNet article to allow Exchange 2016 mailboxes to access your Exchange 2010 public folders during a migration:

Configure legacy public folders where user mailboxes are on Exchange 2013 servers
https://technet.microsoft.com/en-us/library/dn690134(v=exchg.150).aspx

You’ve confirmed that the configuration in the article has been completed but receive the following message when you attempt to expand an Exchange 2010 hosted public folder with Outlook 2013:

Cannot expand the folder. Microsoft Exchange is not available. Either there are network problems or the Exchange server is down for maintenance.

You’ve also used the following KB article to configure Outlook Anywhere to use NTLM as the authentication method:

Users of Exchange Server 2013 or later or Exchange Online can't open public folders or shared mailboxes on a legacy Exchange server
https://support.microsoft.com/en-us/help/2834139/users-of-exchange-server-2013-or-later-or-exchange-online-can-t-open-public-folders-or-shared-mailboxes-on-a-legacy-exchange-server

Solution

One of the reasons why the error message above would be displayed is if one or more of the RPC directory on the Exchange CAS servers have Negotiate listed above NTLM as an EnabledProvider.  To check, log onto each CAS server and launch the Internet Information Services (IIS) Manager, expand the Default Web Site, select the RPC directory and click on Authentication:

Select Windows Authentication and click on the Providers… link under Actions:

Notice that Negotiate could be listed at the top of the list in the Enabled Providers section even if you’ve configured NTLM as the ClientAuthenticationMethod or IISAuthenticationMethods:

Change this by selecting NTLM in the list and clicking on the Move Up button:

Perform an IISReset and this would correct the issue allowing you to expand the public folder hosted on an Exchange 2010 server in an Outlook 2013 client.

Problem

You’ve used the following TechNet article to allow Exchange 2016 mailboxes to access your Exchange 2010 public folders during a migration:

Configure legacy public folders where user mailboxes are on Exchange 2013 servers
https://technet.microsoft.com/en-us/library/dn690134(v=exchg.150).aspx

You’ve confirmed that Outlook 2010 and 2013 clients are able to expand the Exchange 2010 hosted public folders but the following error messages are displayed when attempting to expand with Outlook 2016:

Cannot expand the folder. The set of folders cannot be opened. Network problems are preventing connection to Microsoft Exchange.

The set of folders cannot be opened. Network problems are preventing connection to Microsoft Exchange.

***Note that it is not accurate to test via Exchange 2016 OWA because it would not be able to proxy requests over to Exchange 2010 so you are guaranteed to receive the following error if you try opening the public folders:

Can’t complete your request

No public folders are available. Check that a public folders deployment exists in this Exchange organization. If so, please try again later

Solution

This issue had me stumped for half a day because attempting to search this error message with the combintation of Exchange 2010, 2016 and Outlook 2016 returns many other KBs and forum posts that are unrelated to the issue.  After a bit more searching with different strings, I managed to find the solution in the following KB:

Outlook can't access public folders hosted on legacy Exchange servers
https://support.microsoft.com/en-us/help/3177600/outlook-can-t-access-public-folders-hosted-on-legacy-exchange-servers

Executing the following cmdlet on an Exchange 2016 hosted mailbox displays the DefaultPublicFolderMailbox field as being blank:

Get-Mailbox tluk | FL *public*

Use the following cmdlet as described in the KB to define the proxy mailbox that was created for Exchange 2016 users to access the Exchange 2010 public folders:

Set-Mailbox <User> -DefaultPublicFolderMailbox <ProxyMailbox>

Execute the following cmdlet to assign the public folder database for the user's mailbox database:

Set-MailboxDatabase (Get-Mailbox <User>).Database -PublicFolderDatabase (Get-MailboxDatabase (Get- Mailbox <ProxyMailbox>).Database).PublicFolderDatabase

Complete the above steps by executing the following cmdlet to restart the Microsoft Exchange Rpc Client Access service on the server that's running Exchange Server that hosts the public folders:

Restart-Service MSExchangeRPC

With the above completed, the Outlook 2016 client should now be able to expand the public folder structure:

Problem

You’re attempting to move an archive mailbox of a user from one mailbox database to another in Exchange 2016 but notice that Status in the EAC appears to be stuck in Syncing for a long time and does not complete:

The statistics of the migration request indicates data is either being moved very slowly or not moving at all because the Last synced time can be hours before the current time:

Statistics

Created by: a-tluk@domain.com

Create time: 4/10/2017 8:51:52 AM

Start time: 4/10/2017 8:51:52 AM

Initial sync time:

Initial sync duration:

Last synced time: 4/10/2017 10:24:29 AM

Opening the details of the migration request via the View details link shows the migration rate listed as 0 bytes

mjoell@domain.com

Status: Syncing

mjoell@domain.com

Skipped item details

Data migrated: 1.376 GB ‎(1,477,282,535 bytes)‎

Migration rate: 0 B ‎(0 bytes)‎

Error:

Report: mjoell@domain.com Download the report for this user

Last successful sync date: 4/10/2017 10:41:38 AM

Status:

Queued duration: 00:00:09.5392418

In-progress duration: 00:12:19.0602398

Synced duration: 00:00:00

Stalled duration: 01:32:35.5891119

Opening the properties of the move request and navigating to the migration reports section does not show any reports available:

Solution

There could be various reasons why a migration request could appear to be forever syncing and not completing but for the example above, the reason why the move is taking a long time can be found by using the following cmdlets to obtain more information.

Begin by verifying that the cmdlet is displaying the same results as the EAC GUI:

Get-MigrationBatch -identity "Move Marchelle's archive to EMAR02" -includereport

Continue by listing the detailed statistics of the move requests in the queue:

Get-MoveRequest | Get-MoveRequestStatistics

Notice that the StatusDetail column display StalledDueToTarget_Mdb… in the screenshot above.

To view the full description of the StatusDetail column, execute the following:

Get-MoveRequestStatistics -Identity "Marchelle Joell" | Format-Wide -Property StatusDetail

Notice that the StatusDetail is shown as StalledDueToTarget_MdbReplication.

Reviewing the following TechNet article:

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

Exchange 2016 Migration Status
https://social.technet.microsoft.com/wiki/contents/articles/36516.exchange-2016-migration-status.aspx

Explains the Stalledduetotarget_mdbreplication status as:

Stalledduetotarget_mdbreplication:
This value is also returned from Data Guarantee API on checking the replication health of the target database copies if they are a member of DAG and have database copies.
We might get this message if the MRS service is waiting to get this information from the target server about the replication status of the database copies.

So, in this case, the passive copy must be:
1) Healthy.
2) Must have a replay queue with 10 mins of replay lag time.
3) Have a copy queue length less than 10 logs.
4) Have an average copy queue length less than 10 logs.

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

In the example above, the reason why the migration is taking so long is because there is a delay with the replication between the servers in the DAG hosting the target mailbox database.  This can be determined by reviewing the passive copy’s Copy queue length:

I’ve noticed that the environment I was working in would have this value jump between 0 to 50, which basically indicates there’s a slight replication delay between the two servers in the DAG.  The archive mailbox move is indeed being moved but at a very slow pace.  This can be verified by executing:

Get-MoveRequest | Get-MoveRequestStatistics

… or:

Get-MoveRequestStatistics -Identity "Marchelle Joell"

… and confirming that the value for PercentComplete is indeed increasing:

The only options you’ll have if the above is your scenario is to either correct the replication delay or simply wait for a longer duration to move the archive mailbox due to the problem.

Problem

You attempt to reassign an Exchange UM extension that was previously assigned to a user who you have disabled for UM but receive the following error:

error

Extension xxxx is already assigned to another user on dial plan UMDialPlan or on an equivalent dial plan.

You try using the Get-UMMailbox cmdlet to list all of the users and review which one currently has the extension assigned:

Get-UMMailbox | Format-Table -Wrap -AutoSize

… but do not see the extension listed in Extensions column:

You review the attributes for the user who was previously assigned the extension but do not see any reference of it in the Exchange attributes:

The Lync / Skype for Business msRTCSIP-Line attribute is confirmed not to exist for the user either:

Solution

One of the possible causes of this issue is if the user who previously had this extension assigned still has the EUM email address with the extension as the value:

To correct this issue, remove the email address from the previous user.

I’ve recently had to work with a Riverbed engineer to determine why the traffic between an Exchange server in Bermuda and London was not being accelerated by the Riverbeds between the two sites.  The following Riverbed  configuration guide was what I used in the past for Exchange 2010 environments:

Optimizing Database Availability Group (DAG) Replication for Microsoft Exchange 2010 (Testing Guide)
https://splash.riverbed.com/docs/DOC-1280

Since the the configuration guide above was last modified on December 1, 2012 and I was working with Exchange 2016, I went ahead to try and find a more updated guide but was unable to find one so I went ahead and used the instructions in the older guide.  The following are the results from my tests.

Begin by reviewing the DAG configuration with the following cmdlet:

Get-DatabaseAvailabilityGroup <dagName> | FL *network*

The following is an example of the output from the cmdlet:

Get-DatabaseAvailabilityGroup 16dag | FL *network*

NetworkCompression : InterSubnetOnly

NetworkEncryption : InterSubnetOnly

ManualDagNetworkConfiguration : False

NetworkNames : {}

The two configuration settings we’re interested in are:

• NetworkCompression
• NetworkEncrytion

More information about these two settings can be found in the following TechNet article:

Managing database availability groups
https://technet.microsoft.com/en-us/library/dd298065(v=exchg.150).aspx

In order to allow the Riverbed to accelerate the traffic, these two configuration settings need to be disabled.  As a test, I disabled NetworkEncryption first with the following cmdlet:

Set-DatabaseAvailabilityGroup 16dag -NetworkEncryption disabled

The following is the output and configuration settings of the DAG after the change:

Set-DatabaseAvailabilityGroup 16dag -NetworkEncryption disabled

Get-DatabaseAvailabilityGroup 16dag | FL *network*

NetworkCompression : InterSubnetOnly

NetworkEncryption : Disabled

ManualDagNetworkConfiguration : False

NetworkNames : {}

With NetworkEncryption disabled, the Riverbed was able to provide approximately 16% reduction of data:

After performing the above test, I proceeded to disable NetworkCompression:

Set-DatabaseAvailabilityGroup 16dag -NetworkCompression disabled

Get-DatabaseAvailabilityGroup 16dag | FL *network*

NetworkCompression : Disabled

NetworkEncryption : Disabled

ManualDagNetworkConfiguration : False

NetworkNames : {}

With both NetworkCompression and NetworkEncryption disabled, the Riverbed was able to provide approximately 61% reduction of data:

Problem

You’ve noticed that your previously operational Microsoft Forefront Identity Manager 2010 R2 throws the error the following error when you execute an Export job:

stopped-extension-dll-exception

Exchange 2010 contacts in the are either no longer updated or created in the source domain. 

You proceed into the connector’s properties under Management Agents:

Review and confirm that the service account is correct:

Reviewing the event logs show the following errors displayed in the Application logs:

Log Name: Application

Source: FIMSynchronizationService

Event ID: 6803

Level: Error

Task Category: Management Agent Run Profile

The management agent "FIM Connector" failed on run profile "Export" because the server encountered errors.

Log Name: Application

Source: FIMSynchronizationService

Event ID: 0

Level: Error

Task Category: None

The description for Event ID 0 from source FIMSynchronizationService cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

There is an error in Exch2010Extension BeginExportToCd() function.Type: System.Management.Automation.Remoting.PSRemotingTransportException

Message: Connecting to remote server failed with the following error message : The WS-Management service cannot process the request. The system load quota of 1000 requests per 2 seconds has been exceeded. Send future requests at a slower rate or raise the system quota. The next request from this user will not be approved for at least 1316187520 milliseconds. For more information, see the about_Remote_Troubleshooting Help topic.

Stack Trace: at System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult asyncResult)

at System.Management.Automation.Runspaces.RunspacePool.Open()

at System.Management.Automation.RemoteRunspace.Open()

at Exch2010Extension.Exch2010ExtensionClass.OpenConnection(String uri, PSCredential credential)

at Exch2010Extension.Exch2010ExtensionClass.BeginExportToCd(String connectTo, String domain, String server, String user, String password)

the message resource is present but the message is not found in the string/message table

You attempt to use the following TechNet article to further troubleshoot by disabling Exchange provisioning confirming that the export now completes and manually executing the included PowerShell cmdlet:

FIM Troubleshooting: stopped-dll-exception: WinRM cannot process the request: Access Denied
https://social.technet.microsoft.com/wiki/contents/articles/15091.fim-troubleshooting-stopped-dll-exception-winrm-cannot-process-the-request-access-denied.aspx

.. but you run into the error:

'contoso.com/contoso/Employees/TMRUK/GalContacts/Matthew  Evans' have been modified.
WARNING: The command completed successfully but no settings of
'contoso.com/contoso/Employees/TMRUK/GalContacts/Buu Truong' have been modified.
WARNING: The command completed successfully but no settings of
'contoso.com/contoso/Employees/TMRUK/GalContacts/Gemma Gregson' have been modified.
"DG_TMRUK_Pricing" is a MailForestContact and can't be modified.
    + CategoryInfo          : NotSpecified: (contoso...G_TMRUK_Pricing:ADObjectId) [Set-MailContact], TaskInva
   lidOperationException
    + FullyQualifiedErrorId : 69D6CABF,Microsoft.Exchange.Management.RecipientTasks.SetMailContact

"Terence Luk" is a MailForestContact and can't be modified.
    + CategoryInfo          : NotSpecified: (contoso...cts/Terence Luk:ADObjectId) [Set-MailContact], TaskInva
   lidOperationException
    + FullyQualifiedErrorId : 1DAD038F,Microsoft.Exchange.Management.RecipientTasks.SetMailContact

WARNING: The command completed successfully but no settings of
'contoso.com/contoso/Employees/TMRUK/GalContacts/Anna Ivanova' have been modified.
WARNING: The command completed successfully but no settings of
'contoso.com/contoso/Employees/TMRUK/GalContacts/DG_Operations' have been modified.
"Taro Murakami" is a MailForestContact and can't be modified.
    + CategoryInfo          : NotSpecified: (contoso...s/Taro Murakami:ADObjectId) [Set-MailContact], TaskInva
   lidOperationException
    + FullyQualifiedErrorId : 5FD06EB8,Microsoft.Exchange.Management.RecipientTasks.SetMailContact

"Sara Perdichizzi" is a MailForestContact and can't be modified.
    + CategoryInfo          : NotSpecified: (contoso...ara Perdichizzi:ADObjectId) [Set-MailContact], TaskInva
   lidOperationException
    + FullyQualifiedErrorId : E298C7BF,Microsoft.Exchange.Management.RecipientTasks.SetMailContact

"Giuseppe Ieraci" is a MailForestContact and can't be modified.
    + CategoryInfo          : NotSpecified: (contoso...Giuseppe Ieraci:ADObjectId) [Set-MailContact], TaskInva
   lidOperationException
    + FullyQualifiedErrorId : 28CFBAA8,Microsoft.Exchange.Management.RecipientTasks.SetMailContact

"Ken Tarbet" is a MailForestContact and can't be modified.
    + CategoryInfo          : NotSpecified: (contoso...acts/Ken Tarbet:ADObjectId) [Set-MailContact], TaskInva
   lidOperationException
+ FullyQualifiedErrorId : 2EE5477,Microsoft.Exchange.Management.RecipientTasks.SetMailContact

The AD and Exchange contacts also does not get created.

Other TechNet articles such as the following does not correct the issue:

FIM Troubleshooting: stopped-dll-exception troubleshooter document
https://social.technet.microsoft.com/wiki/contents/articles/8759.fim-troubleshooting-stopped-dll-exception-troubleshooter-document.aspx

Solution

After going through numerous TechNet articles and posts without making any progress, I went ahead and tried changing the Exchange 2010 RPS URI to another Exchange 2010 HT/CAS server:

… and the export job immediately worked.  This lead me to change my search query, which was when I found the following blog post that resolved the issue:

http://www.vspbreda.nl/nl/exchange/exchange-2010/exchange-2010-load-quota-1000-requests-exceeded/

What I needed to do was simply perform an iisreset on the problematic server to prevent the export job from erroring out:

Problem

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

Exception:

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

Solution

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:

VDAServerSetup_7.11

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

VDAWorkstationSetup_7.11

Problem

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

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:

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

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:

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

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:

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:

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

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:

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:

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

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:

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

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)

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:

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

… 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

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

• See Microsoft Knowledge Base Article 2696547

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:

• https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/
• https://blogs.technet.microsoft.com/josebda/2015/04/21/the-deprecation-of-smb1-you-should-be-planning-to-get-rid-of-this-old-smb-dialect/

Problem

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

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

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

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

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.

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:

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

One of the scripts I've used a lot over the past few years is the Test-ExchangeServerHealth.ps1 PowerShell health check script written by Paul Cunningham.  The red, yellow and green colour coded report generated by this script allows me to easily review the status of critical Exchange services on devices with small viewing space such as a smartphone.  If you are unfamiliar with this script, further details about the script can be found in the following links:

Test-ExchangeServerHealth.ps1 – PowerShell Script to Generate a Health Check Report for Exchange Server 2016/2013/2010
https://practical365.com/exchange-server/powershell-script-exchange-server-health-check-report/

Generate Health Report for an Exchange Server 2016/2013/2010 Environment
https://gallery.technet.microsoft.com/office/Generate-Health-Report-for-19f5fe5f

This script could be scheduled to automatically run via the Task Scheduler and this post serves to provide the configuration for the action which sometimes can be difficult to find.  Note that I won’t go into the details of creating the scheduled task as that could be found in one of my previous posts here:

Setting up vCheck PowerShell health check script in Task Scheduler to automatically run daily
http://terenceluk.blogspot.com/2017/03/setting-up-vcheck-powershell-health.html

The following is the syntax required to configure the action:

Program/script: powershell.exe

Add arguments (option): -command "& 'C:\PS-Scripts\Test-ExchangeServerHealth.ps1' -ReportMode -SendEmail"

Problem

You attempt to delete an Exchange 2016 mailbox database but receive the following error:

error

This mailbox database contains one or more mailboxes, mailbox plans, archive mailboxes, public folder mailboxes or arbitration mailboxes, Audit mailboxes. To get a list of all mailboxes in this database, run the command Get-Mailbox -Database <Database ID>. To get a list of all mailbox plans in this database, run the command Get-MailboxPlan. To get a list of archive mailboxes in this database, run the command Get-Mailbox -Database <Database ID> -Archive. To get a list of all public folder mailboxes in this database, run the command Get-Mailbox -Database <Database ID> -PublicFolder. To get a list of all arbitration mailboxes in this database, run the command Get-Mailbox -Database <Database ID> -Arbitration. To get a list of all Audit mailboxes in this database, run the command Get-Mailbox -Database <Database ID> -AuditLog. To disable a non-arbitration mailbox so that you can delete the mailbox database, run the command Disable-Mailbox <Mailbox ID>. To disable an archive mailbox so you can delete the mailbox database, run the command Disable-Mailbox <Mailbox ID> -Archive. To disable a public folder mailbox so that you can delete the mailbox database, run the command Disable-Mailbox <Mailbox ID> -PublicFolder. To disable a Audit mailbox so that you can delete the mailbox database, run the command Get-Mailbox -AuditLog | Disable-Mailbox. Arbitration mailboxes should be moved to another server; to do this, run the command New-MoveRequest <parameters>. If this is the last server in the organization, run the command Disable-Mailbox <Mailbox ID> -Arbitration -DisableLastArbitrationMailboxAllowed to disable the arbitration mailbox. Mailbox plans should be moved to another server; to do this, run the command Set-MailboxPlan <MailboxPlan ID> -Database <Database ID>.

Attempting to use the cmdlet Remove-MailboxDatabase throws the same error:

Executing the following cmdlets does not reveal any other types of mailboxes that reside in the database:

Get-Mailbox -Database EMDB09

Get-Mailbox -Database EMDB09 -Arbitration

Get-Mailbox -Database EMDB09 -Archive

Get-Mailbox -Database EMDB09 -AuditLog

Get-Mailbox -Database EMDB09 -PublicFolder

Solution

One of the possible causes of this is if you have a mailbox that uses this database as an archive database.  Below is an account that has the live mailbox in another database but uses this database we’re trying to remove as an archive database:

Executing the following PowerShell cmdlet would confirm this:

Get-Mailbox -Identity tluk | FL *archive*

An easier way to identify this if you don’t know which mailboxes may be using this database as an archive database is to execute the following cmdlet:

Get-Mailbox | where {$_.ArchiveDatabase -eq "EMDB09"}

If you are experiencing the issue above, simply move the archives left on this database to another database:

Problem

You have received reports from a select few users that they receive the following error message when they attempt to launch an application from the StoreFront portal:

Cannot start App “Outlook 2013”

Logging onto the Citrix Delivery Controller and reviewing the application logs show the following warnings:

Log Name: Application

Source: Citrix Broker Service

Event ID: 1102

Level: Warning

User: NETWORK SERVICE

Computer: Citrix Delivery Controller

The Citrix Broker Service failed to broker a connection for user 'DOMAIN\G0052014' to resource 'Outlook 2013'. The virtual machine 'S30015-205-CX03.ad.domain.com' rejected a request to prepare itself for a connection. This problem usually indicates that the virtual machine is engaged in an activity such as restarting, entering a suspended state, or processing a recent disconnection or logoff.

If this problem persists, please restart the virtual machine.

**Note that S30015-205-CX03 is the application server with the VDA agent

Log Name: Application

Source: Citrix Broker Service

Event ID: 1101

Level: Warning

User: NETWORK SERVICE

Computer: Citrix Delivery Controller

The Citrix Broker Service failed to broker a connection for user ‘Domain\G0052014' to resource 'Outlook 2013'. The Citrix Broker Service cannot find any available virtual machines.

Please add more virtual machines to the site. If the problem is due to existing virtual machines not becoming available, see Citrix Knowledge Base article CTX126992.

Attempting to launch another application such as notepad logs a similar warning event:

Log Name: Application

Source: Citrix Broker Service

Event ID: 1102

Level: Warning

User: NETWORK SERVICE

Computer: Citrix Delivery Controller

The Citrix Broker Service failed to broker a connection for user 'DOMAIN\G0052014' to resource 'Notepad'. The virtual machine 'S30015-205-CX03.ad.domain.com' rejected a request to prepare itself for a connection. This problem usually indicates that the virtual machine is engaged in an activity such as restarting, entering a suspended state, or processing a recent disconnection or logoff.

If this problem persists, please restart the virtual machine.

Logging onto the StoreFront server and reviewing the event logs show the entries:

Log Name: Citrix Delivery Services

Source: Citrix Store Service

Event ID: 28

Level: Warning

User: N/A

Computer: Citrix StoreFront

Failed to launch the resource 'DR.Notepad' using the Citrix XML Service at address 'https://s30015-205-cx01.ad.domain.com:443/scripts/wpnbr.dll'. The XML service returned error: 'connection-refused'.

**Note that S30015-205-cx01 is the delivery controller.

Log Name: Citrix Delivery Services

Source: Citrix Store Service

Event ID: 28

Level: Warning

User: N/A

Computer: Citrix StoreFront

A request from the Citrix server to prepare for a connection was rejected while processing the initialization of desktop group Notepad for user DOMAIN\G0052014. This message was reported from the XML Service at address https://s30015-205-cx01.ad.domain.com:443/scripts/wpnbr.dll [NFuseProtocol.TRequestAddress].

Not all of the users are affected as there are many others who are able to launch applications without any issues.

Solution

What ended up being the cause of this was that the Citrix Remote Broker Provider service was stopped on the Delivery Controller and restarting the service corrected the issue.

Problem

You have a user who is enabled for Enterprise Voice in a Lync Server 2013 environment that had no issues placing and receiving calls but recently noticed that users attempting to call them is now receiving a fast busy with the error message:

Cannot contact <userName>

Running a trace with Snooper on the server shows that a SIP/2.0 485 Ambiguous error is logged during the failed call:

TL_INFO(TF_PROTOCOL) [0]2160.20F4::06/06/2017-13:36:28.621.00008520 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[4058195155] $$begin_recordTrace-Correlation-Id: 4058195155
Instance-Id: 495426
Direction: outgoing;source="local"
Peer: CONTles03.CONT.com:58390
Message-Type: response
Start-Line: SIP/2.0 485 Ambiguous
From: <sip:tluk@contoso.com>;tag=244c2c0e70;epid=98eec5ee8d
To: <sip:+44xxxxx9578@contoso.com;user=phone>;tag=872B83A7584D65996E00DA963EC419D0
Call-ID: 1c27d3fe51e6418892fe4e79cb4f564b
CSeq: 1 INVITE
Via: SIP/2.0/TLS 192.168.131.2:58390;branch=z9hG4bK323649EF.04A161E3BE17588C;branched=FALSE;ms-received-port=58390;ms-received-cid=36CFC00
Via: SIP/2.0/TLS 172.16.1.121:50637;received=216.249.42.188;ms-received-port=50637;ms-received-cid=AE8300
Content-Length: 0
ms-diagnostics: 4199;reason="Multiple users associated with the target phone number";HRESULT="0x8004C3CD";processing-cluster="CONTlse03.CONT.com";processing-frontend="CONTLSE03.CONT.COM";source="CONTLSE03.CONT.COM"
$$end_record

Solution

One of the reasons why this user would experience issues with inbound calls is if someone had recently created an account that uses the same number but with a different extension for their Line URI field.  To troubleshoot this, launch the Lync Server 2013 Control Panel and search for users with the problematic user’s number but without the extension.

For this example, the problematic user’s Line URI field is configured as such:

tel:+44xxxxxx9578;ext=9578

With the above information, add a Line URI filter configured to contain the string:

tel:+44xxxxxx9578

As shown in the screenshot above, two users have been returned.

Open the properties of the user accounts to compare the Line URI field and in the case of this example, the problem is caused by a typo in the Line URI field where:

User A: tel:+44xxxxxx9578;ext=9578

User B: tel:+44xxxxxx9578;ext=9579

User B’s Line URI was meant to be:

User A: tel:+44xxxxxx9579;ext=9578

… and because of the slight typo shown above, the Control Panel allowed the configuration to be made since the strings were unique but a call could not be routed properly because there were 2 matches.