OfficeTalk: From The Garage to Enterprise Ready


Published: May 2012

The following content may no longer reflect Microsoft’s current position or infrastructure. This content should be viewed as reference documentation only, to inform IT business decisions within your own company or organization.

Microsoft had a business need to provide a microblogging site so that employees could discuss sensitive company information. The project had an informal and small-scale start, but soon migrated into a secure and supportable enterprise solution.


Intended Audience Products & Technologies

Download Article, 172 KB, Microsoft Word file

This article is intended for enterprise executives, business decision makers, IT personnel, application developers and engineers.

  • Active Directory Domain Services
  • Microsoft Office
  • Windows Phone 7
  • Microsoft SharePoint MySites
  • Microsoft SQL Server
  • Microsoft System Center
  • Windows Azure


Microblogging is an informal communications and collaboration mechanism that many people use within online communities. At Microsoft, employees use it to share information with each other, comment on current affairs, talk about company-sponsored events, and hold ad-hoc business discussions. This enables them to mirror their personal style of communication by using external services.

However, Microsoft did not have an endorsed microblogging service that employees could use to discuss and share sensitive information without risk of exposing it to malicious users. Individuals in the Microsoft® Office product group identified a business need to develop a microblogging site through which employees could collaborate and communicate without inadvertently exposing data. These individuals decided to tackle the challenge of creating such a service, evolving it from a small grass-roots application enjoyed by a select few into an enterprise-wide product available to all Microsoft employees.

This article discusses the adjustments needed to move a service from an experimental project to a fully supported enterprise offering, by meeting several requirements that any production-ready IT enterprise service must, including:

  • Security
  • Monitoring
  • Support
  • Robustness


OfficeTalk is a proof-of-concept that explores the value of microblogging within Microsoft, and enables Microsoft IT (MSIT) and the Office group to understand scenarios that the microblogging platform produces, as well as gather data to help inform future Microsoft efforts focused on microblogging.

Initially, only personnel within the Office group used the initial version of OfficeTalk, as part of The Garage. This internal Microsoft grass-roots community, developed several years ago and open to any Microsoft employee, enables employees to cross organizational boundaries and utilize each other's experiences and expertise. The Garage provides a way in which engineers, designers, and developers can share tools and libraries to truly collaborate and innovate new applications and projects.

Initially, the OfficeTalk project was used within The Garage, but once the Office group recognized its value, it was deployed to larger groups of users.

The OfficeTalk Timeline

The Office group developed OfficeTalk in December 2008 as a prototype, and it continued as a small-scale project. In July 2009, it was formally launched to the Microsoft community, and then official was introduced as OfficeTalk in January 2010. In November 2010, MSIT assumed ownership of the project.

Initially, OfficeTalk was integrated with Microsoft SharePoint® MySites. MSIT completed the move to its server hardware in June 2011, in time for a series of high-profile company events that increased the user base and provided milestones for production testing. In August 2011, the Windows® Phone 7 client application, which is an important part of the OfficeTalk solution, and its associated infrastructure changes became available.

What is OfficeTalk?

OfficeTalk provides a scrolling interface, where employees can post ideas, links, and other data, as well as follow other employees’ posts. It’s similar to other popular microblogging walls, in which people update their location information, talk about what’s going on in their lives, and share pertinent information with those people who choose to follow them. Today’s technologically savvy users need little instruction on how to use OfficeTalk, as its boasts an intuitive interface reminiscent of Twitter, Facebook, and similar microblogging sites.

Solution Description

OfficeTalk has a typical Microsoft enterprise-application configuration that separates roles onto different servers and virtual machines. OfficeTalk utilizes Internet Information Services (IIS) 7.5 and Microsoft SQL Server® 2008 data management software. The web portions are hosted on clustered and load-balanced virtual machines that are running on Windows Server® 2008 R2, while the SQL Server is on dedicated hardware.

The software utilizes the Model View Controller (MVC) 3.0 framework and Java Script Option Notation (JSON) web services, with an exposed web-based application programming interface (API) that enables other platforms to interact with OfficeTalk. This functionality is exposed thru a user interface (UI) on the integrating web site, so that all users on the adopting website and on the main Microsoft feed can view and interact with OfficeTalk commentaries. MSIT established this UI on the enterprise’s internal search site, primary intranet portal (MSW), and ITWeb, among others.

OfficeTalk capitalizes on the offerings of Windows Azure™, an Internet-based cloud services environment that enables developers to create applications quickly and easily that will run in the cloud. Azure Access Control Service (ACS) provides integration to the corporate Secure Token Services (STS) for Windows Phone 7. All other authentication is performed in Active Directory® Domain Services (AD DS). The security model required changes to support availability in mobile scenarios and on the corporate network. The changes amounted to leveraging the corporate STS to provide a web-based authentication model, thereby eliminating a need for the client to contact AD DS directly. Web clients still use AD DS integration, and the Windows Phone 7 application uses ACS.

Additionally, the solution’s other specifics included:

  • Making URL names manageable: Web links are reported through uniform resource locator (URL) links. These can become very long and cumbersome for an end user to remember. However, the OfficeTalk URL shortener service truncates complex URL names into a manageable size, which reduces the characters necessary to embed them in a conversation. This prevents the user from exceeding character-length limitations that exist in the service. The OfficeTalk shortener service in runs on the front-end IIS servers.
  • Enabling employees to share images: The PIC (picture) service enables users to embed images into their conversations, and runs on the front-end IIS servers.
  • Enabling employees to search by keyword: OfficeTalk leverages the FAST Search for SharePoint service, which was left on the Office group's infrastructure due to downstream clients outside MSIT’s management.
  • Recommending those whom employees might be interesting in following: The Social Intranet Search Ranking (SISR) service performs the lookup for the recommendation of people to follow. This service also was left on the Office group's infrastructure due to downstream clients that MSIT wasn’t managing.

Migrating from The Garage to an Enterprise-Supported Platform

The initial project was implemented in a lab environment, and the core components were on a single-server configuration that minimized costs and implementation overhead. OfficeTalk was originally developed to work on the corporate Active Directory domain. The introduction of redundancy to the platform ensured a smooth migration as the application expanded to encompass the desire of employees to access it from multiple platforms, including the Internet and mobile phones. MSIT then reviewed performance by using the Microsoft System Center suite of tools, to ensure optimization of the solution without the need for additional code adjustments.

In the Garage implementation, OfficeTalk supported as many as 500 simultaneous users regularly. However, to become an enterprise-supported micro blog, it needed an adequate infrastructure to support approximately five times that number of simultaneous users. Additionally, MSIT had to ensure OfficeTalk access availability from a multitude of devices, including PC clients (strictly Windows clients) and Windows Phone 7 clients. The first step in migration to the enterprise was to segregate the OfficeTalk components so that it could be scaled and secured properly.

Multiple IIS servers on virtual machines were exposed to the Internet on a specialized network that MSIT uses to allow connectivity from both the Microsoft corporate network and the Internet. These servers were security hardened after a review uncovered several risks and blocking issues.

To minimize the exposure of OfficeTalk to unwanted traffic and to provide an additional layer of security, MSIT moved the SQL Server to a back-end network and added a second SQL Server to provide redundancy. The following graphic illustrates the high-level computing structure of the OfficeTalk solution:

Figure 1: General architecture of OfficeTalk
Figure 1: General architecture of OfficeTalk

Although the initial design of OfficeTalk was for access via web clients, MSIT had to migrate the service to a new infrastructure that was hosted in a production datacenter. This meant configuring network-specific security and host-level monitoring, and then onboarding the application to comply with Microsoft security standards.

Once MSIT deployed OfficeTalk, capacity became an immediate issue. MSIT testing revealed that the SQL Server was not sized sufficiently to handle the expected workload for a company event. The solution was for MSIT to migrate the server from a virtual machine to physical hardware. This enabled the service to meet estimated user loads. The IIS server topology included two virtual machines to provide redundancy and scale, and MSIT determined that it could meet increased capacity by adding more IIS servers.

Applying Service-Design Engineering Principles

During the migration process, MSIT applied Service Design Engineering concepts and requirements. Many of these were discussed as part of the migration efforts to maximize the service’s uptime, including:

  • Availability: Redundancy was an issue, so to make OfficeTalk highly available, MSIT installed redundant clustered IIS and mirrored SQL Servers to cover critical components.
  • Performance: The ability to estimate an expected number of active users on the system at any given time enables engineers to right-size the necessary hardware. MSIT discovered that to meet the expected OfficeTalk load, SQL Server needed additional capacity. Therefore, MSIT deployed the right-sized hardware, and was able to scale it to remediate IIS bottlenecks and meet demands.
  • Optimization: OfficeTalk had to run on servers built to MSIT standards for deployment in the corporate datacenter. This prevents many known issues from impacting the deployed service and other that are deployed in a given data center.
  • Security: During migration from The Garage to an enterprise-supported service, MSIT reviewed OfficeTalk regularly and updated it as necessary to meet corporate security requirements.
  • Configuration: MSIT implemented OfficeTalk in a low-complexity architecture, and used only what it needed to support the expected user loads. Additionally, MSIT was careful with its configuration to ensure that security services and the SQL Server configurations didn’t conflict.
  • Monitoring: MSIT applied basic service monitoring to OfficeTalk. The underlying infrastructure and critical operating services, such as SQL Server and IIS, have alerts in place for any service that impacts errors and warnings.
  • Business continuance and disaster recovery: Although OfficeTalk is not a mission-critical application, to prevent extended downtime should an outage occur, local disaster-recovery processes are key. MSIT configured and tested SQL Server mirroring and IIS clustering as part of the migration and deployment process.
  • Knowledge management: This is an area of focus for any team that is planning to migrate an informally developed project to an enterprise datacenter, and it posed a significant gap for OfficeTalk. Many people contributed to developing code for the project, on a volunteer basis, but did not document their processes. Therefore, a thorough documentation set was not available for the application.
  • Data life-cycle: Maintaining data on the service for a specified time helps to determine capacity and meet key legal requirements. Surfacing this requirement early allowed MSIT to right-size the hardware.

Testing Production Load at Scale

There were several key milestone events that MSIT used to test the service’s capability to handle larger and larger user loads. Currently the daily average user load is approximately 2,000 users, and those milestones enabled MSIT to gradually increase the load over time to that level, find bottlenecks, and establish stability for the production environment. The key milestone events for OfficeTalk included:

  • Microsoft Global Exchange (MGX): This event for the Microsoft sales force in mid-July 2011 served as the OfficeTalk trial run. Approximately 1,500 people used the OfficeTalk system, which enabled MSIT to review the production implementation, enact configuration and infrastructure mitigations, and assess the service’s scalability. This was done for web clients only, and during this assessment, MSIT determined that there was a limitation with leveraging an extra-large virtual machine as the backend SQL Server for OfficeTalk. MSIT then determined it could downsize to a production server and cluster it to provide failover.
  • TechReady: This event, also in July 2011, had the same number of users, allowing MSIT to test the fixes that it enacted from the MGX testing.
  • MSW integration: Pushing OfficeTalk to the MSW internal website, in August 2011, increased the average user load to 2,500 per day. This enables MSIT to test the scaling of OfficeTalk as well as its integration to other internal websites.
  • Microsoft company meeting. This meeting for all employees, in September 2011, was the acid test for the service, as the potential user load could have topped 20,000 people. The service had an average user load of 8,000 concurrent connections, and also expanded its user base with the addition of a Windows Phone 7 client for OfficeTalk. This client release accounted for 20 percent of the day’s overall traffic. MSIT was prepared with an additional staged IIS server, in case user load exceeded the capacity available on the production cluster’s two servers. The addition of that server mitigated all availability issues.

Lessons Learned

A production-ready enterprise service has to meet several milestones and requirements during its development, and OfficeTalk was no different. The key areas in which MSIT had to address requirements as it expanded the OfficeTalk server included:

  • Security
  • Monitoring
  • Support
  • Robustness

Maintaining Strict Security Standards

Security must be at the forefront of the design. In this case, there were components that were architected to support various security implementations of The Garage project. The entire application was designed and tested in a single Active Directory domain. However, when it came time to migrate OfficeTalk to the enterprise infrastructure, several use cases failed. This complicated the security strategy that was ultimately adopted.  If OfficeTalk had been designed from inception to incorporate Active Directory Federation Services (AD FS) or another security platform, deployment across the various security requirements and usage patterns would have been far less complex and time consuming. It is especially important to understand the impacts of infrastructure security in a production solution, from the physical topology to the policies and standards that an organization has in place.

Providing Successful Monitoring Capabilities

A successful implementation requires determining what type of monitoring is necessary. Actionable monitoring needs to be driven back to the product team from the project’s start. At Microsoft, OfficeTalk monitoring remains an open issue and needs to be defined for the specific event-log entries. Currently, MSIT is experiencing event-log flooding with unactionable alerts.

Key to ensuring successful monitoring is defining, measuring and implementing performance thresholds for the primary workflows. Pinpointing performance bottlenecks early and quickly also is imperative, as is identifying those key people who can anticipate blocking issues and how to mitigate them. That requires an understanding of an organization’s contacts, and their roles and responsibilities, so that these contacts can assist with accomplishing key tasks so bottlenecks are avoided.

Ensuring Future Supportability

How well an enterprise can support a service depends on the initial attention paid to those aspects that ensure future supportability, including:

  • Considering the broader architecture carefully. Temporary or short-term workarounds provide a quick fix, but can impact the service negatively in the long term.
  • Providing feedback to product-development teams to help improve other products. The experience gained from deploying a learning experiment to a production data center is invaluable.
  • Creating documentation for deployment and production support. Proper documentation allows a team to understand how to build the environment, what the critical events are in the system, and how to react to those events for a particular application. Documenting the efforts from the start will enable success in bringing the service to the enterprise. Documentation allows service-operations teams to learn the application errors and alerts prior to dealing with actual issues. There was no documentation for OfficeTalk when MSIT assumed its support. The engineers involved had to backtrack repeatedly to find the root cause of several security and usage issues. Clear, concise documentation would have saved time and effort.

Designing for Robustness and Expandability

Informal projects offer an enterprise’s development teams the opportunity to push the boundaries of what can be done within the framework of the products that they build every day. Additionally, it enables them to try out new technologies and implement existing technologies in new ways. However, even an informal project can grow quickly into an enterprise solution, so it’s important in a project’s early stages that attention is paid to ensuring that it is supportable, scalable, and secure. Partnering early with the support, operations, and infrastructure teams ensures that a service is robust enough to survive in the enterprise space. 

Most of the time, prototyping is done on the smallest possible scale that is cost effective. However, in the migration from prototype to a beta-user implementation, issues typically begin to surface. OfficeTalk initially was used at a very small scale. A single server implementation met the needs of the project team, and a SQL Server was required that had to be isolated from the web server to provide the necessary security layer. Separating out the web server allowed for addition of a clustered web farm.  To enable scale, all of the components that must cleanly communicate within one server need to have the ability to communicate across multiple servers.

Additionally, some other key points regarding robustness include:

  • Identify areas for leveraging and simplifying standardization.
  • Learn the process for implementing a service on internal and external networks. Know the requirements at the beginning, so there are no surprises.
  • Set the expectations on how to scale the service to meet the demands of an expanding user base.


OfficeTalk had humble beginnings, but quickly escalated into an expansive, enterprise-wide service. The deployed Office Talk platform allows for candid discussions among employees, without concern about inadvertently exposing intellectual property, such as product-development details, financial reporting, or market reactions to our products.

The adjustments necessary to migrate OfficeTalk to the enterprise had a number of complications, simply because it was not engineered initially to be enterprise ready. Enterprise readiness involves designing the service with core principles from inception to production release. That design must include early engagement allowing for reviews of the projected supportability, availability, scale, and security needs as it relates to corporate policy, guidelines and standards. Failing to do this can expose a data center and enterprise to unnecessary risk, extended time to market, and reduce quality of the overall service.

As the Microsoft employee base continues to grow, more and more users will avail themselves of the OfficeTalk microblogging experience. This ability to communicate and collaborate with fellow employees around the globe in a safe, secure platform ensures continued productivity and employee satisfaction. Additionally, it promotes creativity and originality as employees continue to design, develop, and test products for the world-wide market.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada Order Centre at (800) 933-4750. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information via the World Wide Web, go to:

© 2012 Microsoft Corporation. All rights reserved.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, Active Directory, Azure, Microsoft SharePoint, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.