Pages

Friday, March 31, 2017

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:

image

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

image

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:

image

Manually selecting this file will allow the install to proceed:

image

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

image

Wednesday, March 22, 2017

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

image

… and ensured that the Allow display scaling was enabled:

image

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

image

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

image

… and View Horizon Connection server version 6.2.3-4126346:

image

Tuesday, March 21, 2017

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:

image

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

image

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:

image

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

image

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

image

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

image

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

image

Navigate to the Conditions tab and uncheck all the options:

image

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.

Monday, March 20, 2017

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

image

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

image

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

Wednesday, March 8, 2017

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.

image

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)

image

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

Saturday, March 4, 2017

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:

image

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:

image

image

image

image

Hiding the Favorites Menu

Hiding the favorites menu as shown in the screenshot below:

image

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

image

Modify the DWord Attributes to a9400100:

image

image

For 64-bit applications

Navigate to the following key:

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

image

Modify the DWord Attributes to a9400100:

image

image

Hiding the Libraries Menu

Hiding the libraries menu as shown in the screenshot below:

image

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

image

Modify the DWord Attributes to b090010d:

image

image

For 64-bit applications

Navigate to the following key:

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

image

Modify the DWord Attributes to b090010d:

image

image

Hiding the Network Menu

Hiding the libraries menu as shown in the screenshot below:

image

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

image

Modify the DWord Attributes to b0940064:

image

image

For 64-bit applications

Navigate to the following key:

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

image

Modify the DWord Attributes to b0940064:

image

image

Hiding the Favorites Menu

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

image

… 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

image

image

image

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

image