Client Behaviour During *over in Exchange Server 2010 - Part 2

Hi,

Welcome back. In the first part of the Client Behaviour During *over in Exchange Server 2010 article ( Client behaviour During *over in Exchange Server 2010 - Part 1 ), I mentioned about the new client connection type in Exchange Server 2010. Also mentioned about the client behavior in some *over scenarios. In this article I will continue to discuss the *over scenarios.

*over Scenario 3

In this scenario the active mailbox database is mounted on the DR site mailbox server. The primary site CAS servers are also down. The user fires up Outlook however Outlook cannot connect to the Exchange servers and throws the following error message:



The client is still trying to connect to the primary site Client Access Server array. Primary site mailbox database server mailbox has the lowest Activation Preference number hence the client is trying to connect to it.  In this case a datacentre switchover is required. I am not going to discuss how to bring the DR site Exchange services online in another article. In a datacentre switchover  scenario the primary site RPC Client Access Array service is required to be re-pointed to the standby Client Access Array in the secondary datacentre. This can be achieved by a simple DNS A Host record change. Autodiscover will still point the primary site servers hence existing Outlook clients do not need any configuration.



The TTL time of the CAS Array record in DNS and also DNS cache update time on the client is important. Set a recommend TTL value of 5 mins. In this test I run ipconfig /flushdns on the client which clears the DNS table cache, as you all know.



After the DNS cache gets updated; client fires up Outlook again and this time successfully gets connected. See below:



The RPCClientAccessServer setting has not been changed either.



* over Scenario 4

One very important thing to remember!! When the mailbox database gets activated in the DR site, the users will continue try connecting to the RPC Client Access Server array from the site where the lowest activation preference value resides.

 





I can hear you asking the question whether the RPCClientAccessServer value  be changed or not? Yes it can be changed. To change the RPCClientAccessServer value of a mailbox database you either need to change the ActivationPreference number (the system will automatically update the value) or need to change it manually via EMS. See below:



And the RPCClientAccessServer value changes automatically:



However existing users will continue to use the old RPC endpoint server rather than the new enpoint server. Once again this is because the old RPC endpoint does not return the ecWrongServer response. If the old RPC endpoint becomes inaccessible the client will not be able to logon to Outlook.

*over Scenario 5

Microsoft has made significant change to this behaviour with Update Rollup 3 for Exchange Server 2010 SP2. For this scenario all Exchange Server in the infrastructure have been updated with  Update Rollup 5-v2 for Exchange Server 2010 SP2.

The client is connected to the primary site RPC Client Access Server array.



When the mailbox database gets activated in the DR site the following box pops up.



The user restarts Outlook and as you can see the RPC endpoint service on the client automatically gets updated. See below:



So what has changed? With Update Rollup 3 for Exchange Server 2010 SP2 the RPC endpoint generates ecWrongServer message and the client receives it.

RPC Client Access log

2013-01-13T14:22:37.908Z,5,1,/o=CKTESTLAB/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=username,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00,”Logon: Owner, /o=CKTESTLAB/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=username in database HQMbx1 last mounted on VTLEXCH01.cktestlab.com at 13/01/2013 14:14:24, currently InTransitSameSite; Redirected: this server is not in a preferred site for the database, suggested new server: /o=CKTESTLAB/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=outlookHQ.cktestlab.com”,RopHandler: Logon:

Very Important point here. The above is the default behaviour when the DAG’s AllowCrossSiteRpcClientAccess value is set to false. Bear in mind this is the default value.

Get-DatabaseAvailabilityGroup



Hope this article helps you to have a better understanding of the client behaviour during the *over process.

Thank you.

ecsword

Client Behaviour During *over in Exchange Server 2010 - Part 1

Hi,

In this article I will mention the client behavior during *over process in Exchange Server 2010 world.

With  Exchange Server 2010 all mailbox related MAPI connectivity started going through the RPC Client Access service on the Client Access Server role. A new property (RPCClientAccessServer) been added to the Mailbox Database. If high availability is implemented this value should be the FQDN of the CAS the Array where Microsoft refers this as the RPC Client Access Server array.

In a *over scenario within the same site, under the assumption that CAS Array has been configured, the Outlook profile’s RPC endpoint will be the FQDN of the RPC Client Access Server array. When a mailbox database failure happens onto another mailbox server in the same site the Outlook profile continues pointing to the same RPC endpoint. So in this case there is NO change to the RPC endpoint service which is the expected scenario.

The second scenario is if the failure requires a switchover to another Datacentre meaning the primary datacentre is down, in this case you would need to Restore the services in the secondary datacentre also re-point the primary RPC Client Access Server array to the secondary site’s RPC Client Access Server array in DNS. With this configuration existing Outlook clients don’t need any reconfiguration for their RPC endpoint services.

The third scenario is if the failure happens onto a mailbox server in the DR site whilst the primary datacentre servers are online. RPC Client Access Server connectivity behaviour varies depending on the Exchange Server Service Pack and the Rollup package installed. The behaviour is different pre and after Update Rollup 3 for Exchange Server 2010 SP2.

The test infrastructure is depicted in the following picture.



*over Scenario 1 

All Exchange servers have been installed with Service Pack 2 only. No Rollup updates have been installed. In this scenario a *over happens onto another mailbox server within the same site. As stated previously; in this case no action is required (under the assumption that CAS Array has been configured) as the Outlook profile will continue to use the same RPC endpoint service which is the RPC Client Access Server array.



*over Scenario 2

In this scenario *over happens onto the mailbox server that is located in the DR site. All Exchange Servers have been patched with Service Pack 2.



As seen in the above figure the database HQMbx1 has been mounted on the DR site mailbox server (VTLExDRMBX01). When a user; who has the mailbox on this mailbox database, logs on to Outlook the connection is still established to the RPC Endpoint service of the primary site. See below figure:



I can hear the question WHY? The answer is simple. Even though the Autodiscover service detected the change the client still connects to the RPC endpoint service of the primary site because the RPC endpoint servers does not return ‘ecWrongServer’ message to the client. Bear in  mind that in this scenario the primary site RPC Client Access Array servers are still accessible.

RPC Client Access Log file

2013-01-13T00:04:46.900Z,8,1,/o=CKTESTLAB/ou=Exchange Administrative Group FYDIBOHF23SPDLT)/cn=Recipients/cn=username,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,0,00:00:00.5468715,”Logon: Owner, /o=CKTESTLAB/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=username in database HQMbx1 last mounted on VTLEXDRMBX01.cktestlab.com at 13/01/2013 00:02:04, currently Mounted; LogonId: 0″

In the next part of this article ( Client behaviour During *over in Exchange Server 2010 - Part 2 ) I will continue to discuss other possible *over scenarios.

 

ecsword

Exchange Server 2013 CU3 Finalizing Setup FAILED

Hi,

If your Exchange Server 2013 Cumulative Update fails with the following error:

The following error was generated when "$error.Clear();
$windir = $env:windir;
# Note: Turning off DynComp for AppPools like MSFFOGLSAppPool as well
$backEndAppPrefix = "Exchange Back End";
$apps = &"$windir\system32\inetsrv\appcmd.exe" "list" "app";
foreach($app in $apps)
{
$startIndex = $app.IndexOf('"') + 1;
$numChars = $app.SubString($startIndex).IndexOf('"');
$appName = $app.SubString($startIndex, $numChars);

# Don't want to disable Dynamic Compression on 1 box topologies for BE Apps, so adding check
if($appName.StartsWith($backEndAppPrefix))
{
Write-ExchangeSetupLog -Info "Skipping $appName since Dynamic Compression should remain turned on for
it";
}
else
{
# We'll set this whether or not the app pool exists. Failures are ignored.
$a= &"$windir\system32\inetsrv\appcmd.exe" "set" "config" "$appName" -section:urlCompression /doDynami
cCompression:false /commit:apphost
Write-ExchangeSetupLog -Info ($a)
}
}
" was run: "Cannot convert 'System.Object[]' to the type 'System.String' required by parameter 'Message'. Specified method is not supported.".
The Exchange Server setup operation didn't complete. More details can be found in ExchangeSetup.log located in the
<SystemDrive>:\ExchangeSetupLogs folder.

 

Check the execution policy of Windows PowerShell and ensure it is set to 'Unrestricted'.

To check the execution policy run:

• Get-ExecutionPolicy

To set it to unrestricted run:

• Set-ExecutionPolicy Unrestricted

 

ecsword

Powerhell ile AD sorgulamaları için basit bir script

Bu basit ve küçük PowerShell scriptini el altında bulundurarak Active Directory (AD) nizi hızlıca anahtar kelime kullanarak sorgulayabilirsiniz. Cevap olarak size obje tipi kısıtlaması olmadan bulduklarını döndürecektir. Bu basit halini isterseniz değiştirip daha farklı işler de yaptırabilirsiniz. Derinlemesine aramalardan önce kolayca obje bulma konusunda yardımcı olacağını düşünüyorum.

param(
[Parameter(Mandatory=$true,Position=1)][string]$Query
)
$filter = "anr=$Query"
$dc = "DCSunucunuz:3268"
Get-ADObject -LDAPFilter $filter -Server $dc

Kullanımı

.\Get-Something01.ps1   osxx

Çıktısı

DistinguishedName	Name	ObjectClass	ObjectGUID
CN=Osman SHENER,…	Osman SHENER	user	2c973a30-4e…
CN=osxxNOT01,OU=…	osxxNOT01	computer	840e9c35-4d…
CN=osxxOSDW7TEST…	osxxOSDW7TEST20	computer	afe1c1fe-41…
CN=osxxPC01,OU=W…	osxxDSK01	computer	3db219e1-44…
CN=osxxVM,OU=San…	osxxVM	computer	ecefbb2f-44…

Handy Powershell script to query AD for any object

I believe keeping this handy and simple PowerShell script within reach is a good idea to query your Active Directory (AD) quickly with a hint of name. It will return you objects that have your wildcard in it. Quick way find things before digging more.

param(
[Parameter(Mandatory=$true,Position=1)][string]$Query
)
$filter = "anr=$Query"
$dc = "YourDC:3268"
Get-ADObject -LDAPFilter $filter -Server $dc

Usage

.\Get-Something01.ps1   osxx

Output

DistinguishedName	Name	ObjectClass	ObjectGUID
CN=Osman SHENER,…	Osman SHENER	user	2c973a30-4e…
CN=osxxNOT01,OU=…	osxxNOT01	computer	840e9c35-4d…
CN=osxxOSDW7TEST…	osxxOSDW7TEST20	computer	afe1c1fe-41…
CN=osxxPC01,OU=W…	osxxDSK01	computer	3db219e1-44…
CN=osxxVM,OU=San…	osxxVM	computer	ecefbb2f-44…

Enabling disk performance counters in Windows Server 2012 R2's Task Manager Performance Tab

Enabling disk performance counters / graph in Windows Server 2012 R2's Task Manager Performance Tab

It is very easy to enable disks in Task Manager's Performance tab in Window Server 2012 R2,



All you need is to run diskperf -y command in a elevated command prompt, it enables counters as it says in the output.

Windows Server 2012 R2 'da Görev Yürütücüsünde gözükmeyen disk performans verileri

Windows Server 2012 R2 'da Görev Yürütücüsünde gözükmeyen disk performans verileri
Windows Server 2012 R2 işletim sisteminde görev yürütücüsünü açtığınızda Performans sekmesinde disk verilerini göremiyorsanız.



Aşagıdaki şekilde diskperf -y komutunu Admistrator yetkileri ile açtığınız komut istemi penceresinde çalıştırarak aktive edebilirsiniz.