Saturday, May 31, 2008

MDM and WM 6.1 Articles

How on earth did I forget to blog about this?

Those great guys at PocketPC mag published my article on MDM in the current edition. There's also a nice article by my colleague, Chris De Herrera, on WM 6.1

Worth checking out.

WM 6.1:

Interesting product dev

Looks like moves are afoot to tie the Zune (note: a very bad word in Hebrew - in with WM. Good move.

Oh, the 'good move' is tying it in with WM, which makes a lot of sense, and not the amusement derived from accidentally offending potential Israeli buyers.

All unconfirmed stuff, but don't be surprised when it happens. BTW I don't have any inside info on this; this is all stuff I gleaned from conversations and a brief googling - oops, I mean Live Search - session.

Links here: and a pretty picture here: Hey! That looks just like an iPho^h^h^h^h zune!

Friday, May 30, 2008

New MDM articles posted on Technet

The whitepapers “Integrating Mobile Device Manager with Microsoft Exchange Server” and “Configuring External and Internal Firewalls in Mobile Device Manager” are now live and posted to TechNet:

More coming soon. Stay tuned.

Tuesday, May 20, 2008

Links to docs

There's a slew of really good documentation (I know they're really good because I wrote some of them, plus I've worked really closely with the doc team on much of this content ) on MDM now available on Technet.

This should be your starting point for everything MDM. MS have done a great job of putting together very relevant material.

More coming soon, including a series of 5 Integration Guides, all of which should be available at the link below by the time Tech Ed rolls around:
- Exchange
- Firewalls
- Global Deployments.

Link here:

Monday, May 19, 2008

Cool Outlook (2007) Add-ins

Hot on the heels of Xobni (, which has now gone from beta/invite only to general release, comes GigaOM. Very cool, very useful.

Monday, May 5, 2008

To NAT or not to NAT

It's coming to be pretty much understood now that you can't put the MDM Gateway on a NAT'd IP address. The reason why is that it 'breaks' the Alerter service, and thus the Wipe Now capability is lost.

In reality, it's acting as designed; the client will check the source address of an alerter message and if the source IP address has changed (as it must, when NAT is used) will failsafe and presume that the originator cannot be trusted and thus will drop the packets.

It looks like things aren't working, when in fact they're working exactly as they're supposed to, with Security first and foremost.

Inconvenient, perhaps, but well thought-through and well implemented.

Bear in mind that "Wipe on Next Connect" is not impacted here since the device will re-connect to the DM on whatever schedule the admin has defined (default is 8 hrs) and then will accept and process the Wipe command.
One suggested workaround is to use the Exchange device wipe capabilities instead, since there is a high probability that waiting until the next connection is unacceptable and the device really does need to be blown out of the water sooner rather than later.

Actually, the risk of waiting until next connect is that the target device can be connected and accessing your LoB hosts as normal. The 'next connect' refers explicitly to the device checking in with the DM to see if there are any packages, policies or commands waiting for it. In the meantime it's business as usual.
Can definitely see that being unacceptable for a lot of folks.

Thursday, May 1, 2008

PKI Legerdemain

Legerdemain is French and literally means "lightness of hands". In English we usually translate it as 'sleight of hand' and it speaks to the actions of a magician when he makes that coin appear from behind our ear, or magically picks the one card out of 52 that we'd glibely selected from the pack.

The subject of PKI and MDM comes up a lot. Customers approach it with trepidation - and who can blame them, since we're talking about something that was designed by committee?

I'm very much a proponent of MS PKI, but I can say that because I've been in places and positions most people haven't. I've worked with brilliant PKI people who were only too happy to share their knowledge with me. In my former life as a Security Conslutant with Moldevort, Incorporated [1,2], I got to design and implement enterprise-wide PKI's and have seen how well they can work. But I'm the exception and not the rule.

The subject of this post refers to legerdemain because MS has done a very clever act of legerdemain; in bundling their PKI offering into the base server license it makes it almost look like you're getting a free lunch, but as we all know there's no such thing.

That not withstanding, products like OCS and now MDM rely very heavily on this technology - the subtle but important difference between the two is that MS backed off on pushing the MS PKI route for OCS and you can very easily implement OCS using a 3rd party offering. Not so MDM - sure, there's a compromise solution in place in that by design it (the MS PKI) functions wonderfully as a subordinate of an existing Public Key Infrastructure, but the reality is that for MDM to work you must have a Microsoft Enterprise Certificate Authority in place or it won't work, period (or 'full stop').

So, now we have MDM wrapped up into the PKI bundle. It must use the MS PKI for reasons I'll go into in my Tech Ed session in June, but what does this really mean? Just how difficult is it to implement PKI in the enterprise? Is it really that difficult? Or does paranoia abound?

Questions, questions, questions...

I'm going to give this some thought, do some research, and post a series out here on my spin on how to approach it.

The beauty of not working for Microsoft and not posting stuff like this on the Enterprise Mobile blog is that anything that may prove to be crap comes down on my head alone and doesn't reflect on anyone else. I'm cool with that. There's a reason why I found a pair of asbestos y-fronts under the tree this past Christmas .

Stay tuned.

[1] Otherwise known as 'they who shall not be named'
[2] The Spoonerism was unintentional but works quite well, I think.