Microsoft Builds a Seamless Wireless Network Experience for Employees and Visitors Alike
Technical Case Study
Published October 2013
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.
By embracing consumerization of IT as a core business principle, Microsoft has enabled employees and visitors to access the company's corporate network by using the devices that they prefer. The solution reduces network maintenance costs and improves user productivity, without sacrificing the security and performance of the IT environment.
Products & Technologies
Microsoft IT sought to enable an easier Internet access experience for users with mobile devices that would improve overall corporate network security while reducing support costs.
Microsoft deployed a wireless virtual network to which non-domain joined devices (such as guest user laptops, employee’s smartphones, and tablets) could easily connect, providing all users with seamless Internet access completely isolated from corporate traffic.
Networks at Microsoft provide connectivity for more than 400,000 employees, vendors, partners, customers, and guests who need controlled access to a multitude of applications and services, both internally and externally. This connectivity accounts for perhaps three-quarters of a million servers, desktops, laptops, notebooks, smartphones, tablets, and embedded devices on Microsoft premises around the world.
Many of these systems, such as servers and test computers, may not need Internet access. But the growing number of portable devices on Microsoft campuses depend on it, demanding a simplified, high-performance Internet access experience that meets security standards.
The IT industry reached a tipping point in 2012 when the sales of new wireless consumer portable devices (generally used alongside corporate-issued assets such as domain-member laptops) began overtaking the hardwired systems that came before. And as device adoption rates likewise rose across Microsoft, existing wireless network and security infrastructure became insufficient to meet the needs of an increasingly mobile-enabled user population. Moreover, employees were using their own smartphones for corporate data access, introducing further stresses on Microsoft Information Technology's (Microsoft IT's) security practices by mixing consumer services and devices with enterprise systems and policies.
This problem also extended to the many visiting partners and vendors on Microsoft campuses every day. There were more individuals with myriad personal devices who needed Internet access, including unmanaged laptops (that is, laptops that are not domain members). Microsoft IT wanted increased control over network traffic segregation, bandwidth utilization, quality of service, information security, and user support for the thousands of new devices that joined the network each week. The solution would need to address both the nascent security concerns over the emerging Bring Your Own Device (BYOD) trend and provide a consistent, multiplatform capability for all users.
A Shift in Vision
Microsoft leadership wanted to provide seamless Internet connection experiences for employees and visitors alike. Their hypothesis was that a more open approach to network management could foster increased productivity by enabling a more flexible work style, and could both reduce costs and increase overall efficiency.
A core tenet of the broader IT industry's efforts around consumerization of IT is that individuals can be more productive if they can work on the devices that they know and love. On these devices, consumer services and technologies mix with enterprise applications and data for improved usability, access, and innovation.
Although the goal was to streamline the way users gain access for both business and personal tasks, it was equally important to maintain corporate network integrity in the process. This meant moving less secure personal devices off the internal network and onto an alternate service.
Understanding the Problem
Previous mechanisms for Internet access via the corporate network placed operational burdens on end users. Connecting a wireless device required a selection of domain credentials, one-time passwords, machine certificates, wireless local area network (LAN) configuration, or other security settings to be managed. In addition, Microsoft IT had been maintaining multiple networks and administrative functions in order to separate public traffic from sensitive internal traffic. This practice also had the effect of increasing overall IT management and support costs.
Providing all users with consistent, simplified, and security-enhanced wireless Internet access would require Microsoft IT to move beyond the traditional definition of a corporate network. It would require Microsoft IT to instead embrace a more open model that reflected the rapid adoption of consumerization of IT across the company.
Deploying a new network that would bridge the gaps between current infrastructure and cellular plans would have addressed the problem temporarily. But in the long term, that solution would only serve to duplicate hardware, increase costs, and create more complexity. Contrarily, consolidating Internet access for all users by using existing infrastructure created a series of challenges that would have different impacts in different regions across the globe. This is particularly true between such diverse security requirements as internal versus external traffic.
Table 1 lists the core requirements that Microsoft IT needed to meet while providing Internet access to mobile wireless devices.
Table 1. Business needs.
Corporate network security
Maintain complete isolation of sensitive corporate traffic and help protect company infrastructure from malware and exploits.
Assure vendors, partners, and customers that their network traffic meets standards for safety and security.
Adhere to both US and international standards that guide the company's use of personally identifiable information or other data.
Acceptable use policies
Place safeguards to help ensure that inappropriate or unauthorized content does not enter the corporate network.
Apply governance to Microsoft intellectual property contained in digital stores, on the network, or in use.
Improve operations and reduce costs while enhancing the Internet access experience for every end user.
Address multiple use cases across multiple geographies, including languages and local compliance regulations.
Among the various security and regulatory/privacy requirements, Microsoft IT identified technical challenges to supporting a broad range of users, devices, applications, and identities within its own network environment. In addition, Microsoft IT sought to deliver a tool-style mechanism for unmanaged devices that enabled an extremely simple, automated connection process.
The group began by conducting user surveys across the company to determine device, application, and network usage patterns, along with user preferences. Understanding these metrics would provide valuable insights into how and why employees and visitors connected to Microsoft network resources through unmanaged devices. Figure 1 shows the survey results indicating users’ ranking of how important certain scenarios are on mobile devices. [Scores are based on number of respondents marking each task as either “Very Important” or “Important”.]
Figure 1. Results of user surveys.
The survey's questions revealed a few important demographics about employee work style, as shown in Table 2.
Table 2. Survey analysis.
|Focus Area||Survey Findings|
|What devices are being used for work and Internet access?||Employees reported that 31% of devices in use are mobile phones, 30% are laptops, 23% are tablets, and 15% are desktops.|
|What are these companion devices used for?||The dominant tasks performed are Internet access, email, and viewing Microsoft Office documents and PDF files.|
|Which is the preferred mobile device per application?||On phones, users consume content
and perform routine tasks.|
Tablets are used for a blend of creating and consuming content, and carrying out more complex tasks (in applications and on the Web).
Laptops are multi-function, used to create and consume content and to conduct complex activities.
|How do users connect their devices?||Wi-Fi is used for tablets, while
phones use cellular data plans.|
Laptops use Wi-Fi/virtual private network (VPN)
Microsoft IT outlined several core scenarios in order to fully describe the primary use cases, based on the device type (phone, tablet, laptop), user (employee, guest, contractor/vendor), ownership (Microsoft, employee, guest, vendor), domain status (member or not), applications (email, documents, corporate intranet, Internet), and desired use (Internet-only versus corporate access).
Employees and vendors at Microsoft need similar levels of application access from all device types (either company owned or user owned), whether on the corporate network or via an outside Internet connection. The survey also showed that users whose tablets are connected to the corporate network expect to spend more time using the device for work tasks. Guests (who use their own devices), on the other hand, need only Internet access while visiting.
Considering these constraints and analyses, management identified the following use cases for a wireless network infrastructure that would simplify access for internal and external users alike:
- Employees—access to the corporate network and the Internet
- Personal phones, tablets, and laptops (multiple hardware platforms and operating system versions, not domain members) that need Internet access
- Company-owned tablets and laptops (Windows-based, but tablets are not domain members) that require access to the corporate network and the Internet
- Vendors—access to the corporate network and the Internet
- Phones, tablets, and laptops that may be personal or owned by their companies (a mix of laptops that are domain members and laptops that are not domain members, with a wide range of hardware platforms and operating systems)
- Guests—Internet access only
- Personal phones, tablets, and laptops (not domain members, with a wide range of hardware platforms and operating systems)
Defining the Alternative
In the past, users could connect to the network in a variety of different device and network combinations, depending on the security of the device and personal credentials. The following networks were available on the Microsoft campus. Each provided Internet access according to preset security policies.
- A-MSFTWLAN—for use by employees and/or vendors who had approved devices and Microsoft user accounts (computers may or may not be domain members)
- MSFTGUEST—for use by visitors, such as partners or customers, who required a one-time password obtained from a building's front desk operator (for computers that were not domain members)
Such a topology enabled flexibility for the different types of access that campus users needed. However, it also increased complexity for users, because they had to determine what connection to use and under what circumstances. If, for example, you were a vendor working on campus for the day (as opposed to a credentialed employee of Microsoft), and you brought your personal laptop along, would you connect to A-MSFTWLAN or MSFTGUEST? If you opted for the MSFTGUEST network, you would have needed to visit the reception desk and get a temporary password. But this network would not grant you access to internal corporate systems or networks. Connecting to A-MSFTWLAN could get your laptop onto the internal network and the Internet, but it required full domain credentials and corporate-issued certificates. A visiting contractor probably would not have those for just a single day's activities.
Microsoft employees who used personal devices for work email, calendar, and contacts could enter their domain credentials to connect to the internal corporate network via A-MSFTWLAN. They could then synchronize with Microsoft Exchange Server and access document libraries in Microsoft SharePoint Server.
These issues, combined with the limited management oversight available for personal devices, created a conflict between granting access and maintaining infrastructure security.
Rather than create another physical network for unmanaged devices, the solution was to build an independent, company-managed wireless network that would provide the simplicity of always-on connectivity, the security of complete network segregation, and the ubiquity of a cellular network. In short, the solution was to build an open network running on existing infrastructure, yet virtualized and separated from internal resources: MSFTOPEN. It would grant Internet access to all users without risking breaches or exploits from untrusted, unmanaged endpoints. The result would be two isolated networks:
- MSFTCORP—high security, for use only by employees who have approved devices and/or domain-member computers and Microsoft user accounts
- MSFTOPEN—for use by visitors, such as partners or customers, and employees' companion devices (for computers that are not domain members)
This solution required collaboration between multiple business groups within Microsoft, including Microsoft IT, Law and Corporate Affairs (LCA), Human Resources (HR), Real Estate and Facilities (RE&F), and internal development teams. But in the end, the effort would not only yield higher productivity and increased user satisfaction, but also reduce IT management costs.
A Needs-Based Approach
At Microsoft, users need broad support for consumer PCs (Mac computers, for example) and other untrusted devices that require Internet connections. In fact, some product groups must have these devices for product development and testing efforts. In addition, vendors, partners, and guests will have the same requests, and corporate management wants to support them without dictating what kind of devices they have to use on the company network. The goal is to support whatever form factors these users have.
To meet the global need for reducing operational costs through more efficient access, Microsoft IT settled on the following key criteria:
- Basic authentication and access mechanism
- Transparent compliance with industry regulations
- Bidirectional security and privacy for both corporate and personal data
- Minimal support costs, but with the broadest platform acceptance
Furthermore, keeping implementation and service costs at a minimum required Microsoft IT to deploy readily available components that would support broad access without complex VPN agents or other weighty client-authentication mechanisms. The MSFTOPEN wireless network would need to:
- Simplify the end-user experience.
- Enable both employees and visitors to easily access the Internet from almost any device.
- Eliminate front-desk network administration tasks from all buildings.
- Improve return on investment by using as much of the existing Microsoft infrastructure as possible.
Creating the Plan
Productivity gains mean accessing more data, from more devices, in more places. But to get there, Microsoft IT had to define a set of standards and policies that would govern how unmanaged devices connect to network infrastructure.
First, in the design phase, Microsoft IT needed to consider the potential impacts that an open network might have on overall IT security practices, topology, and features. In particular, how would Microsoft IT maintain separation between internal and external traffic?
Next, during the implementation phase, Microsoft IT had to create a new end-user authentication portal (a simple "read to connect" webpage). Microsoft IT tested custom router configurations in a pilot environment that consisted of just a few campus buildings. In addition, it was crucial that management processes for these new capabilities fit seamlessly with existing corporate network operations.
And in the final phase, execution, Microsoft IT would deploy the solution across the entire main Microsoft campus in Redmond and ultimately all Puget Sound (Washington) facilities. Microsoft IT would gather user feedback on the overall experience, the portal, and performance prior to a planned worldwide deployment.
Microsoft’s corporate privacy and compliance directives required alignment between defense-in-depth network security practices and individual users' privacy rights (whether or not they were Microsoft employees). Thus, handling sensitive information appropriately—as much for data governance as for personal discretion—was a big concern with comingling traffic through common network hardware.
Manageability, for end users and administrators alike, also needed special attention. Although it was necessary to prioritize individual usability over IT support, a simplified administrative experience nonetheless remained important if the solution was going to succeed long term.
Microsoft IT needed to evaluate policies for information usage in all Microsoft geographic locations. Otherwise, there was a risk that capabilities deployed in one region and suitable to that region's privacy laws would not be usable in other regions, where laws may be more restrictive.
Working with Microsoft LCA, Microsoft IT identified the risks associated with:
- Information protection. Even if users only have Internet egress over company-owned networks, sufficient data leakage protection and attack prevention had to be in place. If users are accessing the internal corporate network from a mobile device, they must use VPN or other mechanisms (for example, smart card, DirectAccess, and Remote Desktop) to help ensure secure and appropriate usage.
- Privacy. Microsoft can collect only the media access control (MAC) address and associated IP address for personal devices, to support authentication and troubleshooting. Microsoft cannot store, scan, or redirect traffic except for minimally acceptable security purposes.
- Compliance. Unmanaged devices on the open network (including smartphones, tablets, and personal laptops) cannot have direct access to sensitive data stored on company servers without sufficient safeguards in place. These safeguards include mandatory health-state monitoring, update verification, and other common endpoint security capabilities enabled by VPN or DirectAccess.
- Security. Users and devices should not be able to access the corporate network from the open network (except as described previously), and vice versa. Networks must be isolated on completely separate subnets, with no routes or permissions for transit between them. In addition, because traffic will flow through existing infrastructure and firewalls, all open-network traffic must be subject to the same antimalware, data leakage prevention, and security filtering as corporate traffic. Examples of this filtering include intrusion detection systems, intrusion prevention systems, and filters for HTTP exploits.
The first goal for the solution architecture was to keep it simple and avoid heavy-handed processes, such as manual configuration, that would only serve to frustrate users and reduce efficiency. Also, the architecture had to work across the broadest possible range of devices, operating systems, and applications without negatively impacting local IT and reception desk operations. As such, the solution had to enable standard client and client/server connections, including email, web, or other application for real-time communications.
Second, the new open network could not be physically separate with its own gateways. It needed to coexist on shared infrastructure and hardware for the Microsoft corporate network, including egress (Internet-facing firewalls), wireless access points, routers, load balancers, security devices, and service-level capabilities such as Domain Name System (DNS). If any additional infrastructure (for example, servers) is necessary, it had to be kept to an absolute minimum and within the confines of existing Microsoft data centers.
Last, any newly developed technology had to use common components and methodologies (such as the Microsoft .NET Framework), and Microsoft products (such as the Windows Server operating system, Internet Information Services [IIS], and Microsoft SQL Server software).
To enable simplicity for both end users and network administrators, it became clear that a standard server-side application would be the best approach. This design would eliminate client-side dependencies and give the greatest flexibility for integrating with the complex network environment at Microsoft. In addition, building from available technology such as Windows Server, IIS, and SQL Server would provide the necessary scalability and resilience, as well as portability and easier support. Figure 2 illustrates how the solution works.
Figure 2. Solution design.
Microsoft IT deployed and configured the following fundamental components at the Microsoft Redmond campus:
- Full virtualization on redundant, clustered hardware to provide failover
- A load-balanced pair of servers running Windows Server and IIS
- A replicated SQL Server database
The IIS web servers deliver both the captive portal page and the web-based administration console. The SQL Server database stores IP and MAC addresses along with timestamps for troubleshooting and maintaining a time-to-live (TTL) value for the network access token. The servers gather usage statistics, but no personal data, settings, or other traffic details are monitored or stored. After the servers pass the token back to the router, the device's address is marked for the Internet VLAN and permitted outgoing Internet access.
Another critical element was providing a simple, seamless connection experience for users that did not involve complex authentication or software agents. Because Microsoft IT did not want to identify, track, and filter MSFTOPEN network traffic, it determined that straightforward HTTP forms-based authentication (with a null password) via a basic HTML webpage would facilitate fast access.
This was also a way to deliver consistency across all devices and browsers—not to mention localization to other languages—without custom development to support each platform. And, if later on (or in specific scenarios such as downtown high-rise buildings) it became necessary to deploy authentication for MSFTOPEN users, the infrastructure would already be in place through this solution.
The end-user experience is essentially as follows:
- You open your device's Wi-Fi network settings to select MSFTOPEN as the broadcast service set identifier (SSID). (Devices that are capable of automatically detecting available wireless networks would raise a notification.)
- Selecting MSFTOPEN starts a web browser session that redirects you to a portal page that has an access agreement that you must accept. If the device does not support this action, you can manually open a new session.
- Upon acceptance of the access agreement, the browser opens the Bing home page, and all further HTTP/tunneled traffic passes through Microsoft Internet gateways.
Such an approach is known as an enterprise captive portal—a mechanism for granting guest (Internet) network access to unknown or untrusted devices or users, much as you would find in a hotel or airport. The basic security premise is that no traffic is allowed until you accept the usage agreement, at which point you digitally sign a terms-of-use disclosure. Thus, whenever you connect your device, you are "captured" before proceeding.
Another critical element of reducing deployment and maintenance costs for the open network was providing a simple administrative experience.
As a network solution aimed at minimizing security risks from consumer devices, MSFTOPEN had to deliver IP/MAC address and event logging (although not traffic recording) for auditability. Thus, if a breach were to occur, it would be possible to conduct a real-time forensic analysis of the source based on IP/MAC address, location, and related information. Microsoft IT can also use this type of auditable logging to aid regulatory compliance reporting when focusing on corporate network traffic used by personal devices.
MSFTOPEN provides a web-based console for configuring and maintaining the captive portal. Microsoft IT can distribute the software for this portal to other Microsoft data centers and locations via Microsoft System Center. Microsoft IT can also use System Center to gather World Wide Web Consortium (W3C)–compliant system logs from the SQL Server database for later analysis and reporting, beyond the native basic reports in the tool itself.
Initially, MSFTOPEN was deployed to only a few campus buildings occupied by Microsoft IT itself for internal testing. It coexisted with the other corporate wireless networks (A-MSFTWLAN, MSFTGUEST), giving Microsoft IT users a choice on any device (personal or company-owned, domain-member or otherwise) of which network to choose.
After Microsoft IT discovered and resolved issues and bugs, the team enabled any user in one of the pilot buildings to select MSFTOPEN. This provided a greater amount of feedback based on additional hardware platforms, operating systems, and application usage. A user could connect to MSFTOPEN from a phone, tablet, or laptop for direct Internet access, and traffic was completely isolated from the corporate network.
After MSFTOPEN was operational, Microsoft IT deployed it across the entire Redmond campus and all Puget Sound buildings. By using existing network infrastructure and only two clustered pairs of virtualized servers for the total network, Microsoft IT achieved implementation on a wide scale quickly and with minimal effort by a small team—covering many tens of thousands of devices automatically.
Ultimately, the MSFTGUEST network will be decommissioned around the world and replaced with MSFTOPEN. MSFTOPEN will deliver Internet access logically separated from corporate traffic, without the administrative overhead—or risk—required by granting access to the corporate network through untrusted endpoints.
MSFTOPEN is now servicing more than 35,000 unique devices daily. When the solution is completed, Microsoft IT expects that MSFTOPEN will handle 30 percent of total worldwide network traffic. Microsoft IT expects this solution to greatly improve operations of corporate network systems, along with reducing the support overhead for non-company devices and users.
Employees and other users who have domain-member computers will still be able to access the Internet through standard mechanisms on desktops and laptops. But after the global policy is implemented across all company sites, any devices (laptops, phones, or tablets) that are not domain members will be automatically rerouted to MSFTOPEN for Internet connectivity.
The benefit for all users is an easy method for Internet access. Access to the corporate network is fully controlled and auditable for security purposes. Additionally, the open network helps avoid compliance or HR issues by further separating potentially hazardous or unwanted traffic (such as piracy, inappropriate content, and malware) from the corporate network.
MSFTOPEN helps users stay connected, receive alerts and meeting updates/notifications, email, instant messages, and more—all from Windows Phones or tablets, along with iOS and Android clients. Similarly, unmanaged laptops that are connected to the Internet will have full use of HTTP-based software and protocols for these same application experiences.
The rapid iterative development process via IIS and SQL Server allowed for fast incorporation of user feedback. As new capacity or new buildings came online, engineers were able to test a growing number of devices, software, user criteria, and performance/reliability capabilities—more easily enabling adjustments based on experiences and security reviews.
In addition, using the existing network infrastructure at Microsoft allowed for a shorter time-to-value (TTV), at a far lower cost. And with simple administration tools for the solution, plus a straightforward interface for end users, Microsoft IT was able to facilitate deployment across hundreds of campus buildings almost as easily as pushing a button.
Implementing an open-network architecture at Microsoft yielded important benefits in information security and end-user satisfaction The program also produced some insights regarding future operations and management.
For example, open networks are not suitable for all device types and configurations. Although a user who has a company-owned, domain-member laptop can use MSFTOPEN, it might result in confusion when he or she is cut off from general corporate resources (for example, SharePoint sites and IT support tools). Such computers would need to default to the main wireless network, or be forced to connect through a VPN. And although this situation is partially mitigated through the use of DirectAccess from compliant endpoints, a global Group Policy setting in Active Directory Domain Services that sets a default wireless network is more straightforward (and transparent) for end users.
Similarly, updated policies will be deployed to redirect all non-domain traffic to the open network. In the future, any device—phone, tablet, or laptop—that does not meet all minimum criteria (that is, employee credentials, domain member, corporate asset) will be denied access to any network besides MSFTOPEN, regardless of a user's identity. This will effectively separate untrusted endpoints from those that are fully known and managed.
Other operational best practices include implementing bandwidth throttling at the router to prevent overusage by non-business network traffic, such as streaming media applications or content downloads. Because the open and corporate networks share the same physical infrastructure, there is a 70/30 split for domain versus open traffic. As a result, untrusted endpoints will never be able to overwhelm legitimate corporate use, and performance for trusted endpoints will be enhanced.
And finally, Microsoft IT will be able to more effectively track usage patterns and employee reactions in the future through quarterly satisfaction surveys, and by providing an internal email alias to gather direct feedback.
If you choose to evaluate a similar open-network solution for your enterprise, here are a few recommendations:
- Consider the impacts of security or policy changes when dealing with a large user population. Without careful analysis beforehand, you may generate more helpdesk calls than you prevent.
- Reuse existing tools and technologies wherever possible, to cut costs. Taking advantage of your infrastructure's existing capabilities will be not only easier, but faster.
- If necessary, modify the approach to require web-based or other authentication mechanisms for greater control over resource utilization. You may want to inspect traffic more aggressively than Microsoft did.
- Identify your use cases early so that you have a full understanding of who will be doing what from which devices.
- As with any broad IT project, keep the end goal simple so that you can measure results and benefits more easily.
IT organizations sometimes require a VPN for mobile device users who want to connect to corporate resources. Although this may work when a company can standardize on a single device platform and enforce a particular software solution, doing so across more than a few device types can lead to compatibility, serviceability, and management problems.
Redirecting this traffic by deploying a secondary wireless network adds a level of security for unmanaged personal devices and non-business use cases—effectively avoiding those challenges. And much like the way you would segment a wired network by using shared physical switches and routers, implementing an open network that is isolated through virtualization will achieve a higher degree of security and manageability. The MSFTOPEN solution not only addressed these needs, but did so without incurring significant costs because the corporate and open networks can coexist on the same infrastructure.
At present, all users are gaining consistent and appropriate access to the Internet, regardless of the devices they have chosen. The experiences of both employees and visitors—for corporate and personal devices—are already creating higher satisfaction across the community. Data governance has improved, and users' privacy when conducting personal tasks is being reliably maintained.
In the near future, Microsoft IT will move forward with global deployment of MSFTOPEN in multiple languages. After that, Microsoft IT will retire the older network topology by disabling the MSFTGUEST and A-MSFTWLAN SSIDs. There will be a 100 percent migration for all traffic to the new open-network access model, with mandatory redirects for all personal phones and tablets, as well as for laptops and PCs that are not domain members.
The next year will also see a further move toward improved operations by shifting the IIS and SQL Server environments to Windows Azure–based cloud deployments for network as a service (NaaS) across Microsoft. And for corporate locations that contain not only untrusted endpoints but also numerous unknown endpoints (such as shared office buildings in city centers), Microsoft IT will implement Remote Authentication Dial-In User Service (RADIUS) to help protect both the networks from use by non-Microsoft staff and visitors. The open portal page will thus become an authentication service, with the same access-token life cycles as the standard MSFTOPEN environment, to help ensure legitimate usage by approved parties.
The open-network project is just one of the investments that Microsoft IT has made to help Microsoft employees embrace digital work styles and flexibility with their own personal devices.
MSFTOPEN also aligns with the Microsoft approach to the future Internet of Things, where both browser-based and browserless devices can be added to the Wi-Fi network via self-service mechanisms. This will include not only phones and tablets, but also media and entertainment devices such as the Xbox One system, smart TVs, and wearable computers.
In particular, MSFTOPEN improved security and segregation for both corporate and personal network traffic, while also letting employees and visitors work on the devices that they prefer, further aiding productivity. The Microsoft culture of deploying new and emerging technologies will be the ultimate test of MSFTOPEN as it moves into production around the world.
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:
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Active Directory, Bing, SharePoint, SQL Server, Windows, Windows Azure, Windows Server, and Xbox 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. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.