Unified Communications

OCS follows Exchange into 64-bit-only land

Devin L. Ganger — Fri, 29 Aug 2008 20:07:05 GMT

You may have missed this interesting blog post this morning amidst all the political kerfuffle, so let me sum up: the next version of OCS will only support x64 platforms.

This isn't the big deal it would have been for OCS 2007. A lot of the initial FUD around the 64-bit-only move in Exchange 2007 turned out to be mere steam. While there were some initial challenges involved in managing the new 64-bit Exchange deployment from 32-bit machines, Microsoft got a lot of the licensing figured out and released the appropriate sets of tools to allow management of Exchange 2007 from both 32-bit and 64-bit environments. I fully expect that the OCS group has been paying close attention to all of this and taken good notes.

There's no denying that Exchange 2007 benefits from the "64-bit only in production" stance -- and with the release of Windows Server 2008 and Hyper-V, not to mention Microsoft's updated support statement for virtualization environments, the need for 32-bit environments is going away. My biggest reason for wanting 32-bit Exchange environments was so I could run demos under Virtual Server; now that I have Hyper-V, I'm probably not in any rush to go back to Virtual Server and the 32-bit limitation. 64-bit hardware is the norm today, and the x64 Windows variants are solid and mainstream enough for my dedicated application servers. (Maybe not so for the desktop quite yet, but still getting there rapidly.)

The one thing I'm skeptical about, though, is whether the move to 64-bits is really going to reduce the total number of servers in the deployment. In Exchange 2007, I only saw the server reductions in very large environments; the mailbox-per-server gains we got from 64-bits was offset by the explicit breakout of roles and the business needs that drove redundant configurations like CCR (which meant no co-locating roles with the Mailbox role) and multiple HT/CAS servers. I'm wondering how this is going to play out with the next version of OCS, where it already has so many distinct roles in play.

What I *hope* to see is that the maximum capacity of each server role (such as the number of users per pool or the number of streams per mediation server) can be driven upwards; this makes the large datacenter configuration options much more attractive, because it does translate to a reduced number of servers. However, for organizations that still have relatively low bandwidth separating their various locations, 64-bits won't do much to help; OCS deployment planning is very dependent on bandwidth, and is often the top limit on scalability long before the limits of the 32-bit Windows environment.

The OCS Edge Server: how many NICs do I need?

Devin L. Ganger — Thu, 14 Aug 2008 18:01:26 GMT

There are a lot of people out there who want to try to get around Microsoft's recommended configuration for the OCS Edge Server roles. For whatever reason, they don't like the thought of have two network interfaces, one on a publicly routable IP network, the other on the private network. I've talked in the past about some of the reasons why this configuration is not only recommended, but actually a good idea, but let's just say it took a lot of talking and thinking before I accepted that notion.

MVP Jeff Schertz has done a fantastic job of walking through the various permutations people have come up with, separating what will work from what won't, and explaining the pros and cons of each variant. I highly recommend this post.

I also want to amplify a point he makes: having multiple interfaces (whether physical or virtual) on the same subnet will cause interesting and otherwise inexplicable weirdness on a Windows machine. I'll write up the situation I'm seeing in a bit (not OCS!), but let me be clear: it's caused me all sorts of problems. Run, do not walk, away from any "solution" that requires this.

Updated Exchange Developer Roadmap

Devin L. Ganger — Tue, 17 Jun 2008 19:43:45 GMT

To reinforce yesterday's post about Exchange Web Services (EWS), I wanted to draw your attention to the Exchange Developer Roadmap posted on May 22 2008 on the Exchange API-spotting blog.

There shouldn't really be any surprises here, but there were a couple of items I wanted to highlight. First:

Given this commitment to Web services and our goal of making Exchange Web Services the richest developer interface for Exchange... (emphasis added)

Here's a preview of some of the functionality that we plan to add to the next release of Exchange Web Services:

Access to Folder Associated Items (FAI) and read/write access to user settings (Devin: this page in the MAPI reference indicates that FAIs are things like views and forms. I believe that this also fixes a known quirk of EWS that keeps you from creating Outlook-visible search folders that use certain property paths. I believe this also gives access to server-side rules, if they're not already accessible through a separate part of the API.)

Management of Personal Distribution Lists (Devin: very cool.)

Throttling capabilities that give Exchange administrators control over system resource consumption (Devin: this will be very nice for helping keep poorly written applications from taking down the Exchange servers.)

A powerful and easy-to-use server-to-server authentication model to enable building portals and enterprise mash-ups (Devin: let's hope this can ease some of the pain of building Exchange-aware SharePoint sites, at least those that don't require direct access to private mailbox content.)

An easy-to-use Microsoft .NET API that fully wraps the Web service calls, which makes Web service development even easier (Devin: I'll be interested in seeing how this stacks up against third-party offerings like the Independentsoft EWS client offering.)

Then they go on to list the APIs that will get removed (Exchange WebDAV, Store Events, CDO 3.0/CDOEx, and ExOLEDB) and moved to "extended support" (Exchange Server MAPI Client, CDO 1.2.1). Don't get too excited by the MAPI client -- it's not what you think:

Provides server applications a MAPI runtime for accessing Exchange.

Note: This is not the Outlook MAPI Client library that is included with Outlook.

and

Outlook's Exchange MAPI Store provider, available in the Outlook MAPI Client library can also be used to access an Exchange mailbox or public folder.

If you're going to start writing Exchange-aware applications, you should probably start looking at EWS first for future compatibility. If you're trying to support Exchange 2003 at the same time...good luck.

Doing UC in the Pacific Northwest

Devin L. Ganger — Tue, 06 May 2008 17:19:34 GMT

I've been sitting on a cool announcement for several days now, and I'm happy that it's now time to announce it.

I've been working with a group of people to get a new user group for Unified Communications (UC) put together here in the Pacific Northwest. While all of us are here in the Puget Sound area, our goal is to put in place a framework to empower a variety of events and meetings all throughout the region, not just based here in Seattle. Rather than be a typical boring user group with a jawbreaking acronym (PNWUCUG, which we do use), we're defining ourselves as people who do UC. This gives us a simpler name -- We do UC, hosted at ucdoers.org.

From our website:

We are the Pacific Northwest Unified Communications User Group (PNWUCUG) and we have a passion for UC. If you are one of the following, you could be one of us:

IT professionals in the Pacific Northwest who design, deploy, or manage Exchange Server, Live Communications Server, and Office Communications Server systems.
Developers who write or maintain solutions that integrate, extend, or provide UC capabilities to Exchange Server, Live Communications Server, and Office Communications Server and clients.
Industry experts with a recognized expertise in UC.
Hobbyists who are exploring Microsoft-based UC solutions.

One thing that's important for me to clarify -- my vision of this user group (which is echoed by the other folks who are getting it off the ground) is that it exists to support all Exchange, LCS, and OCS users, not just people running 2007 and doing the VoIP stuff. We may have a focus on UC, but that's mainly to align ourselves with the direction Microsoft is taking these products. If you're using Exchange, we want you to participate; we want to make sure we have content for you.

So, if this sounds like goodness to you, head on over to the blog for the announcement of our May 28th kick-off meeting at The Parlor Billiards & Spirits in Bellevue, WA. For those of you who can't be there in person, we're even going to have a Live Meeting feed for you -- how cool is that?

Setting Exchange 2007 Unified Messaging codecs on a per-user basis? Genius!

Devin L. Ganger — Wed, 23 Apr 2008 22:06:19 GMT

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:

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.
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.
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.

Security and the OCS 2007 A/V Edge role

Devin L. Ganger — Fri, 11 Apr 2008 18:33:42 GMT

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.

Exchange protocol documentation now available

Devin L. Ganger — Fri, 11 Apr 2008 02:21:31 GMT

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.

New form of spam

Devin L. Ganger — Sat, 01 Mar 2008 03:29:00 GMT

I came across an interesting article yesterday on a new form of spam: using webmail providers' Out-of-Office features to do a new type of backscatter spam. This is an excellent example of how unsecured messaging does not mix well with automated message generation capabilities. Any good Web developer can tell you that it's a bad decision to blindly accept and process untrusted input, and yet SMTP bots (that's what OOF functionality is at its core) do precisely that, thanks to the lack of a standard for verifying the authenticity of the sending identity and the integrity of the end-to-end message route. This is nothing new; this is the same variety of vulnerability that backscatter spam has been exploiting for years: target the NDR/bounce generation mechanism to do the dirty work for the spammers and send the paylod to the victim.

This new form of attack just underscores my growing conviction that our current system of email is going to be gradually supplanted by a variety of mechanisms for communicating with people outside of our organizations. There's too big of a disconnect between “enterprise” features that business want from email and the inherent limitations of the current store-and-forward mechanism SMTP is built upon. And no, I'm not one of those people who thinks that pay-per-email schemes are the answer; what works well for physical, tangible products becomes quickly unworkable for virtual communications.

I don't think there's going to be One True Successor for SMTP, nor do I see SMTP going completely away any time soon (just as Usenet, despite all predictions, still manages to hang on for certain applications and communities). Dependable synchronous communications modes such as instant messaging, voice, and video will, I think, begin taking up a lot more of the message trafrfic currently carried by email. By avoiding store-and-forward asynchronous mechanisms, you reduce the opportunities that attackers and spammers have to forge and inject illegitimate communications into your users' workspaces. Allowing users to decide which communications mode is best for them helps alleviate the pressure on email systems.

Webcast on Unified Communications

Devin L. Ganger — Wed, 13 Feb 2008 23:02:00 GMT

Tomorrow I'm going to be giving two webcasts for Quest on What You Need to Know about Microsoft Unified Communications -- one at 9am EDT, the other at 2pm EDT. (Yes, that's 6am and 11am here, so my morning tomorrow is going to start earlier than normal.) This is going to be a fun, high-level overview of the UC initiative -- it won't be a deep technical dive. Instead, we're going to look at the implications of deploying the Microsoft UC platform for the IT professional. If you have time to join one of the sessions, I'd love to see you!

Liveblogging the Unified Communications Voice Ignite conference, day 5

Devin L. Ganger — Fri, 08 Feb 2008 01:25:00 GMT

Day Five of Devin's notes from the UC Voice Ignite event in Sydney, Australia.