-
There’s an interesting thread going on inside Microsoft about what are the cool and innovative things we have done as a company over the last decade. I think about this quite a bit as well. Working inside Microsoft you see both sides of this discussion. On the one hand, you can look around inside Microsoft and see absolutely phenomenal innovation taking place in virtually every group across the company. On the other hand, you see how rarely that gets recognized outside of the company. I personally think that is partly because we sometimes make the mistake of focusing on technology rather than the core problem and so non-technophiles don’t get what’s so cool about we have delivered. But we are also getting much better at what I call sub derma innovation. That is innovation that lies below the surface. Put another way, we innovate by making really complex problems look easy. And in that light, it’s easy again for non-technophiles to miss the great work that has happened and think “What’s so innovative about X? It’s just this simple thing…”.
But I do believe we have done some remarkable things that most folks would realize as innovative whether you like the product or not and even if you may not know all the hard problems under the cover that had to be solved to make it a reality. Some of my favorites are:
- OneNote – I don’t know how I lived without this before. It transforms ordinary conversations or thoughts into action
- PowerShell – Pure light and goodness :-) It makes me yearn to be a programmer again
- Xbox – Yeah, you could look at this and say it was just another gaming console with different hardware, but that misses what Xbox Live brought to the table as well. No one has come close to duplicating this online experience.
- Windows 7 – I’m cheating since it is only in Beta, but even at Beta, it is the best OS I have ever used.
- OCS – clearly I am biased and time will tell if I’m way off base. Not everyone will use the product in the same way that I do, but I have finally gotten rid of my business phone
What would be on your list?
-
Our virtual launch is coming very soon, but I thought I would share some tidbits of information that you should know about OCS 2007 R2. Just something to whet your appetite …
10. 64-bit
We’ve made the switch to 64-bit at last. Industry trends all point to this being the right time to make such a switch. The cost and availability of 64-bit hardware is unbelievable. In just the short time between the release of OCS 2007 and the release of R2, hardware has grown by leaps and bounds. We wanted to take advantage of that hardware and the only way to truly unlock it’s potential was to go native 64-bit. This is not just a recompile. There are significant changes involved. For this and many other reasons, we have decided to bid farewell to the 32-bit server.
9. Windows Server 2008
Customers demanded it and we have delivered – R2 has been re-designed to work effectively on Windows Server 2008. This is also not just a simple recompile. This means leveraging things like the improved (default) firewall in Windows Server 2008, IIS 7.0, EEC certificates, and much more.
8. Consolidation
In OCS 2007, we had two different options for deploying our Enterprise Edition: consolidated and expanded. Consolidated was simple to deploy because every server was running all the services (instant messaging, presence, conferencing, and voice). But it was limited in scale at the time (30,000 concurrent users per pool) and so our largest customers would deploy expanded instead. Expanded meant we took the resource intensive workloads (mainly web conferencing and audio/video) and offloaded them to dedicated servers.
Moving to 64-bit meant we could take advantage of the natural improvements in hardware and suddenly we could have the best of both worlds: easy to manage and scalable. We now recommend consolidated configuration for all deployments and we have the scale to match: 100,000 concurrent users per pool. (Or 200,000 if all you need is IM and presence)
But we didn’t stop at the core server roles. We also consolidated the Edge Server role so that there is now a single server role to deploy and you deploy multiple instances for scale.
7. No More DNAT
We use load-balancers to effectively scale out deployments and most load balancers support two different modes of operation. Load balancers inherently implement a network address translation (NAT) function as they attempt to make a single virtual IP address distribute across multiple physical servers. There are two obvious ways to do NAT: based on the destination address/port (DNAT) or based on the source address/port (SNAT). In OCS 2007, we supported either mode. In R2, we no longer support DNAT.
Why? Because DNAT has some peculiarities when one of those physical OCS servers behind the load balancer wants to communicate with different OCS server in the same pool and wants to load balance that communication as well. There’s no good way to make this work with DNAT. With SNAT, this works just fine. What’s the impact to you if you have already deployed? A simple re-configuration of your load balancer. No change in functionality or scale.
6. System vs. Config
We leverage Active Directory extensively. This comes directly from our vision statement where we believe a single identity is the core of any UC system. For Microsoft, that single identity comes from Active Directory. AD is effectively a smart, replicated, database. There is a lot of information stored in Active Directory in general and so this replication can be network intensive. For most deployments, this is a complete non-issue. However, for very broadly distributed global deployments, the network connectivity between all sites is not always reliable. The good news is that AD has a solution for this type of situation. It involves putting your application settings into a different container (config) than the normal default (system). The benefit of doing this is that you have a local copy of the config information that is available even when network connectivity between sites is down.
In previous releases, we gave you the option of using either (System or Config) but defaulted to System. That made sense for typically centralized IM and presence deployments. It makes less sense for global, typically de-centralized voice deployments. Our recommendation (and default) moving forward is the Config container. If you have already deployed using the System container, don’t worry. We have a tool to help you with the migration. What you should know is that you need to do this migration BEFORE you attempt to deploy R2.
5. Improved Updates
We’ve made some significant improvements in the way we handle updates to the clients and devices in R2. In OCS 2007, we introduced the Update Server role which allowed you to keep your desktop phone and RoundTable device software up-to-date. With R2, we now allow you to do the same with the Office Communicator desktop software as well. What’s more we’ve addressed most of the shortcomings of the previous implementation including:
- No more Sharepoint dependency (this stuff works out of the box)
- Fully authenticated downloads
- Better support for remote phones outside the firewall
- Support for cross-language updates (go from English to French, for example)
4. RDP-based Application Sharing
Ever use Remote Desktop or Terminal Server to access a remote machine? Works pretty well, right? Well now we use the same technology for application sharing in our product. It’s so good I forget I’m even using it. This is really fast, high fidelity, silky smooth application sharing – the way it’s meant to be. And it works in a web browser… on a Mac… from anywhere.
3. Dial-In Conferencing
You use them all the time. Audio Bridges are a natural way people work nowadays. Only now you no longer need to buy a separate bridge or pay per month or per minute. The nice thing is that this is fully integrated with the rest of the UC solution. You don’t have to worry about forgetting your PIN or remembering what your special meeting ID was meant to be. And you have complete control over who can join which calls – something that is hard to impossible to do in other systems. More on this to come …
2. Group Chat
We acquired a company called Parlano over a year ago. Since then, we have been busy integrating this world-class group chat product into our overall UC solution. With the release of R2, we are proud to announce the first Microsoft release of the new group chat functionality. Why is this important? Because IM has become mission critical at many companies but they aren’t tapping the full value of those IM conversations. With group chat, you get an indexed archive of these group collaboration sessions which you can search at any time. The institutional knowledge that was once lost can now be preserved and leveraged.
1. We’re Not Done Yet
We are still busy putting the finishing touches on things like SDKs, localizing into more languages, improving the planning tools, building the best documentation ever, and some pleasant surprises which I can’t discuss (yet). I will share more as these pieces fall into place over the next few months. There are some really exciting announcements coming at launch.
-
Yeah, what he said: http://radar.oreilly.com/2008/12/hard-work-and-practice-in-programming.html
One thing to add is this is not learning by rote. This is discovery and creation that only surfaces through practice. The same applies equally to being a program manager. There is no substitute for practice (and by extension, experience). I need to go practice now.
Technorati Tags:
PM,
Microsoft
-
Like most of the country, the Pacific Northwest is seeing a bit more snow than usual. In Redmond, we fear snow. For the greater part of the year we have very moderate weather and so most folks here don’t know how to drive on snow and ice. Today is particularly bad because the quantity of snow makes driving a Herculean task even for those accustomed to it.
I’d guess that at least 20,000 of the 30,000+ folks who work at Microsoft in Redmond are working from home today and that is an unexpected challenge for our VPN servers not to mention the local DSL/cable networks. Things are slower than usual but still working. If you can avoid doing a VPN connection, it’s a wise idea.
Here comes the obligatory plug for OCS ;-) I’m not using VPN for the most part. I don’t need it for Outlook and can do e-mail, share files, schedule meetings, etc. just fine. I don’t need it for OC and so I’ve been in meetings all day long using VoIP and application sharing in our soon-to-be-released R2 product. Alas there are some internal tools and web sites which I can’t completely avoid and so I dip my toes into the VPN waters occasionally. What I’m finding though is that set is shrinking over time.
Working remotely is becoming a more frequent occurrence for me (aside from the odd weather around here) and I’ve become addicted to this flexibility. I’ve done IM from Maui, international calls from San Francisco, working meetings in my PJs, and even full day workshops remotely. It’s not a perfect experience, but what I miss most are things we are actively working on. Next time I get snowed in, I will probably enjoy it ;-)
Technorati Tags:
UC,
VoIP,
OCS
-
In two weeks, VoiceCon San Francisco will kick off. After our announcement of Office Communications Server 2007 R2 at the VoiceCon event in Amsterdam, I'm expecting quite a bit of excitement and questions about our upcoming release. Microsoft will have a strong presence at the event as always and I myself will have a chance to attend and be part of a panel discussion around "Leveraging VoIP Investments for Unified Communications". Unfortunately my schedule only allows me to be there for a day since my day job (shipping R2) keeps me busy. Please swing by the Microsoft booth if you have a chance and drop me an e-mail if you will be there on Wednesday.
-
Shameless plug :-) We're looking for a rockstar PowerShell program manager to join the team here in Redmond. Got what it takes or know someone who does? Shoot me an e-mail: sean dot olson at microsoft dot com
UPDATE: Thanks for all the references I have received. I've found my rockstar PM :)
-
At last we are free to start blogging about our upcoming R2 release of OCS 2007. We've made a formal announcement at VoiceCon Amsterdam and the lid is off on this release which we've been cooking for over a year now. I'm especially proud of the customer focused nature of this release. There is not an ounce of fat in the release. No superfluous features, no pet projects, no easter eggs ;-) Seriously, every last piece of this release has come from detailed and repeated feedback from our customers. 64-bit support, Windows Server 2008 support, PSTN bridging, Boss/Admin support, and much much more. This is our best release to date. And this couldn't come at a better time. As folks are starting to tighten their belt during these tough times, OCS 2007 R2 offers some tremendous cost savings. Our own internal deployment of R2 is going to save us million$ just with the PSTN bridging feature. That is some awesome ROI. Beats my 401(K) for sure ... I'll be posting a ton of more stuff about R2 in the coming days.
-
I've attended just about all of the major voice related conferences in our industry to date but of late it seems like the buzz that drew so many to VoIP and SIP in the "early" days is starting to wane as the industry matures and SIP is no longer a question but an assumption. So I'm quite intrigued to see what eComm can become. I've read some very favorable comments about the inaugural event in 2008. I'm now blocking off my calendar to attend next year's event. Like Microsoft's own Interact event, this sophomore effort is not one to miss. Ping me if you plan on attending as well. Would be great to meet as many folks as possible there.
-
Perhaps I'm getting spoiled, but I've gotten used to some basic features in any application I used nowadays and I'm really surprised by any new application that doesn't have these:
- Automatic, in-place upgrades: why make the user work so hard to see your hard work?
- Dock to systray: no app is so important that I shouldn't be able to get some screen real estate back when I need it
- E-mail invitations: if I'm excited about your app, make it easy for me to share that excitement
- Roam my data: preferences, settings, etc. I have more than one machine. So do a lot of folks. Make it easy to keep those in sync
- Connect to my data: don't make me re-enter stuff that's already in obvious places like Facebook, Yahoo/GMail/Hotmail, etc. If I have to build one more list of "friends" ...
- Don't ever ever lose my data: wow, this still happens waay too often
-
The role of program manager at Microsoft is unique. I say that because very few external candidates who interview at Microsoft have done the job of a PM and quite a few have never heard of it before. I also say this because if you ask ten different PMs at Microsoft to define what it is a PM does, you will likely get ten different answers (and they are all right). My favorite definition goes something like this: there are three classic roles at Microsoft that do product development. You have the developers who write the code. You have the testers who ensure that code is correct. And you have PMs who don't write code or test it. Seriously though, I can provide some basic statement that PMs formulate plans and execute them but that just isn't a satisfying answer for many.
You can imagine then how difficult it can be to train PMs or learn to become one yourself. I haven't found anything more effective than try, fail, learn, repeat. But you can arm yourself with some basic knowledge to make the failures softer and the learning more productive. I thought I would share my favorite reading material that I consider essential for any PM. This started as an e-mail I was going to send my team internally but then I thought why not share this with the world ;-)
The Art of Project Management, by Scott Berkun
This one is a no brainer. Written by a former and very successful Microsoft program manager, it's the PM 101 primer. I don't agree 100% with everything in it, but there is more to learn than to discount in this book. I actually hand most new PMs a copy of this to start. Thank you Mr. Berkun.
A Whole New Mind, by Dan Pink
nosce te ipsum. There are a whole class of books out there that fit this mould and this is just a great example of the genre. Know Thyself. Self-awareness is a critical skill for any PM and this book does a great job revealing a whole different side of us. Also check out Blink
The Ten Faces of Innovation, by Thomas Kelley
IDEO wrote the book (literally) on innovation. I enjoy all of his books, but this is the most directly actionable one that I have read so far. Ideas are easy; innovation is tough. We like to go big at Microsoft and this book has some great tips for going beyond the ordinary.
Presentation Zen, by Garr Reynolds
As a PM, you do a lot of PowerPoint presentations, most of them poorly. Read the book to understand why.
The Design of Everyday Things, by Don Norman
Bad design is easy, commonplace, and unnecessary. This is a very quick introduction to a rich and complex topic, but hopefully it puts you in the right frame of mind at least.
Rebel Without a Crew, by Robert Rodriguez
Some people use the word "passion" almost casually. To be successful at anything (including a PM), you should have an appreciation for what passion is really about. This book is as good an explanation as I have found.
-
Awesome. Twitter meets INSTEON in the strangest combination of technology to-date. Check out the particulars here: http://www.vimeo.com/1025711?pg=embed&sec=1025711
If you thought that was strange, check out this: SIP for Light Bulbs Using SIP to Support Communication with Networked
I have to admit, I'm pretty intrigued myself about the possibilities especially if you were brave enough to publish your Twitter account for this.
-
Great set of videos on how folks use their Chumby over at YouTube. I'm still working out how to hack together a simple intercom system using my Chumby and Windows Live Messenger. In the meantime, I'm going to use a text based system via Twitter. Very easy to do and amazingly useful. In a nutshell, my chumby is a alternate sidebar display which I can stream just about anything to and I don't have to have my laptop nearby.
-
Recovering from a hard drive crash tells you a lot about yourself. What do you backup? What do you miss? And what can't you live without as you start to re-create your digital life (or laptop)? I at least had advanced warning from the intermittent BSODs that usually occurred during a critical e-mail writing storm. Rising from the ashes looked something like the following for me:
- Replace hard drive (good first step, right?)
- Install Vista Enterprise SP1 from the network (PXE)
- Plug-in ethernet cable (wireless not working yet...)
- Join myself to the corporate domain
- Reboot
- Add myself to the local administrator's group
- Install ISA Firewall Client from Intranet
- Auto-Enroll for wireless certificate
- Wireless is now working and I can un-tether myself again
- Install Office 2007 (gotta get that e-mail working again)
- Autoconfigure Outlook .... ready to start downloading several GB of e-mail
- Install FolderShare (the absolute easiest way to recover all the files I have backed up on my other machines)... 10 minutes later, I'm functional again
- Now time to install those other applications you can't live without
- Install Office Communicator so people realize I'm back in action
- Install VPN client
- Install Adobe Reader
- Install Adobe Flash
- Install Adobe AIR, so I can ...
- Install Twhirl
- Install Silverlight
- Install PowerShell (passionate hobby ;-)
- Install Zune (not critical, but I much prefer this to WMP)
- Install Windows Live Writer (how else would I write this?)
Done. I'm probably overlooking some things, but so far I haven't missed them.
-
It's that time of year already when thousands flock to sunny Orlando to experience VoiceCon. Last year, I got to see the world's largest phone:
Kinda silly when you think about it but you can't help but stop and stare. Stop by the Microsoft booth to see some really interesting phones (in a more convenient size). In addition to cruising the conference floor and hearing some great presentations and keynotes, I'll be sitting on a panel on Wednesday talking about SIP standards and interoperability:
To what extent is SIP viable -- or required -- when deploying a converged, multivendor IP communications network? To help you answer that question, Ed Mier, a leading independent expert on SIP will give you a detailed report on SIP interoperability, based on the latest annual survey of SIP-supporting vendors: How many and which features interoperate, where interoperability still falls short, and where we stand with SIP "extensions." He'll discuss his conclusions with a panel of vendor representatives and the audience.
KEY QUESTIONS
Which traditional voice features can be supported with approved SIP-standard specifications? What features can't? - To what extent do SIP elements from different vendors truly interoperate? Are the newer SIP-based systems backward-compatible with earlier products that were based on proprietary protocols?
- In which areas of the network are SIP implementations most likely not to interoperate?
- What sorts of features are being implemented as SIP extensions, and why?
- Will SIP extensions always be with us, or will most if not all features become standardized over time?
Speaker - Ed Mier, CEO, MierConsulting, LLC
Panelist - Tony Rybczynski, Strategic Enterprise Tech, Nortel
Panelist - M Raza, Product Management, 3Com
Panelist - Sean Olson, Principal Group Program Manager, Microsoft
Panelist - Paul McMillan, Director UC Strategy, Siemens Communications
If you like what you hear and want to learn more, please stop by and see me. Or check out our new interoperability site.
-
I worked on Unix systems for probably close to a decade before coming to work at Microsoft. The common denominator among them all was that the command line was way more interesting than whatever GUI they might provide (the two exceptions being the NeXT cube and SGI's IRIX which were years ahead of their time). My perspective was a bit biased being a programmer since scripting at the command line brought me an efficiency and range of functionality that could not be met with any point and click GUI. Simply put, it was way cooler to get things done with the command line than any pretty boy UI. For these reasons, I became acquainted with dozens of command line scripting options and expert in more than a few.
Bourne Shell and all its brethren are where it started for me: ksh, sh, Bash, zsh, etc. Writing scripts that could work on a variety of systems to automate a bunch of manual tasks. In that environment you don't learn one tool, you have to learn several to get anything useful done: grep, awk, sed, ps, kill, ls, sort, uniq, count, more, etc. You master the syntax of the input/output of each of these commands as well as the format of all the useful files. The mantra that everything is a file in Unix serves you well as long as you (a) know where that file is and (b) know the structure of the file.
This was tedious but it worked. The tedium came from learning a bunch of tools and how to string them together as well as how to work around the idiosyncrasies of these tools on all the different flavors of *nix. Then came the most wonderful invention: Perl. Hard to believe that it has been twenty years already! Perl was wonderful because it replaced all those tools and gave you a consistent regex notation for parsing all those text files. Perl 4 still sets the bar for maximum functionality in minimal lines of code. Perl 5 raised the bar by creating a vast library of re-usable modules to handle all those common administrative tasks and more. No more re-inventing the wheel over and over again.
Perl has an elegance to it once you grok the syntax. You can work some real magic with Perl hash tables and dynamic evaluation. Perl is never going to win any beauty prizes though. For some folks, it's just not their cup of tea. Python could be viewed as an alternative to Perl for those who prefer a more "pure" scripting language. I first came into contact with Python while working at NASA. There are some incredibly brilliant Python folks there. I love the way Python handles objects (though my favorite is the original prototype concept in JavaScript). Python too has a vast library of re-usable modules. Some would argue that the way Python handles libraries is cleaner than Perl but they both get the job done.
Fast forward to when I joined Microsoft six years ago. Love the interface of Windows compared to X Windows, but when it came to command line scripting, it was like going back to the dark ages. Not a big fan of cmd.exe or the WSH but it does get the job done. Partly because of past history I turned to ActivePerl to fill my scripting needs on the Windows platform. It's an awesome product but using Perl on Windows always leaves you feeling like something is missing. Part of the problem is that everything is not a file on Windows. Management in Windows means understanding other things like WMI, Active Directory, COM, etc. The other part of the problem is that Windows fundamentally handles file paths differently and it can be a hard transition from using Perl on Unix to using Perl on Windows. Using the command line in Windows was definitely not cool.
This all changes with PowerShell. I was skeptical at first. Could Microsoft really create something that could compete with Perl or Python and fill this aching gap in their command line story? I think the PowerShell folks have done just that. They've borrowed a lot of the great concepts from those languages while introducing some novel concepts of their own. First off, I can do things in PowerShell with about the same number of lines of code I would use in Perl. Secondly, I can leverage the entire functionality of the .NET framework. Re-read that again. I can't overstate the importance of this piece. No more re-inventing the wheel here. There is a ton of functionality in those libraries that you can use directly in PowerShell without having to learn any new syntax. For example, retrieving a file from a remote HTTP server is trivial and you don't have to know anything about HTTP. Third, PowerShell is built for Windows by folks who really understand Windows. All that WMI, AD, LDAP, and XML that is a routine part of managing a Windows system is easily accessible from within PowerShell. And I've never seen an easier way to access COM objects from a scripting language. Finally, you have to try the object-based pipeline in PowerShell to fully appreciate what this means in terms of power and efficiency. Simply put, you don't have to spend all your time parsing text anymore. You think in objects and not regular expressions. Beautiful.
This leads me to an obvious topic: when will Office Communications Server offer PowerShell as a command-line scripting interface? Like many Microsoft enterprise products, OCS 2007 today offers WMI as the primary scripting interface for the product. Combined with WSH, you can get most things done via a command line. But it's no PowerShell. The roadmap we have for offering PowerShell consists of two phases. In the first phase, you can use PowerShell's native ability to work with WMI to access all of that functionality. We have a good proof-of-concept for this in the CD that accompanies the Microsoft Office Communications Server 2007 Resource Kit. Longer term, we are going to offer a native PowerShell interface similar to what is available with Exchange 2007. To do this right takes time. We want to provide an object model and corresponding PowerShell cmdlets that maps well to the product and provides an interface that will be useful for years to come. This means rethinking our entire WMI interface as it stands today and coming up with something better. As we make progress on what that new interface will look like, I will post more information and solicit your feedback.
The command line is cool again, especially on Windows, and I can't wait to show you what comes next...