OT: Microsoft Certified Master

My blog posts have been very lacking recently as every single moment I have spare has been spent preparing for the Exchange Microsoft Certified Master (MCM) next week. I fly out on Friday, with classes due to start on Monday.
With the amout of information I have read about this course and the relatively low pass rate considering the acceptence criteria, I am incredibly nervous and feel very unprepared. I have completed about 85% of the pre-course reading material (there was a lot on it. With the 11 hour flight and the rest of this weekend, I hope to get close to 100%. How much I remember is a different question.
As well as being nervous, I am incredibly excited. This will probably be one of the best technical learning experiences of my career and expect to come out a changed man, regardless of the exam results :o)

I will definately not be posting over the next 3 weeks whilst I am there, so will post back on the other side.

Exchange 2007 message size limits

Setting message size limits on your Exchange platform is a fairly obvious, although sometimes controversial best practice. The primary reasons for doing this include managing mailbox growth rates, network utilisation and also preventing potential Denial of Service attacks.

Once you have sorted out the politics of setting message size limits and how big this limit should be, how do you actually implement on Exchange 2007? Of course the first place I would set it is in the Organization Configuration > Hub Transport > Global Settings > Transport Settings > Transport Limits or I would use the Set-TransportConfig cmdlet.

Easy, eh? Well no, that is only a small part of the whole story. There is a whole bunch of other stuff you need to consider.

What: Do you want to limit the size of the Message, the Message Header, attachments?
Scope: You have just set a message size limit at the Organization level. But you can set it all these levels;
1. Organization / Global
2. Connectors ( including Send, Receive, Site Link and Routing Group connectors)
3. Servers
4. User objects (including mailbox, contact, Distribution Group and contact level).
Precedence or Effective limits: What if you set different attachment size limits on different scopes. Which one applies? The smallest size? The largest size? The one set last?

What

I think for most Exchange Organizations they would not need the granularity of exactly what part of a message they want to apply to size limits to. For the main reasons I listed at the top, accepting the Exchange 2007 SP1 defaults and then only considering what to change the maximum message size to (including attachments and headers) would be sufficient.

Scope

First thing to clarify is what is the difference between Organization level and Global level? In a nutshell, the Organization size limits apply to all Hub Transport servers in the Exchange Organization. The Global size limits applies to all Exchange 2007 Hub Transport servers and all Exchange 2003 servers in an Exchange Organization. In Exchange 2007 SP1 these limits cannot conflict as the Organization limits will be copied to the matching Global limits. (This was not the case with Exchange 2007 RTM, but there is no point going into that as no one in their right mind would still be running Exchange 2007 RTM - IMHO. For the rest of this post I am not going to include Exchange 2007 RTM info). To set message size limits on the Edge Transport server you will need to use the server scope in the EMC or the Set-TransportServer cmdlet.
The other scope levels are fairly self explanatory. With Exchange 2007 SP1, anywhere Microsoft set a default maximum message size it is 10MB. It would take me too long to list all the places this limit has been set here.

Precedence

Now this is important. If I want to set Organization message size limits, can I create exceptions to the rule? If I set different size limits what is the Effective message size limit for a particular mailbox?
Unfortunately figuring out exactly what take precedence or what effective message size limits are, is not entirely obvious on the main Technet article describing setting message size limits in Exchange 2007. Even the one example seems to be missing words.

A good rule of thumb is if the user object (any one of the list above) message size limit is higher than the Organization message size Transport limits, then an email to the higher size limit can be sent internally. Unfortunately this precedence does not occur for any email being sent or received from outside the Exchange Organization.

Gotcha....
A major “gotcha” to watch out for is that the initial size of a message may get bloated by content conversion by a decent percentage. An email that begins as 10MB, could end being 13MB after content conversion and therefore violate message size limits. If you are troubleshooting message delivery failures, a good place to look is the Message Tracking logs. (Enabled by default in Exchange 2007)

OT: Humour - Vista progress

I had to remove the "Compress this drive to save disk" space property on a computer hard drive. Obviously it is not good practice to compress a system volume in the first place, but have a look at how long it is going to take to decompress this volume!

Set-CASMailbox

I think this is one of the most annoying cmdlets in Exchange 2007. I recently attempted to use this cmdlet to disable the Change Password window in Outlook Web Access for a lot of mailboxes that were going to have their password set via a 3rd party synchronisation tool. It has been some months since I had last run Set-CASMailbox and had forgotten about it's sledgehammer approach. Basically if you set just about any of the segmentation attributes to $false, it sets them all (beginning OWA....) to $false also. (Thank goodness that was on my test rig...)

Here is a list of all OWA Segmentation attributes that will get set to $false by running the command Set-CasMailbox BGibson OWAChangePasswordEnabled $false ;

OWACalendarEnabled : False
OWAContactsEnabled : False
OWATasksEnabled : False
OWAJournalEnabled : False
OWANotesEnabled : False
OWARemindersAndNotificationsEnabled : False
OWAPremiumClientEnabled : False
OWASpellCheckerEnabled : False
OWASearchFoldersEnabled : False
OWASignaturesEnabled : False
OWAThemeSelectionEnabled : False
OWAJunkEmailEnabled : False
OWAUMIntegrationEnabled : False
OWAWSSAccessOnPublicComputersEnabled : False
OWAWSSAccessOnPrivateComputersEnabled : False
OWAUNCAccessOnPublicComputersEnabled : False
OWAUNCAccessOnPrivateComputersEnabled : False
OWAActiveSyncIntegrationEnabled : False
OWAAllAddressListsEnabled : False
OWAChangePasswordEnabled : False
OWARulesEnabled : False
OWAPublicFoldersEnabled : False
OWASMimeEnabled : False
OWARecoverDeletedItemsEnabled : False

That's right, if you set one to $false you set them all to $false unless you explicitly remember to list every other attribute and set them all to $true in the command.

Thankfully there is a quick fix to reverse this action. Open ADSIEdit.msc and browse to the affected AD user account(s). Select the user properties and find the msExchMailboxFolderSet attribute. Clear any value in this attribute (i.e. ) and the OWA Segmentation properties will all be set back to default.

So how do you set one OWA Segmentation attribute then?
You can either list all the attributes above as $true, except the one you want to set as false. Or you can use ADSIEdit to set all attributes to $True by setting the msExchMailboxFolderSet value to 2147483647 and then change the one attribute you want to disable using the Set-CASMailbox cmdlet again.

Windows 2008 initial settings

This blog post is mostly for myself to easily cut and paste from here, but it may be useful to some others. I find myself continually installing and reinstalling Windows 2008 servers for Exchange 2008 dev environments these days. So I have began to write a batch file I cut and paste each time, edit a few parameters, save as SVRCFG.cmd and then double click. This saves me a few minutes of manually typing everything out each time. Multiply this by an average 8 servers per environment and it soon adds up. Nothing here is rocket science, just nice simple command line administration in a batch file.

powercfg /hibernate off
netsh firewall set opmode DISABLE
netdom renamecomputer %computername% /newname:ET01 /force
netsh int ipv4 set address name=10 source=static address=192.168.0.15 mask=255.255.255.0 gateway=192.168.0.254
netsh int ipv4 add dnsserver name=10 address=192.168.0.1
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v AUOptions /t REG_DWORD /d "3" /f
servermanagercmd -install Powershell
Shutdown -r -t 2

Things to check:
Change the server name
Change the IP address
Check the Network cards Idx number or "name"

OT: Microsoft Certified Master: Exchange

Thought I would give a quick update on here to say I have been accepted onto the Microsoft Certified Master for Exchange(MCM:Exchange). So in March I will be off to Redmond for three weeks intensive training, 3 written exams and a lab. I am incredibly excited at the prospect of learning so much and attaining that next level in my career, certification and technical abilities. It does mean the next few months will be spent completing that enormous reading material list and studying my weaker areas a lot more indepth.

What is the MCM?

The new Microsoft Certified Master series offers advanced technical training and certifications on Microsoft technologies that go beyond any product training offered outside of Microsoft today. IT professionals who successfully complete the training program and certification testing validate their skills as product experts who successfully design and implement solutions that meet the most complex business requirements.

Candidates who successfully complete the program can expect to have a greatly improved understanding of the Microsoft Exchange Server 2007 platform. Microsoft Certified Masters can design and build customer-specified messaging solutions, and they understand how design decisions affect the final solution. They can troubleshoot and diagnose configuration and performance issues, and they have the detailed knowledge and skills that are required to successfully operate and manage an enterprise-class Exchange Server 2007 infrastructure.

http://www.microsoft.com/learning/mcp/master/default.mspx
http://www.microsoft.com/learning/mcp/master/exchange/default.mspx

All being well, with a lot of blood, sweat and tears (or maybe just a hell of a lot of studying) I will become a MCM:Exchange in a few months time!

Exchange 2007 LoadGen installation issues

I have had a few hours frustration and an eventual work around to installing the Exchange 2007 Load Generator in one of my test environments.

I have been trying to install the Exchange 2007 Load Generator (LoadGen.msi) on a range of servers with the same installation error occurring each time. The errors occured when installing both the 64-bit package on some Windows 2008, 64-bit servers and also the 32-bit package on some Windows 2003 R2 SP2, 32-bit servers. Here are the range of errors and diagnosis:

The Microsoft Exchange Load Generator installer gives the following error message:

There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact you support personnel or package vendor.

The server's application event log gives the following error message:

Event ID: 11722 Source: MsiInstaller
Product: Microsoft Exchange Load Generator -- Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action START_REMOTE_SERVICE.B08E90EE_3FC7_4509_A7F3_DE16BC275F17, location: net.exe, command: START LoadGenRemote

If I run the MSI with verbose logging (msiexec /i LoadGen.msi /l*v C:\LoadGen.txt) I get the following error in the verbose log file.

Generator\LoadGenRemoteSvc.exe", ServiceType=16,StartType=2,ErrorControl=0,,,,StartName=LocalSystem,Password=**********, Description=Enables distributed load generation for the Microsoft Exchange Load Generator tool.)
Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action START_REMOTE_SERVICE.B08E90EE_3FC7_4509_A7F3_DE16BC275F17, location: net.exe, command: START LoadGenRemote


When you click OK to the installer error message it of course rolls back all actions in the MSI. The last error message pointed me in the direction of it being a service problem. If you do not click OK and look in the Services.msc you will see there is a service called Microsoft Exchange Load Generator Remote Agent. This service is configured as Automatic, but is unable to startup using the Local System account credentials. If you give it another account (I used an admin account in my test lab) it does start. Of course this is useless as the installer has already failed and the only option is to click OK and roll back the install.

As an absolute pot luck guess, before beginning to think about attempting to edit the MSI the following action allowed the installation to complete. The answer is.....

Disable the network card during the MSI installation!

Yep - for some completely unknown (to me) reason, this allows the installation to complete and the service to run as the Local System account.