Ant Drewery

There has been a lot of discussion recently about the changes to daylight savings time in the USA. The changes have come about due to the 2005 Energy Policy Act. In previous years, DST in most of the USA ran from the first Sunday in April until the last Sunday in October. From 2007 DST will be from the second Sunday in March to the first Sunday in November. I’m based in the UK so these changes do not affect me directly but I work for a global company with a global Windows/Exchange environment so there is an impact to address.

Microsoft has had a patch available to address the issue since late November 2006. This has recently been updated to include DST changes in other time zones around the world. My recommendation is to deploy this patch to ALL Windows machines in your environment. The patch can be distributed via WSUS if you have this facility available.

Once the patch has been deployed you may need to correct entries in the Outlook calendar. Microsoft have provided two tools to do this. The first (http://support.microsoft.com/kb/931667/) is a tool that needs to be run individually for the affected users. The tool requires user interaction so you may want to distribute a link to a file share along with detailed instructions on how to run it and it’s potential impact. You should also give examples of why the tool is necessary so that the users have a good understanding.

The second tool is for Microsoft Exchange (http://support.microsoft.com/kb/930879) and will allow you to update the calendars centrally. If you are going to take this approach you need to carefully consider the risks of a blanket update. KB930879 lists the pros and cons of this method.

You can find more information from Microsoft about the DST changes here: http://support.microsoft.com/gp/cp_dst

UPDATE:

There are now patches for Blackberry (http://www.blackberry.com/select/dst2007/index.shtml) and Windows Mobile (http://www.microsoft.com/windowsmobile/daylightsaving/default.mspx).

Part of the way my current employer has grown is through acquisitions and mergers. Consequently we’ve been supporting more than 10 legacy SMTP domains from various shipping lines. Now that we’re decommissioning our systems it’s time to do some housekeeping and discontinue these domains.

The first step was to check that all objects had their primary SMTP address set to the main domain name. This was done more than a year ago but needed to be reconfirmed. A custom LDAP query that included the syntax  (!mail=*@our_main_domain.com) sufficed.

Next I wrote a script that exported all SMTP proxy addresses for user objects. This was to be used as a reference in the unlikely event that problems arose down the line. The LDAP query can easily be modified for groups, contacts and public folders. It’s not the most exciting of scripts but it does the job. You can download it here: AllSMTPProxies.vbs.txt

As I wanted to be very specific and meticulous in the removal of legacy proxy addresses I wrote another script that targets a specific SMTP domain. In this script you can specify the domain by changing the strSMTPDomain value. The script will then only export the names and addresses for proxies that match the SMTP domain. You can download the script here: SpecificSMTPProxies.vbs.txt

In my next post I’ll be using PutEx in a script to remove proxy addresses from AD objects.

I had a call from a user today who had forgotten her password to a couple of PST files. I was about to look at some commercial software when I came across this great process on Slipstick that will remove the password completely. The caveat is that it won’t work with Outlook 2003’s Unicode format PST.

http://www.slipstick.com/problems/lostpw.htm

This is fairly old news now but something I thought worth documenting as it affected our two BES installations.

Microsoft have changed the Full Mailbox Access permissions in Exchange so that it no longer implies Send As rights. Recent fixes for store.exe include this change. When applied it affects 3rd party applications like BlackBerry Enterprise Server which previously only used Full Mailbox Access rights for the application account.

You can avoid disruption by a small amount of preparation before applying the latest Exchange fixes. You’ll need to grant the BES admin account Send As rights on the Active Directory user accounts of your BB users. You could do this individually but it would be easier to do it at OU level. You’ll need to take into account the inheritance configuration on your OUs to decide the best location(s) to set the permissions. To see the Security tab on your OU properties you’ll need to enable the Advanced Features in Active Directory Users & Computers. This is done via the View menu:

When viewing the Security tab click the Advanced button. Now click the Add button to add your BES service account. You’ll be presented with a list of permissions. Change the drop down box to User Objects then tick Allow Send As. Once you’ve Ok’d back to ADUC your permissions will be set.

Any administrative users will need to be addressed separately. Administrative users include anyone who is a member of the following groups:

Enterprise Admins
Schema Admins
Domain Admins
Administrators
Cert Publishers
Backup Operators
Replicator Server Operators
Account Operators
Print Operators

It should be noted that it is good security practice not to have admin rights on your everyday mail-enabled account. 

To handle the administrative users the appropriate permissions need to be set on the AdminSDHolder container. The easiest way to do this is with the dsacls command. To use it you’ll need the Windows Server 2003 Support Tools installed. The syntax of the command is as follows:

Once all your permissions are set and verified you can go ahead and install the Exchange patches knowing that your BlackBerry users will continue to function as before. 

Technorati Tags: BlackBerry, BES

Having been recently taken over we’re now working on transitioning data and systems to the new company. As a result there are a large number of email redirections in place whilst the users and applications move across to the new organisation. The vast majority of redirections are handled in a controlled format using contacts in Active Directory and the delivery options on user objects. However, despite our best efforts we do suffer the occasional mail loop. This is usually when a user has set an OOF message on their mailboxes in both organisations and also set a rule to forward and auto-reply. (Note: We need auto-replies and OOF messages enabled between the two Exchange organisations). The detrimental effects are limited through the use of mailbox limits but that can still leave us with thousands of messages to clean up once the loop has been stopped. To help us with this task we use ExMerge.

Run the wizard and choose Extract or Import (Two Step Procedure). On the next screen choose Step 1: Extract data from an Exchange Server mailbox.

When you get to the Source Server screen enter the appropriate Exchange server name then hit the Options button:

 The first tab you want is Import Procedure and choose Achive data to target store. This option will extract the data from the mailbox rather than just copy it:

Next go to the Folders tab and restrict your export to the Inbox (if required):

Now you need the Message Details tab so that you can restrict your export to only the looped messages. In the example below I’m removing messages with "Out of Office" in the subject:

Now hit OK and complete the rest of the ExMerge wizard to select the mailboxes you want to extract from and the destination for the resulting PST. Double check the contents of the PST before you delete it!

Technorati Tags: ExMerge, Exchange 2003

We have a total of 4 Storage Area Networks attached to our primary Exchange clusters. We have 2 HP MSA 1000’s , an EMC CLARiiON CX300 and an EMC CLARiiON CX500. When designing our storage solutions I try to ensure a maximum database size of 50GB and leave twice that amount of free space so there is room for DB maintenance if necessary. I would normally put all databases for a storage group on a single RAID 1+0 array. This way there’s a little give and take with the DB sizes. For example if I planned to have 4 mailbox stores in a storage group I would make the partition at least 300GB (4 x 50Gb for stores + 2 x 50GB free space for maintenance).

Unfortunately I haven’t been as strict with our older hardware and have learnt an important "battlefield lesson" (thanks go to Gary for the post title). We have a server (an old HP ML570 ) that we have been using as a transitional area for mailboxes that we’re manually archiving. As it doesn’t normally contain much production data we’ve been a little lax with our housekeeping and have allowed the 2 stores to grow in excess of 90GB in size (although with plenty of white space) and allowed the free space to drop to around 15GB. We had a failed drive on the box at the weekend and the RAID controller didn’t do too good a job of keeping things going resulting in corrupted stores/logs. We mounted empty stores to allow the affected users to continue working but now have to copy almost 200GB of data across the network to attempt a repair or restore (I believe strongly in keeping an original intact copy of the corrupt DBs/logs when trying any repair procedure). We are running a restore using a recovery storage group on an alternative server but until we have a safe copy of the old DBs on another box we cannot risk deleting the originals to make room for merging the data back.

We’re out of empty drive bays and the server doesn’t support USB so for now we’re just waiting for the copy to complete. 24 hours and counting…

Technorati Tags: Exchange, SAN, storage

The company I work for has been bought by another and we are currently transitioning our IT systems. As part of this transition the users are being given mailboxes in the new organisation. Until the decommisioning of existing systems is complete some users have a need to access their original mailbox and public folders which they are achieving via Outlook Web Access.

The users working with public folders via OWA found that they could not reply or forward messages exceeding 2MB in size. A Google search returned this article which provided the solution.

On each front-end server the following registry entry needs to be created: 

Location: HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA
Value: maxPFReplyForwardSize
Type: REG_DWORD
Value Data: X

Where X is the maximum size you want to set in kilobytes (remembering to set the base to decimal).

Technorati Tags: Exchange 2003, OWA, Outlook Web Access

You Had Me At EHLO has the solution to an issue we experienced when installing some of our Exchange 12 boxes. We got round it at the time by using the RC1 Refresh version of MMC 3.0 but we’ll use the registry key and RTM version in future.

You Had Me At EHLO… : Resolving MMC 3.0 errors when installing Exchange 12 CTP release

I’m still trying to get my head around Exchange 12 mail flow and message routing but I’m sure it’ll become clearer once we get the servers up in the other sites. I’m hampered a little by the fact that this beta doesn’t have a GUI for configuring the bridgehead servers so I can’t have a nose around the settings.

From my understanding so far Exchange 12 is an Active Directory site aware application so it is very important that your Subnets and IP Site Links are correctly defined in AD Sites and Services. After checking available hardware in the various regions I’ve settled on 4 AD sites in the sandpit environment. These are Crawley (UK), Tampa (US), Santos (Brazil) and Montreal (Canada). The sites will be fully meshed with IP Site Links. To begin with the links will have uniform costs but at a later stage I’ll be investigating whether adjusting the values has any impact on mail routing within our organisation.

For the Crawley site we’ll have 4 servers initially. There will be a domain controller containing the global catalog, a mailbox server, a server with the bridgehead and client access roles and a gateway server. According to the release notes the gateway server role hasn’t completed the security pass. Therefore we’ll keep it on the internal network and route email to/from it via a Mailsweeper server in our DMZ.

I’ve placed a diagram of the Crawley topology below. Click on it for a larger version.

I’ll provide more information once the other sites are running and we’ve had a chance to experiment with connectors and mail routing. There’s no point me regurgitating the help files at this stage when I don’t have a decent understanding.

Technorati Tags: Exchange 12

Having had some time to review the Exchange 12 help files and documentation I’ve revised my infrastructure design slightly. In this post I’ll address server naming conventions and follow it with a post on my revised topology.

We use strict server naming conventions in our production environment and I’ve carried these through to our AD/Exchange 12 sandpit with some slight modifications.

I’m prefixing all server names with LAB. If for some reason they are picked up by one of our systems (e.g. LanDesk) it groups them together and makes it immediately obvious that they’re not production machines.

Next comes a three letter location code: MTL - Montreal, CRW - Crawley, TPA - Tampa etc.

That’s followed by EX. This makes it clear that they are Exchange servers and makes them easily identifiable to those who don’t work in the Messaging team and understand the role codes that follow.

Now we add a code that identifies the server’s primary role:

MB - mailbox server
BH - bridgehead server
CA - client access server
GW - gateway server
UM - unified messaging server

We might also use PF if the box was a dedicated public folder server.

Lastly we add a numeric increment to prevent duplicate names. We wouldn’t bother with this where you can only have one server of a particular role in a site e.g. SRS in Exchange 2003.
So the final server name would look like LABCRWEXMB2 or LABSYDEXUM1. We’re also using a similar convention for non-Exchange servers in our environment e.g. LABCRWDC1.

Technorati Tags: Exchange 12