Devin on Earth

Just 2 days left — on with Thursday! (You can see my day 3 notes here.)

09:57: The RTAudio codec suite is pretty cool. Finally found out why there’s all those new devices (like USB headsets) that are marked as Microsoft UC-compatible. Regular low-end devices are used to dealing with the G711 codecs which sample at 8KHz; many of them can’t support sampling at the 16KHz rate that the RTAudio wideband codec variants (there are 6) support. The updated equipment specifically is tested to give the full fidelity when using the wideband RTAudio variants. (source http://www.microsoft.com/downloads/details.aspx?familyid=05625AF1-3444-4E67-9557-3FD5AF9AE8D1&displaylang=en and http://www.microsoft.com/downloads/details.aspx?FamilyID=5D79B584-79C9-42A8-90C4-4AB3F03D19C4&displaylang=en)

10:12: Ooh! Microsoft has a freely downloadable Deployment Validation Tool for OCS.

12:31: Going back to the reverse proxy issue I talked about in 15:44 on Day 3, you can get detailed guidance on configuring ISA Server 2006. (source http://technet.microsoft.com/en-us/library/bb663639.aspx)

12:35: Yes, Virginia, the A/V Edge server external IP address must be a publicly routable address. It can’t be behind NAT (not even 1:1 NAT, also known as Static NAT, bi-directional NAT mapping, or any of a number of othre terms). Is this just another stupid “Microsoft doesn’t get security” stunt of years gone by? Nope — this requirement is there because you absolutely have to have a publicly routable address somewhere in the equation in order to allow NAT traversal for all the other clients. OCS’s A/V Edge NAT traversal functionality is based on the STUN standard, which was developed under IETF guidance through a multi-vendor working group including Microsoft and Cisco. (source http://tools.ietf.org/html/rfc3489, especially the last paragraph of section 6, http://www.voip-info.org/wiki-ICE, and http://technet.microsoft.com/en-us/library/bb870364.aspx)

16:05: Had a nice series of crunchy labs. Yum! Before that, though, a couple of key Exchange Unified Messaging/OCS interoperability points. You should have one Exchange UM SIP URI dial plan for each OCS location profile — they have a 1:1 correspondence. You may also have additional Exchange UM TEL URI dial plans if you’re in PBX co-existence mode; those dial plans are for the PBXs, not for OCS. (source http://technet.microsoft.com/en-us/library/bb803653.aspx)

Continue on to my Day 5 notes.

I’ve noticed something for a while now — people are really reluctant to install a proper PKI system. If you’re a Windows-based organization, I have three words for you:

Get over it.

The Windows Certificate Service (WCS) is powerful and fairly easy to manage — and it’s included in Windows Server Standard or Enterprise versions.

For years, people have been complaining about the lack of security in various products. Well, Microsoft and other vendors have listened, and standards like TLS and Mutual TLS are now getting put into most of the new products and versions rolling out the door. However, in order to USE these standards and get the security, you must have certificates. You can spend a lot of money buying and installing and managing these certificates from third-party vendors or you can install WCS.

The most common objection I hear is, “But I can just use commercial certificates!“ True, you can. But now you’re paying for every certificate and adding to the complexity of your deployment tasks. Rolling out Exchange 2007 or OCS 2007 with all the proper certificates is a lot easier when your servers have an internal WCS infrastructure to talk to — requests are fulfilled almost immediately. You don’t have to spend money on all those internal server certificates — just the external-facing certs for machines that are talking to external clients or mobile devices.

Either way you choose to go, there are a few facts of life:

• You WILL need to take time to learn how certificates and requests actually work. Knowing why you want to keep secure exported copies of certificates with their private keys associated is a good thing.
• You WILL have to allocate time managing your certificates and infrastructure. Commercial certificates expire — we at 3Sharp had a certificate expiration sneak up on us and disable OWA and EAS until we got it sorted out.
• You WILL have to worry about certificate backups and processes. See the point about exported certificates.

Okay, here’s a question — would there be any interest in having me do a series of blog posts on the basics of certificate handling? I know there’s good material out there, so I’d focus my stuff on common tasks and gotchas I’ve run across when deploying certificates for Exchange and OCS. If that sounds like something you’d want to see, drop me a comment.