Site Sections
Posts
254
Comments
120
Trackbacks
120
April 2008 Entries
Greetings from Orlando!

I'm posting from a break between sessions at Exchange Connections in Orlando, FL. I just had a good session on protecting Exchange with DPM -- thanks to everyone who attended and gave lots of good feedback.

Next up -- a session on DCAR with Exchange, and then Exchange 2007 update best practices.

The weather is actually the best I've ever seen here -- not too hot, with a nice breeze, so the humidity isn't overwhelming. However, the A/C is up full in the room I'm presenting, so I'm glad the speaker shirts are long-sleeved.

More later!

posted @ Monday, April 28, 2008 6:53 AM | Feedback (0)
Setting Exchange 2007 Unified Messaging codecs on a per-user basis? Genius!

I was completely floored to discover, via Paul, that you can control which codec the UM role uses to record voicemails on a per-user basis. This is seriously cool stuff, and if you can't see why quite yet, let me offer the following scenarios for you:

  1. Most common: you have multiple users who have non-Windows Mobile devices that don't support the WMA codec, but still want to be able to listen to their voicemail on their devices. The GSM and G.711 PCM Linear codecs may be more widely supported. For example, on an EAS-aware iPhone will Apple also roll in support for recognizing UM voicemails? If they do, will they support the WMA codec? Now, in theory, they don't have to.
  2. Also common: you have multiple users who use a non-Windows based client. (Paul already calls out one example, those of us who use Entourage.) This would be just as valuable, though, for people who are using some IMAP or POP3 client on a Linux/BSD/Solaris box.
  3. Not so common, but possible: you have a specific need to automatically process voicemails in an automated fashion and need to use either the GSM or G.711 PCM linear codecs instead of being able to support WMA. Switching one or two mailboxes over keeps the entire Exchange storage system from suffering the increase in voicemail file size that would result.

Okay, so these are slightly lame scenarios, but I'm sure there's more out there that I can't see.

posted @ Wednesday, April 23, 2008 3:06 PM | Feedback (1)
Security and the OCS 2007 A/V Edge role

When people start digging into the specifics of the A/V Edge role in OCS 2007, they usually have a strong and immediate knee-jerk reaction something along the lines of, "No way!" (Mine was, "Oh, heck no!") This reaction is usually caused by learning one or more of the following deployment requirements:

  • Public IP address. The A/V Edge server needs to have a publicly routable IP address. This address must be publicly routable; you can't fudge it by giving it an IP address in a private range (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) and do any sort of NAT to it. 1:1 NAT or static NAT mapping won't do the trick here. You can and should have a firewall between it and the Internet, but it can't be doing any address translation.
  • Dual-homed. The A/V Edge server cannot be separated from the internal OCS servers by NAT. Therefore, if you're using a private address range and NAT in your internal network, you have to give the A/V Edge server a second network interface and IP address on routable, non-NAT address range. (Note, however, it doesn't have to be the same address range as the internal network, simply on an address range that is directly routable without NAT.)
  • 20,0002 external ports. The external (publicly routable) interface needs to have the following ports opened to the Internet: UDP 3478, TCP 443, UDP 50,000-59,999, and TCP 50,000-59,999. Security people immediately look at the need to have 10,000 dynamic TCP ports and 10,000 dynamic UDP ports and have their head asplode in sheer instinctive security reaction.

I've personally reacted to all three of these requirements; I've yet to talk to a security-conscious IT professional new to OCS who hasn't. So what on Earth is Microsoft doing putting these requirements in place? Have they completely lost it about security?

In a word, no.

There are good reasons why these requirements are in place. Rather than go over them myself, however, let me simply direct you to this excellent post on the OCS team blog. If you have any questions, post them there and tell 'em I sent you. Note that to post questions on their blog, you need to first join their Community Server site. This is painless and easy; simply click the Join link in the upper right-hand corner, pick a username and password, provide your email address, and you're ready to go.

posted @ Friday, April 11, 2008 11:33 AM | Feedback (0)
Exchange protocol documentation now available

Per the announcement on Tuesday (08 Apr), Microsoft has released a lot of new documentation for various Exchange and Outlook-Exchange protocols. This is some cool stuff -- just check out the list of what's available. However, as the web site warns, it's preliminary documentation. If you don't believe them, when you download the files (available in PDF format) the big fat "PRELIMINARY" watermark (in very bold font) will help remind you.[1]

I can already hear some of you out there: "So Microsoft released documentation on obscure or unimportant Exchange protocols. Big deal. I bet they've saved all the good stuff for licensing!" Well, I'm not going to deny that this is a complete set of documentation for every Exchange protocol you might ever want to know about -- after all, Microsoft is a company who believes in the value of intellectual property. They've kinda built a business plan around it, and it's both foolish and naive to somehow assume that they're just going to toss all of that overboard overnight. It's not even reasonable to expect them to completely abandon that position; it's an arguable proposition that Open Source principles work best in conjunction with an IP scheme that permits open licensing when the developers feel invested in doing so, alongside more restrictive licensing schemes. But that's a religious argument for another day.

This will be a long post. I'm going to split it into three sections: Appetizers, Main Course, and What's Missing.

Section 1: Appetizers

First, we have some housekeeping and overview documents and protocols:

Name Description
MS-CAB Cabinet File Format
MS-MCI MCI Compression and Decompression
MS-OXDOCO Outlook-Exchange Protocol Document Roadmap
MS-OXGLOS Office Exchange Protocols Master Glossary
MS-OXPROTO Office Exchange Protocols Overview
MS-OXREF Office Exchange Protocols Master Reference
MS-PATCH LZX DELTA Compression and Decompression

You may have noticed that these documents include a few things that aren't strictly Exchange or Outlook-specific, such as the CAB file format and various compression protocols. Just remember that the Exchange protocol documentation is part of a wider set of Interoperability Principles, and so it depends on technologies that are part of the more generic set of Windows technologies.

Section 2: Main Course

Okay, with roadmaps and preliminaries out of the way, let's take a look at the meat:

Name Description
MS-NSPI Name Service Provider Interface (NSPI) Protocol Specification
MS-OXABREF Address Book Name Service Provider Interface (NSPI) Referral Protocol Specification
MS-OXBBODY Best Body Retrieval Protocol Specification
MS-OXCDATA Data Structures Protocol Specification
MS-OXCETF Enriched Text Format (ETF) Message Body Conversion Protocol Specification
MS-OXCFOLD Folder Object Protocol Specification
MS-OXCFXICS Bulk Data Transfer Protocol Specification
MS-OXCICAL iCalendar to Appointment Object Conversion Protocol Specification
MS-OXCMAIL RFC2822 and MIME to E-mail Object Conversion Protocol Specification
MS-OXCMSG Message and Attachment Object Protocol Specification
MS-OXCNOTIF Core Notifications Protocol Specification
MS-OXCPERM Exchange Access and Operation Permissions Specification
MS-OXCPRPT Property and Stream Object Protocol Specification
MS-OXCROPS Remote Operations (ROP) List and Encoding Protocol Specification
MS-OXCRPC Wire Format Protocol Specification
MS-OXCSPAM Spam Confidence Level, Allow and Block Lists Protocol Specification
MS-OXCSTOR Store Object Protocol Specification
MS-OXCSYNC Mailbox Synchronization Protocol Specification
MS-OXCTABL Table Object Protocol Specification
MS-OXDISCO Autodiscover HTTP Service Protocol Specification
MS-OXDSCLI Autodiscover Publishing and Lookup Protocol Specification
MS-OXIMAP4 Internet Message Access Protocol Version 4 (IMAP4) Extensions Specification
MS-OXLDAP Lightweight Directory Access Protocol (LDAP) Version 3 Extensions Specification
MS-OXMSG .MSG File Format Specification
MS-OXMVMBX Mailbox Migration Protocol Specification
MS-OXOAB Offline Address Book (OAB) Format and Schema Protocol Specification
MS-OXOABK Address Book Object Protocol Specification
MS-OXOABKT Address Book User Interface Templates Protocol Specification
MS-OXOCAL Appointment and Meeting Object Protocol Specification
MS-OXOCFG Configuration Information Protocol Specification
MS-OXOCNTC Contact Object Protocol Specification
MS-OXODLGT Delegate Access Configuration Protocol Specification
MS-OXODOC Document Object Protocol Specification
MS-OXOFLAG Informational Flagging Protocol Specification
MS-OXOJRNL Journal Object Protocol Specification
MS-OXOMSG E-mail Object Protocol Specification
MS-OXONOTE Note Object Protocol Specification
MS-OXOPFFB Public Folder Based Free/Busy Protocol Specification
MS-OXOPOST Post Object Protocol Specification
MS-OXORMDR Reminder Settings Protocol Specification
MS-OXORMMS Rights-Managed E-mail Object Protocol Specification
MS-OXORSS RSS Object Protocol Specification
MS-OXORULE E-mail Rules Protocol Specification
MS-OXOSFLD Special Folders Protocol Specification
MS-OXOSMIME S/MIME E-mail Object Protocol Specification
MS-OXOSMMS SMS and MMS Object Protocol Specification
MS-OXOSRCH Search Folder List Configuration Protocol Specification
MS-OXOTASK Task-Related Objects Protocol Specification
MS-OXOUM Voice Mail and Fax Objects Protocol Specification
MS-OXPFOAB Offline Address Book (OAB) Public Folder Retrieval Protocol Specification
MS-OXPHISH Phishing Warning Protocol Specification
MS-OXPOP3 Post Office Protocol Version 3 (POP3) Extensions Specification
MS-OXPROPS Office Exchange Protocols Master Property List Specification
MS-OXPSVAL E-mail Postmark Validation Protocol Specification
MS-OXRTFCP Rich Text Format (RTF) Compression Protocol Specification
MS-OXRTFEX Rich Text Format (RTF) Extensions Specification
MS-OXSHARE Sharing Message Object Protocol Specification
MS-OXSMTP Simple Mail Transfer Protocol (STMP) Mail Submission Extensions Specification
MS-OXTNEF Transport Neutral Encapsulation Format (TNEF) Protocol Specification
MS-OXWAVLS Availability Web Service Protocol Specification
MS-OXWOAB Offline Address Book (OAB) Retrieval Protocol Specification
MS-OXWOOF Out of Office (OOF) Web Service Protocol Specification
MS-OXWUMS Voice Mail Settings Web Service Protocol Specification
MS-XJRNL Journal Record Message Format Protocol Specification
MS-XLOGIN SMTP Protocol AUTH LOGIN Extension Specification
MS-XWDVSEC Web Distributed Authoring and Versioning (WebDAV) Protocol Security Descriptor Extensions Specification

On first glance, that's an impressive list. NSPIs, S/MIME, SMTP and POP3 extensions, RTF extensions, TNEF -- the list goes on. There's a lot of seriously crunchy material here. The question of the moment, though, is "just how detailed is all this documentation?"

Good question.

I haven't had time to look through it all in a lot of detail. To be honest, I suspect that a lot of it is in areas that I wouldn't be able to catch any glaring omissions or discrepancies (sorry, readers, I'm just not up on the latest specs for RTF). However, I did take a quick look through MS-XLOGIN, "SMTP Protocol AUTH LOGIN Extension Specification"[2], since I'm reasonably familiar with SMTP.

Let me skip to the chase: yup, this is preliminary work. On whole, it does a good job of documenting the flow of the LOGIN extension (which people have already mostly figured out how it works through years of careful protocol analysis). The most complicated part of it is that you're using Base64 to encode the credentials being passed -- not rocket science. However, there are some gaps in this straightforward documentation:

  • Nowhere did I find any guidance on what the user and passwords challenges are supposed to be computed on (only that they are to be Base64 encoded). This makes it more difficult to properly code a LOGIN implementation.
  • The samples they gave look like valid Base64, but according to my quick conversion tests in PowerShell, they aren't. I can't get any of the sample values to match what they should. Again, this means I can't work backwards to get the missing data.

I really hope this is the kind of stuff they're going to fix between this release and the final release, because without it, this documentation isn't nearly as useful as it could be. Some would even accuse it of being provided merely to give the appearance of interoperability while still keeping enough implementation details close to the chest to keep it from really happening. I, however, subscribe to the philosophy that one should never initially ascribe to malice what can be explained through other possibilities -- and I've done enough work on these sorts of projects to know that getting the right level of detail in a document like this is far from a no-brainer, especially if you're dealing with contractors or are having to generate the documentation after the fact. (I don't know that either of these possibilities are involved, but I'm guessing.)

Section 3: What's Missing

There are three obvious protocols missing in all of the above: MAPI, MAPI over RPC over HTTP, and Exchange ActiveSync. I can hear the screams now...but this is where I go back to the point that Microsoft still makes money from intellectual property. Microsoft's Web site offers a searchable IP Catalog that shows you exactly which protocols they offer for a licensing fee, and both MAPI (aka the Outlook Exchange Transport Protocol) and Exchange ActiveSync are on it, as well as several other important protocols for Unified Communications. Microsoft is under no obligation to make every single protocol available for free -- but the fact that they're finding value in doing it with the above protocols is pretty cool and interesting. [3]

[1] If the watermark bugs you, try seeing if your PDF client will allow you to view or print the document without annotations. Using Foxit Reader, I was able to make the watermark go away and actually read some of the text it obscured.

[2] SMTP Protocol? Seriously? Is that like PIN number or ATM machine? Attention, Microsoft technical writers: P stands for Protocol.

[3] You're free to speculate on what value they get, but not here, please. That's another religious discussion.

posted @ Thursday, April 10, 2008 7:21 PM | Feedback (2)
News

Devin has moved on
to new adventures.
This blog is preserved
for historical purposes.

Please follow his
personal blog at:
Devin on Earth

Virtual Devin
Article Categories
Archives
Post Categories
Data Protection
DCAR
Exchange
Other
Security
Unified Communications
Windows