A few official videos have been produced by the Exchange MCM team, well worth a look if you’re considering attending (which you should because it rocks):

Detail from Bojan on his thoughts heading into the MCM:

http://borntolearn.mslearn.net/careerfactor/b/bojan/archive/2011/03/18/bojan-s-story-starts.aspx

Video featuring a number of instructors for the programme (& a view of the classroom – where you’ll live for three weeks J):

http://vimeo.com/21215132

A section of the transport content delivered by Brian Reid:

http://blogs.technet.com/b/themasterblog/archive/2010/12/28/mcm-exchange-video-preview.aspx

Rob

I have a situation where user data is migrating from one forest to another and there is a need to set permissions on folders which will form home ‘drives’ for users. The users’ home directory names match their SAM account names, I have written a simple PowerShell script to assign full control NTFS permissions to those folders based on the name of the user.

#script to give full control NTFS permissions on a directory to the domain user with the same name of that directory

#script settings

$domain = “robsdesk”

$root = “c:\data”

#don’t edit below here
$folders = Get-ChildItem $root

ForEach ($folder in $folders)

{

$username = $domain+“\”+$folder

$permissions = Get-Acl $folder

$userpermissions = New-Object System.Security.AccessControl.FileSystemAccessRule($username,“FullControl”, “ContainerInherit, ObjectInherit”, “None”, “Allow”)
$permissions.AddAccessRule($userpermissions)

Set-Acl $folder $permissions

Write-Host“Set permissions on $folder for $username”

}

The two lines to edit are the $domain and $root lines, the $domain line should be your domain name, this is used to construct the ‘domainname\user’ text used in the script. The $root variable is the root folder containing the folders to have permissions applied.

It’s quick and dirty – only used for a one off & there’s no error checking so be careful before you use it!

Rob

DCDiag is one of those tools which is generally only used when things are going wrong, it can be very handy in finding directory services issues (which can manifest themselves in all kinds of ways….) Ned Pyle on the Directory Services team blog has written a brilliant post on this tool & what the various switches are actually doing for you, well worth a read (hopefully before you have to use it in anger): http://blogs.technet.com/b/askds/archive/2011/03/22/what-does-dcdiag-actually-do.aspx

Rob

Hi,

I was recently on a call with some Exchange peers & we were fortunate enough to have a guest appearance from Tod Edwards from the Windows Server team at Microsoft. He attended to provide some background & recommendations to making the above technologies work successfully with Windows Server and why they should be enabled where possible. As this information is in the public domain & helps improve everyone’s experience I have reproduced it here.

Background

RSS – Receive Side Scaling, this allows a server to spread network interrupt traffic over more than 1 CPU, significant benefits have been seen with this on 1Gb+ network interfaces

TCP Chimney – Allows the offloading of TCP/IP processing to the network card, both Intel and Broadcom have NICs in the market which support this, the benefits with this feature are less pronounced at 1Gb connections but significant at 10Gb connections (think iSCSI storage connections)

Chimney is incompatible with some features in Windows (firewall, etc.), & if they are enabled Chimney will not offload any connection. In W2008 R2, the Windows Firewall is compatible with Chimney, which was a change from previous OS.

TCP Chimney Offload is not the same thing as Checksum Offload, Large Send Offload, etc. Those offloads have been around for since W2003 & are generally problem free.

RSS & Chimney both require the above basic checksum offloads to function, so disabling any of them (in NIC properties) will automatically keep RSS and Chimney from being used.

Compatibility issues

As alluded to above, these technologies work really well with 2008r2 out of the box, on older operating systems (2003) you’re probably already familiar with needing to disable these to resolve issues, here are recommendations as to how things should be configured for the various Microsoft Server OSs in the market at this time:

W2003 SP2: RSS, Chimney & NetDMA are known to be problematic. Customers should disable these manually or use KB:948496. If you really need the features, install SNP roll-up (KB:912222) for W2003 and re-enable features.

W2008 RTM: RSS is on by default but Chimney is off. RSS had some issues that customers hit after installing W2008, most were resolved in SP2, & remaining were solved in KB:979614 (which brings RSS/Chimney to W2008 R2 level).

W2008 R2: RSS is on by default & Chimney is in ‘Automatic’ mode, which means the TCP connection being offloaded has to be 10Gb speed, less than 20ms latency between the 2 end points, & transmitted at least 130k. See page 6-7 of ‘W2008 R2 Networking Deployment Guide: Deploying High-Speed Networking Features‘

Win2008 R2 SP1 does not contain any fixes related to Chimney, and only has 1 fix for RSS that fixes a bug where RSS only uses 1 CPU when you have over 32 processors, KB:977977

If you’re seeing issues on modern operating systems which are resolved by disabling the above features ensure you’re systems are using the most recent NIC drivers, filters (teaming, AV, firewall etc..) & BIOS – whilst the market has matured there are still issues resolved with updated vendor drivers. It is important to work through these issues & use the functionality, in the Exchange world customers have achieved higher throughputs & got more value out of their hardware by getting these features turned back on.

Rob

Recently I had to undertake an IP change on a UAG array, after having made the IP change on the interfaces on both servers in my array I needed to update the portal configuration within UAG to bind it to the new IP address, annoyingly only one of the two nodes was showing the correct address.  I tried various things including removing & re-adding the troublesome node to the array.  Eventually after some research I found some information which pointed me towards the uag.map file in the C:\program files\Microsoft Forefront Unified Access Gateway\common\conf directory.  This file has some (not all) of the UAG configuration stored within, including IP addresses bound to the nodes in the array, I updated every incorrect entry to the correct entry, saved the file & reloaded the configuration in UAG, finally the correct addresses were being reported.

This is obviously not a supported / documented / recommended thing to do!  (be very careful & take a copy of the file before you change it)  In my situation I was rapidly coming to the conclusion re-building the array from scratch was going to be required, so I had an ever decreasing amount to loose by making the edit.

Rob

This is something which I’m really pleased to see Microsoft talking about, whilst technically supported using NLB for CAS it’s a bad solution, some of the reasons being:

• It doesn’t scale well
• It isn’t service aware (if the NLB service is running on the target server it will get its share of client requests regardless of if Exchange is actually able to service them)
• You cannot combine it with Failover clustering (which is required for a DAG node) & multi role solutions (Hub, CAS & Mailbox) are very effective with Exchange 2010
• Potential switch issues

So as Steve Goodman has reported Ross Smith IV spoke about this in his TechEd Europe session a few weeks ago his recommendation is to use a proper HLB solution, I’ve had good results with the Kemp series of HLB’s, I’ve used both the virtual appliances and the physical hardware appliances.  These are very cost effective & meet the requirements for load balancing & making Exchange 2010 CAS highly available.  Henrik Walther has written a good article on using the Kemp appliances with Exchange 2010, well worth a read.

Rob

I didn’t think we’d ever see this!  Ori on the Forefront TMG product blog has announced Update 2 for TMG SP1, which includes support for NLB with teamed or VLAN Tagged NICs.  The blog entry is here: http://blogs.technet.com/b/isablog/archive/2010/11/30/support-for-nlb-on-vlan-tagged-or-teamed-network-adapters.aspx & the update itself here: http://support.microsoft.com/kb/2433623/

Rob

I ran into this one in the wild today – as has Neil C, adding routes using route add under server 2008r2 seems to give some inconsistent results – using netsh does the job nicely, there’s a nice write up of the commands here: http://fixmyitsystem.blogspot.com/2010/10/adding-static-route-using-netsh-and.html

Rob

This seems to be a bit of a black art – however Microsoft have published guidance for BPOS / Office 365, which is ideal for calculating your own numbers: http://technet.microsoft.com/en-us/library/cc745931.aspx. 

Rob

Linked to my previous post around mailbox exports I had a need to run a mailbox export from a scheduled task (as it was going to take several days and my session would be reset if left idle for too long), so a scheduled task felt like a good solution, setup a scheduled task & manually start it. 

With the change to remote PowerShell with PowerShell 2 you have to do things a little differently than previously (where you could simply use import-module to load the exchange management ps commandlets), to do this for Exchange 2010 I did the following:

• Create a scheduled task with no schedule and the following action:
• Action: Start a program
• Program / script: powershell.exe
• Add arguments: -command ". ‘c:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1′; Connect-ExchangeServer -auto; c:\pathtoscript\script.ps1"
• On the general tab change the security options to look like this (the user account needs to have the required level of privilege granted by Exchange to do what ever it is your script has asked):
• 
• The ‘Run with highest privileges option’ was key for me, with that un-ticked the powershell process would start but nothing would actually happen, this is akin to pressing yes when prompted by the UAC dialog when you launch Exchange PowerShell.

You can then either setup a schedule if required or run the script on demand.

Rob