Attempting to add the CAS role to an Exchange 2010 mailbox server with SP3 Rollup 13 throws the error: “The installed product does not match the installation source(s)…”

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

“Allow display scaling” option within VMware Horizon Client does not scale virtual desktop on Windows 10

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:

Setting up vCheck PowerShell health check script in Task Scheduler to automatically run daily

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.

Attempting to access an account’s Outlook Web App (OWA) throws the error message: “something went wrong Your account has been disabled.”

Problem

You have an account that was recently disabled in Active Directory and need to access it via OWA so you proceed to enable in Active Directory Users and Computers then log on via the webmail webpage but receive the following error:

:-(
something went wrong
Your account has been disabled.
X-ClientId: 19F7108344BF45D0BD829021E1B17519
X-OWA-Error: Microsoft.Exchange.Data.Storage.AccountDisabledException
X-OWA-Version: 15.0.1178.4
X-FEServer: EX04
X-BEServer: EX04
Date: 13/03/2017 14:13:58
Fewer details...

Solution

I’ve come across this quite a few times when clients have asked me to troubleshoot this and as obvious as the solution is, it is also very easy to overlook.  What I’ve noticed over the past year is that the majority of the time administrators run into this issue and are absolutely sure that the user’s AD account is enabled is when the following configuration in Exchange is disabled:

Email Connectivity

Outlook Web App: Disabled

Some organizations may disable this for various reasons.  Hope this helps anyone who may encounter this issue.

Attempting to export a mailbox to PST from the Exchange Server 2013 ECP throws the error: “The call to ‘net.tcp://exchangeServer.domain.com (15.0.1178.0caps:1FFF)’ timed out. Error details: This request operation sent to ‘net.tcp://exchangeServer.domain.com/Microsoft.Exchange.MicrosoftReplicationService…”

Problem

You attempt to export a user’s mailbox to PST via the Exchange 2013 ECP console but receive the following error:

The call to

‘net.tcp://exchangeServer.domain.com (15.0.1178.0caps:1FFF)’ timed out. Error details: This request operation sent to ‘net.tcp://exchangeServer.domain.com/Microsoft.Exchange.MicrosoftReplicationService did not receive a reply within the configured timeout (00:01:00). The time allotted to this operation may have been a portion of a longer timeout. This may be because the service is still processing the operation or becase the service was unable to send a reply message. Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client.

Solution

I’ve had clients call me about this error message in the past and most of them would have Google-d the error and come across the following KB:

Mailbox import or export fails in Exchange Server 2010
https://support.microsoft.com/en-us/help/2675690/mailbox-import-or-export-fails-in-exchange-server-2010

Many other forum posts also suggests the two updating the RpcClientAccessServer to point to one of the CAS servers but if an attempt was made to do that with the cmdlet:

Set-MailboxDatabase “Mailbox Database Name” -RpcClientAccessServer casServer.FQDN.com

… you’ll quickly notice that this cmdlet no longer exists and the only way to change this attribute is to use ADSIedit.

What I’ve noticed is that there have been plenty of times where the above KB does not apply so prior to going down the route of either creating a host record or adjusting the RpcClientAccessServer variable, check to ensure that the path specified in the following step for the export is correct:

Export to a .pst file

*Specify the path to export the .pst file to (example: \\server\folder\ExportFile01.pst)

The error message above could also be thrown if you specify a path that is not reachable.

Hide Favorites, Libraries, Network and redirected local drives for Citrix and RDS published RemoteApp applications

One of the most common questions I’ve been asked by clients with Microsoft RDS deployments is how to hide the Library, Favorites and redirected local drives for RDS published RemoteApp applications.  The reason for this is because many administrators have noticed that users are unable to differentiate the Desktop, Downloads and Recent Places folders listed in the Save As dialog box for RemoteApp applications, which reside on the RDS server, and ones located on their local desktop:

This isn’t the users fault so to avoid this confusion, it is best to hide these folders and the following demonstrates how to accomplish this.

Taking Ownership and Granting Permissions to Registry Keys

Note that all of the registry keys mentioned below will require taking ownership and granting permissions to the account making the changes because only the TrustedInstaller has permissions to the keys. I won’t go into the details but I’ll include screenshots of what the process looks like:

Hiding the Favorites Menu

Hiding the favorites menu as shown in the screenshot below:

… requires modifying registry keys as shown in the following:

For 32-bit applications

Navigate to the following key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID\{323CA680-C24D-4099-B94D-446DD2D7249E}\ShellFolder]

Modify the DWord Attributes to a9400100:

For 64-bit applications

Navigate to the following key:

[HKEY_CLASSES_ROOT\CLSID\{323CA680-C24D-4099-B94D-446DD2D7249E}\ShellFolder]

Modify the DWord Attributes to a9400100:

Hiding the Libraries Menu

Hiding the libraries menu as shown in the screenshot below:

… requires modifying registry keys as shown in the following:

For 32-bit applications

Navigate to the following key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID\{031E4825-7B94-4dc3-B131-E946B44C8DD5}\ShellFolder]

Modify the DWord Attributes to b090010d:

For 64-bit applications

Navigate to the following key:

[HKEY_CLASSES_ROOT\CLSID\{031E4825-7B94-4dc3-B131-E946B44C8DD5}\ShellFolder]

Modify the DWord Attributes to b090010d:

Hiding the Network Menu

Hiding the libraries menu as shown in the screenshot below:

… requires modifying registry keys as shown in the following:

For 32-bit applications

Navigate to the following key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID\{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}\ShellFolder]

Modify the DWord Attributes to b0940064:

For 64-bit applications

Navigate to the following key:

[HKEY_CLASSES_ROOT\CLSID\{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}\ShellFolder]

Modify the DWord Attributes to b0940064:

Hiding the Favorites Menu

Hiding the redirected local drives as shown in the screenshot below:

… requires applying the following group policy configuration to the server object:

Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection

Enabling Do not allow drive redirection will prevent the local redirected drives from being accessible: