Tangential Thinking

Dedicated Fax Numbers

Providing the connected PBX supports it, users can have more than one UM number, the first attached to their DDI and another for dedicated direct-fax. This may be necessary when migrating from a fax platform such as RightFax or may just be desirable when introducing UM.

On the Mitel environments our means of implementing this proved to be slightly hacktastic,using hunt groups with permanent forwards set as UM requires calls to arrive at the UM number via a forward. The Exchange 2007 GUI didn’t support adding additional extensions, instead we achieved this via powershell using the enable-ummailbox cmdlet, making this something which is preferrably done at initial provisioning. Additional numbers are provided after the first, separated by commas.

Adding a dedicated UM number which doesn’t first ring an extension has an added benefit to your organisation – corporate mobiles can be diverted to these numbers instead of the normal operator voicemail, further unifying lines of communication and helping your staff remain available to customers.

Having deployed one of the first Unified Messaging enabled sites in the UK I’ve had plenty of time to tinker with UM and discover some undocumented ‘features’ and workarounds to common requests.

Out of Office Autoresponses and UM

This one is mostly a matter of user education. Simply put whatever your users call their contacts is presented back to their contacts in situations where a UM enabled user defines both telephony and email contact details and an OOF event occurs with UM.

For example, Bob Davis a hypothetical user has Clive Green defined in his exchange contacts as: “Green, Clive (pest)” .

While OOF (with autoresponse enabled) Clive calls Bob and leaves him voicemail. Exchange upon delivery of Clives voicemail to Bob will email Clive Bobs autoresponse and in doing so expose the name Bob has given Clive. Bad juju.

One of the nicest features of my iPhone remains the mail sync capabilities. I’m a heavy email user and sync several accounts which include MobileMe and Exchange. This unfortunately means I also have first-hand experience of just how hard that hits the puny 3G battery roll on the iPhone released next summer!

Anyhow, Apple aren’t known for their openness when it comes to disclosing the finer points of their updates, so it’s no suprise there are some undocumented changes in iPhone 3.1 which are causing a range of pains for iPhone/3G/3GS users.

It turns out that until 3.1, the implementation of Exchange ActiveSync in 3.1 was fairly weak from a security perspective. Organisations which are using Exchange 2007 and have device policies set couldn’t properly block handsets which didn’t have a pin code set or encryption enabled.

So for users of the original iPhone and 3G as of 3.1 if your firm uses such policies you’re stuck between a rock and a hard place – unless they relax the Exchange ActiveSync policy associated with your exchange account (preferrably creating a new policy which is applied specifically to those with affected devices) your syncing days are over.

Users with the 3GS will either be prompted to use a PIN (or error out if one isn’t used, I don’t recall which) and find that encryption is enforced (if policy dictates).

Of course this is really an internal IS problem, after all nobody would connect their personal telephone to the corporate messaging infrastructure, right?

As I mentioned in an earlier post, I was recently caught out deploying a new organisation running Server 2008 R2. As our only DCs were R2 boxes we opted to run our AD at that functional level only to find that the latest Exchange 2007 packages (SP2) were incompatible.

Microsoft have now posted updates to the BPA files which will allow installation with this configuration, the english versions to which are linked below:

ExBPA.Prereqs.XML
ExBPA.Readiness.XML

To use the above just right click and ’save target as’ as the links are to the xml files themselves unpackaged which will otherwise be rendered by your browser. Then all you need to do is drop them in to the Setup\ServerRoles\Common\<language> of your installation directory – those installing from the DVD media will need to copy the DVD to local storage on the machine so they can drop the files in and make use of the fix.

Other language versions and more information is available here.

… a word of warning. Well several in fact.

Historically the release process for Service Packs from Microsoft has a pretty good track record. Occasionally one small irritating bug might make it out (Server 2000 SP6 anyone?) but for the most part the quality is high, any major issues which are uncovered prior to RTW will trigger a delay for a fix, (as occured with SP1 with E2007 when issues were found in particularly large trial environments).

Unfortunately today I’ve come across a blocking issue in deploying Exchange 2007 with SP2.

In short:

Exchange 2007 SP2 is currently incompatible with Active Directory  running at 2008 R2 functional mode

Or, to be more specific, if you only DCs are 2008 R2 and 2003 pre-SP1, or 2008 R2 only at its highest mode you’re currently unable to install the latest release of exchange.

The response from Microsoft thus far is quite weak, I’ve chatted with several people who have responded to say that a fix will follow when R2 is “widely available” which to say the least is is nice and vague.

Which leaves two options, fix the prereq xml that BPA queries by hand, or go 2010 RC. Neither of which are exactly supportable. Sigh.