Two of the many significant changes coming with Exchange 2010 are the change to DAG’s and to terminate MAPI connections at the Client Access Layer. 

Under Exchange 2007 an Outlook user has the server name configured to that of the mailbox (server / cluster) name, under Exchange 2010 with the concept of DAG’s you no longer connect to the exchange mailbox server directly, your server name is one of your Client Access Servers.  In its out of the box configuration its not very fault tolerant, if the client access server is unavailable the client wont be able to connect.  Client Access Arrays along with load balancing (can be NLB, Forefront TMG or another solution) are the way to tackle this issue.

In this example I have a Forefront TMG (beta 3 – I’ve not upgraded to the RC yet…) server exposed to the internet, behind this I have two Exchange 2010 servers both running Hub, Client Access and Mailbox roles.  There is also a supporting AD, DNS, Certificate infrastructure etc… however I’ve not shown it in the interests of keeping this simple, thanks to Visio it looks like this:

I am publishing the following external names:

autodiscover.contoso.com – Exchange autodiscover

mail.contoso.com – OWA, OA, EWS, ECP, EAS

As we want to load balance / provide fault tolerance for our Exchange 2010 services we have a web farm created with Exch2010.contoso.com & Exch2010-2.contoso.com using HTTP / HTTPS GET requests to verify connectivity. 

Three publishing rules have been configured as follows:

All publish to the web farm containing the two Exchange servers.  Again in the interests of keeping this simple I’ve not gone into SSL offload & authentication delegation – best practice would have multiple listeners – FBA for OWA, NTLM for OA etc… but I’ve got one public IP so one listener it is!

To configure a client access array the following steps need completing (I’ve not documented the usual steps you would go through to configure your internal and external URL’s – you set these up as usual):

• Create a client access array

Creating the client access array is simple, all that is needed is to specify an FQDN (an internal name which doesn’t resolve on the internet is fine – the name doesn’t get registered in DNS) and name, in this case I used cas.contoso.com (original eh!) and the AD site the array will serve:

New-ClientAccessArray cas.contoso.com -FQDN cas.contoso.com -Site Default-First-Name-Site

This will create your new array & place all Exchange servers with the client access role in the site specified into your array.

• Configure mailbox databases to use the client access array – this information is then passed back to the client via autodiscover.

When the mailbox database has the RPCClientAccessServer field completed this specifies either a client access server or client access server array to be returned to the client through autodiscover. 

Simple enough to do, this is the command I used:

Set-MailboxDatabase testdb -RpcClientAccessServer cas.contoso.com

Once this has been set, allow a few minutes for replication & client connections will start to be directed to cas.contoso.com from autodiscover & existing clients will begin to update their configuration – the Exchange Server field in outlook will become cas.contoso.com.

So should one of your client access servers go offline TMG will send the connection to another server in the farm and the client will continue to work as it has as CAS array name specified rather than an individual server.

There is documentation on technet about this, however it’s still quite vague – as you would expect at this stage, more will come in due course.

Exchange… awesome product! 

Microsoft have released a free eBook that contains useful content from both the Microsoft Press Windows 7 Resource Kit and Technet, its available for download from the following link;

http://www.microsoft.com/downloads/details.aspx?FamilyID=EE2A1D38-88A9-43B3-95BC-7E962F0B6030&displaylang=en

Enjoy!

Just found this gem of information on Anderson Patricio’s blog, something which stumped me when setting up some 2010 HA demo’s. 

Exchange 2010 allows you to create a highly available implementation with just two servers (excluding edge), you can combine mailbox, hub and client access on one box, do this twice & use a DAG to replicate the databases & you have highly available Exchange (you can use Forefront TMG to load balance). 

The Exchange 2010 DAG functionality replaces the CCR / SCR technology in Exchange 2007, like CCR DAG requires a file share witness to prevent split brain syndrome.  Typically in Exchange 2007 you would place this on a Hub transport server (having manually created the share & permissions), Exchange 2010 has a wizard to create the FSW on a remote server for you which is handy, however as I found out when I tried to use it against a non Exchange server it didn’t work, I manually created the FSW – putting it down to a Beta / RC bug, however it would appear that you need to add the Exchange Trusted Subsystem group to the local administrators group on the target server to allow the FSW wizard to work.

Rob

Previously this was a bit of an effort in Operations Manager pre R2, but the feature is now much improved with the ability to scan the update catalog directly.

Most customers adopt a weekly check that involves monitoring blogs for latest updates to the Microsoft management packs. R2 now lets you scan your installed management packs for any updates required.

In the administration console select Import management packs, click add and select add from catalog. This queries Microsoft’s catalog directly, we can now change the view to ‘Updates available for installed management packs’ click search and any management packs in need of updating will appear (A bit like the shop keeper in Mr Ben) These can then be added, the process will download then import them.

In my next post I will  share with you how we can use another less well known method for those still using Operation Manager Pre R2.

Laters

via the sysinternals website Microsoft have released a new free P2V tool – Disk2VHD which creates a vhd of a machine, using VSS to snapshot the machine while it is running.

While this does not update the HAL and inject drivers you could use it to convert a running Win7 machine to vhd and use it to boot that machine from vhd with little or no fuss or just to create a bootable backup.

you can get it here:

http://technet.microsoft.com/en-nz/sysinternals/ee656415(en-us).aspx

If you have heard the story this weekend that Microsoft are working on a 128bit version of Windows for Windows 8 then I am afraid this is nothing but unfounded rumour. The story started by reporting of a LinkedIn profile of someone claiming to work on a high security project for Windows 8 and incorporating 128 bit support. Unfortunately the person isn’t real and neither have they worked for Microsoft.

Looks like the Windows 8 hype starts here now 7 has shipped

Windows 7’s XP mode feature and its counterpart Windows Virtual PC are now available in x86 and x64 editions to download from MSDN and TechNet having been signed off on the 1st October.

XP mode is licensed for Windows 7 Enterprise customers allowing you to deploy 7 today and run your XP applications via a Windows XP virtual machine. The experience is pretty good, and offers shortcuts integrated into the Windows 7 desktop and Start menu making this  a simple way for users to run XP apps without necessarily having to understand the concepts of virtual machines, etc. Only caveat is your client PC’s or laptops will need to have virtualization support e.g. Intel VT or AMD-V extensions and enabled in the BIOS.

Get more info on Windows Virtual PC here:

http://www.microsoft.com/windows/virtual-pc/features/compare.aspx

Headlines are:

• Integration with Windows XP Mode
• USB support for devices such as storage and cameras, etc
• Seamless application publishing and launching
• Support for multi threads
• Clipboard sharing between Windows 7 and virtual machines
• Printer redirection allowing virtual machines to print to the host’s printers
• Smart card redirection
• Support for higher resolutions  up to 2048×1920 from 1600×1200.

A follow up to Certificate Strangeness – if you found that useful, you’ll probably be looking at making some changes to fix whatever issues you were having.

While it is theoretically possible to script ACL changes in Powershell and VBS, there’s no point in re-inventing the wheel when there are perfectly good command line tools available. Most of us are aware of CACLS, which has been around for donkeys years, but you may not be aware  its use is now deprecated, as it can incorrectly order the ACE’s on the ACL.

Ideally, you would use ICACLS.exe, as this is the utility currently shipped and supported by MS. However, there are 2 versions – Vista and upwards, and 2003 downwards. The Vista version will remove the inheritance flag from an ACL, but the 2003 version will not. Also, if the user is the owner of a file, the Vista version will successfully write an ACE onto an empty ACL, whereas the 2003 version will not. Of course, if you are fixing ACL’s on the MachineKeys folder and its files, these are the very 2 actions you need to accomplish. If we could just copy the exe across and use the Vista version on an XP system, everything would be gravy, but life is never that simple – it just errors out.

The solution? Let somebody else write the script

xcacls.vbs is available for download from the MS website, and successfully achieves both the actions outlined above on an XP system – be aware that its use is NOT supported by MS, but be that as it may, if its the only tool available on XP and 2003 ….

Recently I was tasked with performing a mass update on a large HMC / multi tenant style Exchange 2007 implementation.  The update itself was a reasonably simple one – prevent Outlook clients who were not running in cached mode from connecting to their mailboxes (as an aside the reasoning for this was the need to prevent clients with desktop search applications from having a negative performance impact on mailbox servers), the PowerShell cmdlet to do this is ‘Set-CasMailbox’.

In our test environment I executed the following in an Exchange PowerShell session:

Get-CasMailbox -OrganizationalUnit ‘PlatformUsers’ -resultsize unlimited | Set-CasMailbox -MAPIBlockOutlookNonCachedMode:$true

This had the desired effect however took quite some time to run, so looking for a way of speeding this up I stumbled upon the UseRusServer option.  Including this the above command now looks like this:

Get-CasMailbox -OrganizationalUnit ‘PlatformUsers’ -resultsize unlimited | Set-CasMailbox -MAPIBlockOutlookNonCachedMode:$true -UseRusServer <servername>

By using this command Exchange doesn’t have to look for a server running the Recipient Update Service, this makes the process a lot faster (by some rough timings in this environment somewhere between 7-10 times faster) it also meant I had control over which server was used to perform the update against, I chose a server responsible for OAB generation, Exchange could have chosen a mailbox server holding user mailboxes, there likely wouldn’t have been a performance impact but why take the risk.

In the live environment this change affected around 400,000 accounts, so the performance improvement was worth having!

Rob

Here’s a scenario, you have a PKI, it all seems to be healthy, but when you try and use the certificates on your client systems, you get ‘unexpected results’

Alternatively, you have issued certificates previously, but when you come to renew, systems fail with ‘unexpected results’

At this point, you might be ready to tear your hair out, or just go home for the night (or the month…). Instead, its worth checking the permissions on the folder where the client OS stores the systems private keys. If the ACL has been changed from the system default, results can be, lets say, unpredictable.

On XP and 2003 systems, the folder in question is “c:\documents and settings\all users\application data\microsoft\crypto\rsa\machine keys”. This folder must NOT be inheriting permissions from its parent, and the ACL for the folder should contain Everyone:RW:This Folder Only, Administrators:F:This Folder Only – and nothing else! If you need to grant a service account access to one of the keys, add the account to the ACL on the specific file within the folder. Each file in the folder has explicit permissions defined, which will vary depending on the application that generated it, as a minimum they must include System:F and Administrators:R

Quite why the systems private keys would be stored in the All Users profile, I don’t know, but it has been moved in Vista and Server 2008 to “C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys”, which seems far more logical, and prevents errors where misguided administrators reset the permissions on the entire All Users profile. The ACL structure for the folder and its files remains the same.

A final word of warning – as with anything you read on the web, its always worth checking these ACL’s against a system in your environment that you know to be working, if you have one. It doesn’t matter how much you trust the writer, there’s nothing like the comfort of seeing a working system with your own eyes before you propose a change to hundreds or thousands of systems…

See the next post for info on scripting changes to the ACL’S