It’s 2006, and we’ve been busy since the holidays gearing up for Beta 2.  One of the internal milestones we have for that release is getting Microsoft up and running on Groove 12.  The Microsoft internal deployment of Groove is up to over 8000 active users since we started the rollout last May.  The user base was mostly created by word of mouth as we wanted to wait to do a big push until we had Groove 12 available.  In addition to the ad hoc users of Groove, one of the IT groups supporting the sales force wrote a custom solution using Groove 3.1 to manage sales efforts for folks in the field.
 
Our initial deployment followed what we think is a typical model for Groove, at least historically.  Initially, we had a number of internal users who where were running in the ‘unmanaged’ environment hosted on groove.net, either using a trial version or a full version that they’d purchased prior to the acquisition and our subsequent internal deployment.  Our first step was to create a ‘Microsoft’ domain using the hosted Groove service so that we’d be able to quickly set appropriate policies (security policies, in particular) and get people migrated onto that managed domain prior to deploying the server infrastructure internally.  In parallel we set up a registration portal where interested people could request a Groove license and account, and then MSIT would issue those accounts and give people instructions for where to install the software and how to get configured.
 
At the same time MSIT started the process of planning for an internally hosted Groove environment:  capacity planning, ordering hardware, work orders to get the machines installed, etc.  One of the key benefits of moving to an internally managed environment was the ability to have user identity information automatically synchronized with AD so that there wouldn’t be a manual step of managing contact information.  In September, the production environment went ‘live’ and we migrated people from the hosted domain to the internally hosted and managed one.  Interest in Groove has continued to grow, really without any internal marketing or any attempt to make it something available via SMS push or a standard desktop image.
 
As we get ready for Beta 2 of Office 12, we’re starting a series of efforts to get the MSFT users running Groove 12 Beta 1.  There are two parts to the migration.  The first is deploying the Beta 1 client to the internal users of Groove 3.1.  In addition to the client upgrades, we also need to plan the migration to the Groove 12 infrastructure.  The first step in that process happened last week as we deployed what we’re calling the ‘Groove Dogfood’ environment in Redmond.  The product groups at Microsoft have a long tradition of using our software while it’s under development and Groove is no different.  We’re setting up two parallel environments for Groove—the first is our production domain, currently running Groove 3.1.  The new domain is running the Groove 12 servers (management and relay) and is targeted at the Office engineering teams for their daily use.  We use this as a staging ground prior to rolling into production, so that we can identify issues before the software becomes part of the broader deployment in the production environment.  We’ve use a similar approach for Exchange, so from an IT perspective we’ve tried to keep the same model.
 
The migration from ‘production’ to ‘dogfood’ has started for a pilot group, but we’re finding it a slow uptake, consistent with the experience we had when we did the initial migration from the hosted environment to running our own Groove infrastructure.  Based on that initial migration we started thinking about ways that we could help smooth enterprise deployments, which we think will follow the same model that MSFT used, and tried to look at what was making it difficult for customers to get up and running or stay up and running with Groove. 
 
Probably the biggest challenge with the way Microsoft deployed initially is that we require user interaction to complete the configuration steps, whether that’s getting up and running for the first time with Groove or responding to a change in the environment that dictates a migration from one management domain to another.  Groove does have a facility for ‘auto-activiation’ which we did not deploy initially in the production environment; we will be deploying this feature in the new dogfood domain for new users and eventually (with Groove 12 Beta 2) in the main production domain.
 
What happens with auto-activation is that Groove detects (using a reg key) on initial startup that it’s part of a managed environment and queries the Groove management server for the account information based on the Windows credentials of the current user.  The Groove management server is already provisioned with user data through directory sync, so it passes the account information to the client and Groove finishes the configuration automatically.  This works great for that initial installation.
 
One gap in the 3.1 management server is that this process doesn’t work if the same user tries to run Groove on a second machine, so they are forced down the route of saving their Groove account from their first machine and importing on the second.  In Groove 12 we’re going to change this so that a user can auto-activate as many times as needed, whether that’s due to adding a new machine or a disaster recovery scenario where their machine was reformatted.  Due to the need for authentication, this auto-activation feature will only be available when the management server is running within the organization infrastructure (where it has directory sync access) and not when running on a hosted Groove domain.
 
This leaves the issue of domain migration, a step today which is always manual, and if not done carefully, can result in a user accidentally creating a second identity within their account, rather than merging the new domain information into their existing account and pushing that update out to all of their contacts.  We’re working on a design for migration that will also enable it to be more automatic and controlled by the admin, so that essentially a migration happens as an action between the management servers responsible for the two Groove domains, rather than something that requires user participation.
 
For those of you reading this, we’re interested in your feedback on the current deployment challenges with Groove and any feedback you have on places where you think the process could be streamlined.  You can respond via comments to this blog, or email the Groove Feature Suggestion alias, grvwish@microsoft.com.