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

During a migration from OCS R2 to Lync I started having a problem when testing UM access to voicemail; displayed an error on call or redirect and disconnected. Ran some tracing and the following error was flagged in the diagnostics field:

MS-client-diagnostics: 52059;reason=”Invalid SDP in response”

Turns out this is caused by the VoIP Security setting  in the Exchange UM Dial Plan option. Whilst I used to have this configured as ‘SIP Secured’ when operating with OCS R2, it would appear it now requires to be ‘Secured’ to function correctly with Lync2010.

So, to fix: Exchange > UM Dial Plans > Properties of your Dial plan > VoIP Security = Secured

Hope this helps

Neil

When attempting to merge the existing OCS estate into Lync I get the following error:

2011-03-14 17:25:46 INFORMATION :  User input file path: "C:\Users\risual\AppData\Local\Temp\TopologyBuilder\2011_03_14_17_25_44\MergeTopologyInput.xml"
2011-03-14 17:25:46 ERROR :  Total number of validation errors: "1"
2011-03-14 17:25:46 ERROR :  Topology error description: "There was a problem validating the topology XML against the XSD that defines the schema."
2011-03-14 17:25:46 ERROR :  Topology error instances: "[ System.Xml.Schema.XmlSchemaValidationException: There is a duplicate key sequence 'urn:application:Rgs SipServer Primary Mtls' for the 'urn:schema:Microsoft.Rtc.Management.Deploy.ServiceRoles.2008:ComponentPortId' key or unique identity constraint. ][ System.Collections.Generic.List`1[System.Object] ]"
2011-03-14 17:25:46 ERROR :  Topology error reason: "FailedSchemaValidation"
2011-03-14 17:25:46 ERROR :  There were errors while creating and validating a topology.
2011-03-14 17:25:46 WARNING :  Total number of errors is 1
2011-03-14 17:25:46 WARNING :  Total number of warnings is 0
2011-03-14 17:25:46 ERROR : BuildTopologyError

Found this useful link which has some pointers on trying to locate and troubleshoot the issue:

http://viammercer.blogspot.com/2010/12/merge-topology-failure-microsoft-lync.html

Personally, the above didn’t work for me.

Because I knew it was an RGS error (‘urn:application:Rgs SipServer Primary Mtls’) I ran a validation against the RGS in OCS and it came back with an error reporting that it was expecting one CN record but it was in fact set to another. I tried to set the correct CN in ADSI Edit but just received an error.

How did I fix this? Well, luckily for me the customer wasn’t using the RGS so i deactivated it. After it had been deactivated the OCS to Lync merge process completed without any errors.

Hope this helps

Neil

Finally… some information about the Lync Client for Windows 7 mobile.

Stumbled across this blog earlier and thought it was well worth passing on as information about the development of the client has been… well, thin.

http://obieosobalu.wordpress.com/2011/03/04/windows-phone-7-lync-client-v1-0/

Neil