Preparing for the Global Deployment of Windows 2000 Technologies: Strategic Pilot Testing at Microsoft
Contents
Executive Summary
Microsoft Deployment Environment
Upgrading the First Windows NT 4.0-Based Domain
Business Problem
Pilot Scope
Pilot Implementation
Results
Lessons Learned
Future Direction
Printers in Active Directory
Business Problem
Pilot Scope
Pilot Implementation
Results
Lessons Learned
Future Direction
Intellimirror Management Technologies
Business Problem
Pilot Scope
Pilot Implementation
Results
Lessons Learned
Future Direction
TAPI 3.0 Integrated Technologies
Business Problem
Pilot Scope
Pilot Implementation
Results
Lessons Learned
Future Direction
Conclusion
Future Direction
For More Information
Appendix
Executive Summary
The release of the Microsoft Windows 2000 operating system is a major milestone for Microsoft and its long-term investment in Windows NT technology. To assure a higher level of quality and to verify the business value of the technology in Windows 2000, Microsoft has executed a broad internal deployment of Windows 2000 while it is still in the prerelease stage.
Although deploying beta code worldwide has presented operational challenges to Microsoft's Information Technology Group (ITG), Windows 2000 is providing great opportunities and new efficiencies in Microsoft's business computing environment. With Windows 2000 Professional on their desktops and Windows 2000 Advanced Server running for backend services, Microsoft employees can enjoy easier access to network resources whether they are Intranet, Internet, dialup networking, or on the corporate network, with much improved reliability and higher levels of service from ITG.
In an April 1999 white paper entitled "Windows 2000 Initiatives at Microsoft," ITG discussed the strategy and goals for that deployment as well as challenges faced and organizational efforts undertaken to plan, implement, and manage the deployment. That discussion continues in this document, "Preparing for the Global Deployment of Windows 2000 Technologies," which details pilot tests conducted around four key areas of the deployment, Upgrading the First Windows NT 4.0-based Domain, Printers in Active Directory, IntelliMirror Management Technologies and TAPI 3.0.
Strategic Pilot Testing
As ITG learned, pilot tests were essential in helping to develop a strategy for deployment of Windows 2000 features company-wide. For example pilot tests were key to upgrading the company's largest master-user domain in April 1999 as well as deploying Windows 2000 Professional to more than 42,000 desktops across the company. Based on experiences in these deployments and in the pilot tests that preceded them, ITG began planning and building strategies for company-wide deployments of other Windows 2000 core technologies.
Upgrading the First Windows NT 4.0-based Domain
Migrating 27,000 domain accounts to Active Directory was a vital step in the strategy to deploy Windows 2000 Advanced Server company-wide. The systems that were used to store the bulk of domain accounts were at the heart of the company, and at the fore of ITG's deployment strategy. To advance its deployment into other areas of the company ITG needed to deploy Windows 2000 Advanced Server to those systems to further develop deployment strategies for additional Windows 2000 technologies. Now with Active Directory, employees are able to locate printers and install applications much faster than in the past.
Printers in Active Directory
Active Directory stores information on network objects, such as accounts, computers, printers, applications, and network subnets. Users of Active Directory want to find and use these objects, and administrators want to manage the way in which the objects are used. For its pilot testing of printers in Active Directory, ITG needed to determine a naming convention that would aid in the location of printers nearby.
Under Windows NT Server 4.0, ITG print administrators had to perform much of their jobs situated in front of the print-server console. This was because very little print-server administration could be done remotely. Now with Windows 2000 Advanced Server most print-administrative tasks can be done remotely.
IntelliMirror Management Technologies
IntelliMirror management technologies are built into the Microsoft Windows 2000 operating system and designed to increase availability and reduce the overall cost of supporting users of Windows 2000. At the core of IntelliMirror are three key management features 1) User Data Management 2) User Settings Management 3) and Software Installation and Maintenance. As part of its deployment strategy ITG pilot tested IntelliMirror management technologies to develop a strategy to deploy those technologies company-wide. Now using IntelliMirror management technologies, employees are able to locate and install programs faster and with reduced support from ITG.
TAPI 3.0 Integrated Technologies
Just as data networking is key to bridging vital corporate links between Microsoft and the rest of the world, so too are its telecommunications. For the internal deployments of Windows 2000 Professional and Windows 2000 Advanced Server, ITG planed the deployment and support for desktop telephony using TAPI 3.0 from thousands of computers. TAPI 3.0 is key to seamlessly integrating data networking with telecommunications, and as such, ITG viewed pilot testing TAPI 3.0 essential to begin that deployment company-wide. For the first time thousands of employees are able to place phone calls directly, using computers running the Windows 2000 Professional operating system and TAPI 3.0.
In addition to exploring ITG's approach to conducting the pilot tests, this document discusses competencies gained, lessons learned, and decisions made about the future direction of Microsoft's internal deployment and how it is likely to benefit from those tests. The goal of this document is to help customers understand why the results of these pilot tests are important to Microsoft and how customers might want to apply ITG's experience to the evaluation of similar functionality in its own environments.
Microsoft Deployment Environment
All environments are different and therefore each company must plan differently for a major product deployment. Microsoft has many challenges in deploying Windows 2000 Professional and Windows 2000 Advanced Server that are unique to that environment. The challenges and advantages ITG encountered include:
Providing useful feedback to product development — One of ITG's main goals was to help test Windows 2000 Professional and Windows 2000 Advanced Server, providing the product-development groups with real-world, production environment, enterprise feedback to help ensure a high quality release of both products. This of course required ITG to deploy both Windows 2000 Professional and Windows 2000 Advanced Server. It also required ITG to develop a process to identify and provide meaningful feedback to the product development group.
Piloting a beta product in a production environment — As ITG knows, the best possible environment for pilot testing beta technology, from a technical perspective may not be a viable option from a businesses perspective, especially if that environment is critical to Microsoft's business. ITG had to be creative in the way it tested the beta product, for example, by simulating real-world environments in other ways. In general, ITG deployed the beta by first pilot testing the new technology in a small-scale environment and then later deploying more widely using its real-world environment while providing feedback to product development at every step in its deployment.
Deploying the Microsoft Windows 2000 Active Directory directory service in a production environment — On April 9, 1999, ITG upgraded its largest master user domain, located in Redmond, Washington. The upgrade process, discussed later in this paper, was the first time such an event had been performed. The upgrade process is an excellent example of the type of commitment Microsoft has to use its own internal computing infrastructure as a critical test bed for finding and resolving issues with the product internally, before the product is released. ITG and the product development group are committed to making sure that both Windows 2000 Professional and Windows 2000 Advanced Server are fit for the largest enterprises by resolving issues internally before releasing either product.
Deploying Windows 2000 Professional to more than 42,000 workstations — At this writing, more than 42,000 computers within the company have been upgraded to Windows 2000 Professional, and over 25,000 user accounts have been migrated to Active Directory. Having a larger number of Windows 2000 Professional workstations in production along with a production Active Directory service has made it possible for ITG to break new ground and push forward in areas of its deployment not previously possible. Two such examples are the pilot testing of printer location tracking and IntelliMirror, both discussed later in this paper.
Learning while doing — Early in the product development cycle documentation is being developed along with the product. ITG began its deployments of Windows 2000 Professional and Windows 2000 Advanced Server without the benefit of completed documentation. As of this writing, many documents have become available and have significantly helped ITG to deploy Windows 2000 Professional and Windows 2000 Advanced Server. (See the section entitled "For More Information" to access such documentation.) However, until documentation became available ITG relied heavily on hands-on work to learn what Windows 2000 Advanced Server and Windows 2000 Professional can do.
Upgrading the First Windows NT 4.0-Based Domain
Business Problem
At the heart of Microsoft's computing infrastructure are computer systems that handle logon requests from more than 25,000 employees who require access to the enterprise information environment. These computer systems challenge the security credentials of employees in a variety of ways, including network logon, shared-file access, and shared-printer access. Without the availability of these computer systems, employees would be denied access to information that is critical to supporting Microsoft's day-to-day operations. In addition, without these computer systems the security system protecting Microsoft's corporate network would be compromised.
Known as Microsoft Windows NT Domain Controllers, the computer systems that handle and manage the security functions at Microsoft are considered a vital component of the enterprise based upon the Windows NT Server network operating system. Windows NT Domain Controllers play a critical role in securing corporate assets while at the same time providing employees the access they need to do their jobs. In addition, Windows NT Domain Controllers are used to ensure that computers can share information among one another.
Because so much depends on the availability of Windows NT Domain Controllers at Microsoft, it is critical that those systems be extremely reliable. Microsoft is committed to ensuring that Windows 2000 Advanced Server (and Windows 2000 Data Center Server) are one of the most highly available and reliable network operating systems ever. This makes the Windows NT Domain Controllers that constitute Microsoft's largest master user domain the most logical computer systems on which to test the availability and reliability of the beta release of Windows 2000 Advanced Server. At the time Microsoft decided to begin upgrading its enterprise information systems to the beta of Windows 2000 Advanced Server, ITG determined that the Windows NT Server 4.0 domain controllers would be likely candidates for the upgrade. The fact that the beta had never before been put to use on such heavily used domain controllers made those systems all the more desirable to upgrade.
ITG also determined that given the critical nature of the functions performed by the domain controllers that make up the master user domain serving Microsoft's corporate headquarters, those servers would have to be highly available and reliable after the upgrade to Windows 2000 Advanced Server. If the upgrade should fail, Microsoft's corporate headquarters would essentially end up offline until ITG could restore the state of the master user domain.
Before upgrading any Windows NT Domain Controllers to the beta release of Windows 2000 Advanced Server, ITG needed to considerably reduce the risk associated with deploying the beta in the production environment. ITG felt that the best approach to this first upgrade would be to pilot test (1) the extensive contingency plans and (2) upgrading the domain in a carefully, well tested, controlled fashion.
Pilot Scope
Upgrading Windows NT Server 4.0–based Domain Controllers to Windows 2000 Advanced Server was a vital step in ITG's process of deploying Windows 2000 Advanced Server. To provide feedback to the product development group, ITG selected the largest of the company's 13 master user domains. The scope of the pilot was to test, validate, and confirm the process of upgrading the large master user domain, consisting of six servers running the Windows NT Server 4.0 network operating system, while in production and to study the effects of this upgrade across the company. Once the pilot was fully operational, an unprecedented 25,000 employees located at Microsoft's corporate headquarters would be relying on Windows 2000 Advanced Server to gain entry into the enterprise.
In addition to generating feedback for ITG to deliver to the product development group, the upgrade was designed to provide direct advantages to ITG as well. For starters, ITG needed to upgrade the largest master user domain to Windows 2000 Advanced Server before pilot testing other Windows 2000–based technologies, such as Printers in Active Directory, IntelliMirror management technologies, and TAPI 3.0. With this upgrade complete, ITG could begin pilot testing those other technologies (as discussed later in this paper).
ITG expected the upgrade process to go smoothly, even before it began, due to the fact they had performed a number of trial runs in a test environment. At the same time, ITG recognized that because they had not undertaken the process in a real-world environment before, some unforeseen bug could surface under a heavy load and essentially shut down the company. To mitigate such risk while providing the availability that 25,000 employees at corporate headquarters had come to expect, ITG did considerable testing and planning to develop their approach to the upgrade.
Below is the approach decided on:
Build the test environment.
Transition each domain controller from the production environment to the test environment.
Perform the upgrade.
Test and validate that the domain controllers can authenticate test accounts.
Transition the domain controllers back to the production environment.
Because of the critical nature of the testing, ITG acquired six additional computers that would later be used as part of the test. Testing and validating authentication took place over a 48-hour period. During this period, ITG validated the results of the upgrade across the company. ITG staff who participated in pilot came from various areas of the company and focused on the following:
Infrastructure and critical server support — For hands-on work necessary for upgrading servers to the beta release. Prior to installation and configuration of software, this group verified that all hardware and networking components were fully operational.
Diagnostic support — Acted as liaison between ITG and product development in case of a problem with Windows 2000 Advanced Server. As a contingency measure, this group was prepared to configure servers for remote debugging so that, if necessary, product development could resolve a problem by debugging it.
Helpdesk — Informed employee's company-wide when pilot testing would begin and end and what it would entail. Also learned to identify upgrade-related symptoms and answered questions quickly and with a high degree of customer satisfaction.
Windows 2000 product development — Involved in every step of ITG's planning and testing of the beta so that in case of problems product development could work to resolve them quickly.
Information security and directory service management — Responsible for domain trust relationships and domain security. Ensured that trust relationships worked properly following the upgrade and that password expiration was extended beyond the duration of the pilot.
Operations tools support — Ensured that internal tools relying on the creation of machine and user accounts would function properly once the beta was in use.
Line-of-business application support — Verified that batch files would authenticate properly and complete normally once the beta was in use. Also reviewed verification of line-of-business application authentication as a condition of the pilot testing.
Archival and recovery support — Focused on ensuring that all systems had been properly backed up before being upgraded to the beta.
Pilot Implementation
As noted in the preceding section, to upgrade the selected master user domain to Windows 2000 Advanced Server, ITG staff built a test environment, transitioned domain controllers from production to the test environment, upgraded each domain controller and verified that the upgrade was a success, then transitioned the upgraded servers back to production.
Building the Test Environment
The test environment consisted of a private network isolated from the corporate network and a number of other computers from which ITG could validate authentication against Windows 2000 Advanced Server. Servers within the test environment fluctuated in number as they were transitioned in and out of production for upgrading.
Initially, ITG added four Windows NT Server 4.0-based backup domain controllers to the master user domain, leaving them in production for three days to ensure that the Security Account master database was fully synchronized on each. ITG cabled two remaining servers to its private network so the servers would be isolated from the corporate network. They then installed Windows 2000 Advanced Server on the two servers and configured each of them as a member server. Note that all servers involved were located in the same room. Figure 1 illustrates a simplified view of both the initial state of the production environment and the initial state of the test environment.
.gif "Bb742603.wn2kdp01(en-us,TechNet.10).gif")
Figure 1: Initial condition of production and test environments
Transitioning Domain Controllers from the Production to the Test Environment
To prepare for the upgrade, ITG disabled account password changes and account creations for Windows NT by turning the primary domain controller off, just before it began the upgrade process. This precaution was deemed necessary to ensure that the state of the domain would not change during the testing. ITG also initiated a number of e-mail communications with internal users to ensure that employees company-wide were aware that the upgrade was underway, and that password changes would not be possible during the process.
In order to minimize the number of password changes that would be attempted during the upgrade, the network security group extended the password expiration grace period by several days before the primary domain controller was taken offline. This was deemed necessary to reduce the probability that passwords would expire, during the upgrade processes.
ITG then transitioned two of the production Windows NT Server 4.0–based backup domain controllers from the production environment to the test environment. ITG performed the transition by recabling the backup domain controllers so that the backup domain controllers were physically cabled to the private network, essentially isolating those servers from the production environment.
After recabling each Windows NT Server 4.0–based backup domain controller, ITG "promoted" one of them to become the primary domain controller. The promotion from backup domain controller to primary domain controller was accomplished by using Server Manager (srvmgr.exe) included with Windows NT Server 4.0.
As a disaster-avoidance measure, ITG took a second Windows NT Server 4.0–based domain controller (in addition to the primary domain controller) within the production environment offline. They took this precaution to ensure that they would be able to restore the environment if necessary by simply bringing either domain controller back online and promoting one of them to become the primary domain controller of the production environment. (Note that ITG had done this as a disaster avoidance measure to ensure that if the upgrade had failed they would still be able to recover from the problem.)
After the transition, the test environment consisted of one Windows NT Server 4.0–based backup domain controller, one Windows NT Server 4.0–based primary domain controller, and two Windows 2000 Advanced Server–based member servers. Figure 2 illustrates both the test environment as well as the production environment following this transition.
.gif "Bb742603.wn2kdp02(en-us,TechNet.10).gif")
Figure 2: State of production and test environments during the transition
Upgrading Each Domain Controller
The upgrade process, which lasted about six hours, went very smoothly. Each server that was upgraded was cabled to the private network, isolating it from the corporate network. The production environment remained in full operation during the upgrade and was virtually unaffected by the operation.
ITG upgraded the Windows NT Server 4.0–based primary domain controller to Windows 2000 Advanced Server simply by running win32.exe, which is included in Windows 2000 Advanced Server. As part of the upgrade, ITG selected an option to join the domain to an existing Windows 2000–based forest, which is a collection of domains. By upgrading the Windows NT Server 4.0–based primary domain controller to Windows 2000 Advanced Server, ITG upgraded more than 27,000 user accounts to Windows 2000 Advanced Server as well.
ITG ran DCPromo.exe, included with Windows 2000 Advanced Server to convert the two Windows 2000 Advanced Server–based member servers to domain controllers. Once those systems were converted to domain controllers they began to participate in domain replication and synchronization. After competing the process, the test environment consisted of one Windows 2000 Advanced Server–based primary domain controller, two Windows 2000 Advanced Server-based backup domain controllers, and one Windows NT Server 4.0–based backup domain controller.
Microsoft plans to offer as a SKU through all channels Windows 2000 Advanced Server at a slight discount to customers who are upgrading from Windows NT Server 4.0. A more substantial discount upgrade is planned for customers who are upgrading from Windows NT Server 4.0, Enterprise Edition.
Verifying and Validating Authentication
After performing the upgrade, ITG conducted a series of tests to ensure that the environment would be stable once it was put back to production use. Their testing focused on ensuring that authentication and domain replication occurred seamlessly and without issue. In addition, ITG focused on validating the following areas:
Authentication from Remote Access and the Point-to-Point Tunneling Protocol
Batch file processing
Domain synchronizing
Local authentication
Trust relationships between the upgraded domain and other domains in the enterprise
To test trust relationships in the test environment, ITG built a replica of a down level 1-way trusted domain, and a 2-way trusted MUD. The replicas were built in existing domains then moved into the test environment for the specific purpose of testing. A Remote Access and PPTP server were added to the test environment for the specific purpose of testing authentication using those systems.
Transitioning Domain Controllers Back to Production
After performing all authentication tests, ITG determined that the upgrade process was successful. The next step, transitioning the upgraded domain controllers back into production, was a simple one.
To perform the transition, ITG turned off each domain controller in the test environment long enough to recable it to the corporate network. ITG then brought each recabled Windows 2000-based domain controller back online, making it immediately accessible across the company. As soon as the domain controllers were accessible, ITG reset password life to 70 days.
Results
On a scale of 1–10, the upgrade to Windows 2000 Advanced Server was determined to be a solid 9. Just two bugs were found in Windows 2000 Advanced Server and resolved as part of the test. The first bug resulted in trust relationships failing to trust the Windows 2000–based domain. A trust relationship is necessary between domains such as the ones ITG created so that employees are able to log on to the network using a single password to gain access to corporate wide resources. ITG worked around the trust issue by simply recreated the affected trust relationships manually using User Manager (usrmgr.exe), included with Windows NT Server 4.0 so as to bring all domains into full operation.
The second bug resulted in authentication failures using dial-up. Product-development was unable to resolve this bug immediately, so ITG performed a risk analysis to determine how many users it might affect. Based upon this analysis, it was determined that only employees who connected remotely using the Point-to-Point Tunneling Protocol over Remote Access would be affected. As it was, ITG staff had performed the upgrade over a weekend and their risk analysis indicated that only two-dozen employees were expected to access the equipment in such a way as to be affected by the bug. A password reset was found to be a suitable workaround for those employees. Within a few days, product-development resolved this bug as well. As a result, all of the bugs found during the test were resolved before the beta 3 release of Windows 2000 Advanced Server.
After proving that Windows 2000 Advanced Server was sufficiently available and reliable to be used at the heart of the company, ITG decided to upgrade the remaining domain controllers in the master user domain to Windows 2000 Advanced Server.
As of this writing, all seven Windows NT Server 4.0–based backup domain controllers in the Redmond master user domain have been upgraded to Windows 2000 Advanced Server. Additionally, ITG has converted 2 of its 13 master user domain to Windows 2000 Native Mode, and eight others are running in Windows 2000 mixed mode. A total of 51 Windows NT Server 4.0-based domain controllers company-wide have been upgraded to Windows 2000 Advanced Server.
Based on what they have observed in running Windows 2000 Advanced Server in their production environment, ITG is better prepared to deploy Window 2000 Advanced Server in other areas across the company.
Lessons Learned
ITG learned two key lessons from its upgrade of the master user domain to Windows 2000 Advanced Server. First, ITG learned that performing an in place upgrade of the master user domain was a better approach than performing a parallel migration would have been. Second, a training environment that ITG built was greatly appreciated for its value in allowing hands on training to occur.
Upgrading in Place the Better Approach
ITG considered two approaches for transitioning the first Windows NT Server 4.0–based domain controllers to Windows 2000 Advanced Server: A parallel migration approach and upgrading in place.
ITG thought of doing a parallel migration because they felt the approach might greatly reduce the risk associated with deploying the beta software, and the approach might ultimately be easier to do. The parallel migration plan called for keeping the legacy Windows NT 4.0 environment fully in place long enough to duplicate machine and user accounts in a parallel Windows 2000 environment. ITG considered this approach to be the safer of the two, since the legacy environment would not be affected by the addition of new equipment, however ITG would have been required to perform clean installs rather than upgrade software in place.
The fact that ITG would have been required to do clean installs rather than upgrade software would essentially have meant that ITG would have to rebuild its environment from scratch. ITG would have needed to build a parallel Windows 2000–based environment and migrate user accounts from its legacy Windows NT 4.0 operating system environment to the new environment. The accounts would have needed to be migrated by 1) duplicating those accounts in the Window 2000-based environment 2) establishing trust relationships 3) providing sufficient file-level permissions for the migrated employees to access files they had created in the legacy environment. While the approach seemed viable, there were a number of issues that made the plan less desirable than the approach of upgrading software in place.
First, to perform a parallel migration from Windows NT Server 4.0 to Windows 2000 Advanced Server, ITG would have needed to purchase hardware that was otherwise unnecessary. Second, ITG would have needed to monitor, manage, and maintain many trust relationships between its Windows 2000–based environment and its Windows NT 4.0–based environment. Third, every user and machine account would need a new Security Identifier (SID).
The SID is central to internal security for both Windows NT Server 4.0 and Windows 2000 Advanced Server. Each user and machine account that must log on to the network has a unique SID for validating and enforcing security. The SID is used also when employees create and save files to corporate file servers. In this case, each file is designated with the SID of its creator. The association of a user's SID with files that he or she creates enables files to be secured quickly and with minimal administrative overhead.
However the SID complicated plans to perform a parallel migration. The parallel migration plan would have called for ITG to create a new user accounts for each employee in the parallel environment. As part of this process the underlying system would have created a new SID for each employee, by design the system also views each SID as a unique user on the system. ITG found that each user needed to migrate to Windows 2000 Advanced Server using the parallel approach would have to be given access to files manually so that employees could reclaim access to them. The process was viewed as too time-consuming making the parallel-migration plan unviable.
The approach that ITG is using as of this writing is to upgrade software in place, by running the Windows 2000 Advanced Server setup utility from computers already running the Windows NT Server 4.0 network operating system. In contrast the parallel migration plan called for ITG to perform clean installs of Windows 2000 Advanced Server.
Appreciating the Value of a Training Environment
ITG constructed a Windows 2000–based training environment for the purpose of learning very early in its planning. The training environment is limited to ITG, and absolutely everything that ITG plans to do in production is first done within the training environment.
The training environment has served as a valuable asset for ITG staff who want to reality-check plans and deployment approaches before putting them to use in production and for those who want to learn about Printers in Active Directory, IntelliMirror, Group Policies, and Windows 2000–based administration.
The training environment also proved to be of value in mitigating the risk associated with learning how to upgrade and how to perform trial runs and develop plans while deploying a beta product in production. Note that the training environment is intended not to keep the entire system highly available but rather to provide a way for ITG to learn about the environment and get the most value out of it. Even though the training environment is considered a test environment, it still has all the trust relationships needed for employees to be able to do their jobs while using the environment. This means that for all practical accounts it is a production environment, distinguished only by the fact that ITG has limited the number of users so the environment can remain offline without adversely affecting employees company-wide.
Future Direction
Now that more than 42,000 desktop computers within the company are running Windows 2000 Professional, and Microsoft's largest master user domain is running in Windows 2000 Native Mode, ITG has created an ideal environment around which other aspects of their deployment can rally. This environment enables ITG to begin pilot testing other Windows 2000–based technologies such as Printers in Active Directory, IntelliMirror, and TAPI 3.0. (Later sections of this paper discuss each of those pilots in detail.)
The experience that ITG developed to upgrade its first Windows NT Server 4.0–based domain to Windows 2000 Advanced Server is being used to upgrade other domains as well. ITG is now in a better position to continue upgrades of other domains throughout the company, as a result of the pilot. The upgrade of Microsoft's largest master user domain to Windows 2000 Advanced Server is a significant advance toward completing the internal deployment.
ITG will continue to use experiences gained during pilot testing to upgrade other master user domains to Windows 2000 Advanced Server, until all have been upgraded. As this process continues, employees in other areas of the company will be able to take advantage of other Windows 2000 features that rely on the Windows 2000 Active Directory directory service.
Printers in Active Directory
Business Problem
While Microsoft employees view documentation primarily in electronic form, they still rely on printers for a variety of needs. For example, they may need a hard copy of speaking notes or documentation to prepare for a presentation or to hand out at a meeting. To accommodate the diverse printing needs of Microsoft employees, ITG has deployed several thousand printers across the company.
Microsoft is a dynamic working environment. To accomplish their work, employees routinely move from one area to another within the company. When they make such moves, temporarily or permanently, they must locate "shared" printers they can use. ITG has tried to simplify this process by placing shared printers in public areas so they are easily visible.
However, this approach doesn't solve the entire problem. While it helps employees to see printers easily, it doesn't help them with the installation and configuration of software they may need in order to use a particular printer.
For example, signs are posted on each printer showing its print server and printer queue name, the basic configuration information needed by anyone who might want to install a connection to that printer to their workstation. However, signs sometimes are removed, and configuration information quickly becomes out of date.
Another problem is that employees frequently are unaware that they are free to connect their workstation to any number of printers. Unless the employees take the trouble to investigate a number of different printers, they have no idea which ones are capable of printing in color, full duplex, and so on. As a result, they often choose a printer that's conveniently located rather than a printer that might work best for their particular need.
To address such problems, Windows 2000 Advanced Server and Windows 2000 Professional include a new feature called printer location tracking. As part of a number of powerful printing enhancements that are vital to the redesign of Microsoft's internal printing superstructure, printer location tracking is designed to help mobile users easily install and configure printers without needing to know their location in advance. With printer location tracking enabled and configured properly, employees will be able to search for printers from the convenience of their workstation, and find the ones they want based on color capabilities, speed, location, and other criteria.
As of this writing, all print servers located in Microsoft's main campus in Redmond, Wash., have been upgraded to Windows 2000 Advanced Server, and 42,000 workstations have been upgraded to Windows 2000 Professional. Additionally, ITG has upgraded Microsoft's largest master user domain to Windows 2000 Advanced Server, making the situation ideal to now enable printer location tracking.
Pilot Scope
For printer location tracking to work properly, ITG needed to plan and configure Windows 2000 Active Directory properly. According to ITG's plan, pilot testing Printers in Active Directory would play a vital role in configuring the group's Windows 2000 Active Directory service and in helping ITG to sanity-check its configuration in a small-scale environment. This approach also would allow ITG to quickly make minor adjustments to its configuration based upon the results of the usability testing.
ITG performed the pilot testing of Printers in Active Directory using equipment running in production, including the following:
An ATM-based network backbone and Metropolitan Area Network
Print servers running Windows 2000 Advanced Server
A Windows 2000–based Active Directory
Thousands of desktop computers running Windows 2000 Professional
Cross-team collaboration was key to completing the testing and collecting usability feedback. So, participating members came from a number of different areas:
Helpdesk
Windows 2000 Active Directory deployment planning and strategy
Corporate data-center support
Pilot Implementation
To plan and configure Active Directory so that employees could locate printers efficiently and effectively, ITG divided its pilot testing into five primary tasks: developing naming conventions, configuring network subnet objects, applying a group policy, configuring printers, and testing for usability.
Developing a Naming Convention for Physical Locations
Naming conventions generally are used to categorize objects or resources that have something in common. For example, ITG has developed standard naming conventions for servers and telecommunications devices as well as network routers. By helping to provide information about a device's purpose (e.g., e-mail, remote access, printing), physical location (e.g., Redmond, Sydney, Beijing), and other characteristics, the names help ITG to monitor, manage, and maintain servers and other devices.
For printers in Active Directory directory service viewing printers as output devices employees use rather than a collection of print queues was important. This consideration helped ITG to focus on developing a naming convention that would be of value to the majority of employees who use printers, rather than as a convenience to print administrators who would like to come up with a standard on their own.
So ITG devised a location naming convention that 1) describes to employees where printers are physically located and 2) describes the same information (through query search strings) to Windows 2000 Active Directory. To devise a naming convention that would satisfy these requirements ITG based the naming convention on well-defined rules for searching Active Directory, rules that are part of Active Directory design itself. ITG put those rules to use in devising a naming convention that works well in its environment.
The well-defined rules for searching the Active Directory service for published printers specify the following:
A location search string is in the form of <countryname>/<cityname>/<buildingname>/<floorname>/<roomname>... with "/" as the dividing character between levels.
A location search string can consist of no more than 256 levels.
A location search string can consist of no more than 260 characters.
Each <___name> in the string can consist of any characters except "/".
Each <___name> in the string can consist of no more than 32 characters.
To arrive at a location search string for each printer, ITG conducted an audit to obtain an accurate sample of a few dozen printers. Of key interest was the physical location of each printer. For each printer selected to be part of the audit, ITG noted the make, model, physical location, and network subnet. Staff also looked up the location of employees as displayed in the company's Exchange 5.5 Global Address List, who were in close proximity to the selected printers. This was deemed necessary because it was felt that the naming convention for locating printers might later be needed to describe other objects in Active Directory, objects such as users accounts.
Conducting the audit and planning to pilot test Printers in Active Directory gave ITG a chance to assess current business practices for managing its printers. Currently, many shared printers throughout Microsoft use the Dynamic Host Configuration Protocol (DHCP). This technology makes it very easy for printers to be moved between corporate buildings and office parks without needing to be reconfigured to work at the new location. Because DHCP-enabled printers are so cost effective and so simple to deploy and later re-locate, ITG staff did not need to record the physical location of DHCP-capable printers. In contrast, when ITG staff manually programmed each printer using static IP addresses, they had to record where each printer was located. This was key to consider because moving forward ITG will need to keep a record of physical printer locations, so that users can enter a suitable search string to locate each printer.
Based on this audit and the Windows 2000 Active Directory rules discussed earlier, ITG suggested the following location-naming convention:
Country/City/Building/Floor/Room Description.
Table 1 illustrates how ITG staff then used the results of the audit to build a table describing various U.S. locations at which shared printers were installed. The table represents various ways in which a user will be able to search Active Directory to locate a printer they wish to use. For example a user could locate printers in the SAMM-B building of Issaquah, Wash by using USA/Issaquah/SAMM-B as Active Directory search string. (For the results of such a search see Figure 5)
Table 1 Naming rules applied to the ITG environment
City |
Building |
Floor |
Room Description |
|---|---|---|---|
Redmond |
Building1 |
Floor1 |
1234 |
|
|
Floor2 |
Mail copy room |
|
|
Floor3 |
Mail copy room |
|
|
|
|
|
Building2 |
Floor1 |
Mail copy room |
|
|
Floor2 |
Mail copy room |
|
|
|
|
|
Building3 |
Floor1 |
1717 |
|
|
|
|
Issaquah |
SAMM-A |
Floor1 |
Mail copy room |
|
|
Floor2 |
2314 |
|
|
|
|
|
SAMM-B |
Floor1 |
Mail copy room |
|
|
Floor2 |
2222 |
|
|
|
|
Bellevue |
RW-G |
Floor1 |
Mail copy room |
|
|
Floor2 |
Mail copy room |
|
|
Floor3 |
3322 |
|
|
Floor4 |
Mail copy room |
To configure the Windows 2000 Active Directory service, ITG staff needed to know the physical location of every printer across the company. Rather than conducting a company-wide audit of all printers, ITG needed only the locations of a few dozen such printers in order to begin their pilot tests. With those first few dozen printers, ITG was able to begin to configure their implementation of Windows 2000 Active Directory.
Configuring Subnet Objects in Active Directory
To create subnet objects within Active Directory, ITG used the Directory Services Site and Subnet Management tool included with Windows 2000 Advanced Server. With this tool, ITG created site and subnet objects for each location that would participate in the pilot. For example, using their own location naming convention, ITG staff associated a location string with both site and subnet objects.
Table 2 illustrates the use of ITG's location naming convention with objects within Active Directory, and Table 3 illustrates the location naming convention used to associate subnet objects within Active Directory with the physical location of each subnet.
Table 2 Location associated with each site
Site |
Active Directory object name |
Location |
|---|---|---|
Redmond |
USA1 |
USA/Redmond |
Issaquah |
USA2 |
USA/Issaquah |
Bellevue |
USA3 |
USA/Bellevue |
Table 3 Location associated with each subnet
Place |
Subnet object* |
Location string associated with each subnet object |
|---|---|---|
Redmond Marketing |
123.45.67.8/24 |
USA/Redmond/Building1/Floor1 |
Redmond Marketing |
123.45.67.8/24 |
USA/Redmond/Building1/Floor2 |
Redmond Marketing |
123.45.67.8/24 |
USA/Redmond/Building1/Floor3 |
Redmond Sales |
123.45.67.8/24 |
USA/Redmond/Building2/Floor1 |
Redmond Sales |
123.45.67.8/24 |
USA/Redmond/Building2/Floor2 |
Redmond HR |
123.45.67.8/24 |
USA/Redmond/Building3/Floor1 |
|
|
|
Issaquah Planning |
123.45.67.8/24 |
USA/Issaquah/SAMM-A/Floor1 |
Issaquah Planning |
123.45.67.8/24 |
USA/Issaquah/SAMM-A/Floor2 |
Issaquah Devt. |
123.45.67.8/24 |
USA/Issaquah/SAMM-B/Floor1 |
Issaquah Devt. |
123.45.67.8/24 |
USA/Issaquah/SAMM-B/Floor2 |
|
|
|
Bellevue Support |
123.45.67.8/24 |
USA/Bellevue/RW-G/Floor1 |
Bellevue Support |
123.45.67.8/24 |
USA/Bellevue/RW-G/Floor2 |
Bellevue Support |
123.45.67.8/24 |
USA/Bellevue/RW-G/Floor3 |
Bellevue Support |
123.45.67.8/24 |
USA/Bellevue/RW-G/Floor4 |
*Subnet Objects within Active Directory are defined as <IP Address>/<ActiveBits>
Applying a Group Policy in Active Directory
By default, printer location tracking is not enabled within Active Directory. So ITG staff used the Group Policy Editor, included within Windows 2000 Advanced Server, to apply a policy that would enable printer location tracking. The Group Policy Editor provides a graphical user interface that simplifies configuration changes.
Configuring Printer Objects in Active Directory — Each of the printers in the pilot test was configured so that its location field would reflect its physical location. In order to prepare each printer for the pilot ITG made two configuration changes to each printer using the printer property dialog. (see Figure 3)
Configured the location field — ITG configured the location field by keying in text that describes where the printer is located (see Figure 3). The text that ITG entered in the location field was of the form Country/City/Building/Floor/Room Description.
Published printers to the Active Directory — ITG published the printers to Active Directory by selecting the "List in the Directory" check box located on the sharing tab of the printer properties dialog. Employees can search Active Directory for printers that ITG has published. Printers that are shared but not listed in Active Directory can be accessed remotely. However, such printers will not appear in response to Active Directory queries.
Figure 3 illustrates the printer properties dialog and modifications made to a single printer to reflect the physical location USA/Issaquah/SAMM-B/Floor2/Mail copy room.
.gif "Bb742603.wn2kdp03(en-us,TechNet.10).gif")
Figure 3: Example modifications to printer configuration using the printer properties dialog
Usability Testing of Configuration
Usability testing was an important aspect of the pilot, enabling ITG to sanity-check its configurations and choice of printer location naming convention. This helped to ensure that everything worked properly and that employees could understand the printer location naming convention ITG decided on.
Employees were chosen to participate in the pilot based on their physical location to printers that ITG had already configured and published within Active Directory. Once ITG had Active Directory properly setup for testing, they sent e-mail to these employees informing them of the new functionality and how they might begin to use it immediately. Specifically, ITG asked the group of internal testers to use the Add Printer Wizard, included with Windows 2000 Professional, to locate and install a printer close by.
Figure 4 illustrates the graphical user interface of the Add Printer Wizard.
.gif "Bb742603.wn2kdp04(en-us,TechNet.10).gif")
Figure 4: Add Printer Wizard integrated into Windows 2000 Professional
Note that the Add Printer Wizard was executed from the Start menu (Start, Settings, Printers, Add Printer). Note also that when a user of the Add Printer Wizard selected "next," the "Find Printers" query page was displayed. Initially, the location field displayed the message "Checking…" While this occurred, the query form determined the network subnet on which the Windows 2000 Professional client was located. The subnet location of the client was then used to determine the default printer location query string through a query to the Windows 2000 Active Directory service for the location string associated with the network subnet. Suggesting a suitable printer location query string in this way, was found to greatly reduce confusion and simplify the process of locating printers close by.
In Figure 5, Windows 2000 Professional suggests USA/Issaquah/SAMM-B automatically, through the interrogation of network subnet and Active Directory. The query results shown in Figure 6 were obtained by selecting "Find Now" using the suggested, or default printer location query string USA/Issaquah/SAMM-B. The query returned a list of printers that are on the same network subnet as the Windows 2000 Professional client.
Employees who run such a query used its results to easily add a connection to a printer that was close to them. In addition to searching for printers according to their location, employees searched by criteria such as color capabilities and print speed. By combining selections such as location and capabilities, employees made the best use of shared printers while finding one that best served their immediate need.
Figure 5 shows a list of recommended printers. The recommended list was specific to the employee and based upon the results of a query to Active Directory.
.gif "Bb742603.wn2kdp05(en-us,TechNet.10).gif")
Figure 5: Query results of USA/Issaquah/SAMM-B
Employees added printers simply by selecting a printer name from within the query form. Windows 2000 Professional then established a connection to a corporate print server running Windows 2000 Advanced Server, which automatically downloaded, installed, and configures a suitable printer driver. This automatic download process essentially eliminated the need for employees to spend time searching for a printer driver. The process also ensured that employees had a properly configured printer connection and that print quality was high.
Results
As a result of the pilot, ITG was able to review printer-management business practices, sanity-check its configuration of Active Directory, and assess the results of listing Printers in the Active Directory for the benefit of employees. Not surprisingly, two results stood out in particular:
Employees found nearby printers easily. By publishing Printers in Active Directory, ITG made it easy for employees to locate nearby printers in under a minute. In fact, some employees learned for the first time that they had a diverse collection of printers from which to choose.
Employees found other printers easily, too. Employees not only found nearby printers easily, they also found printers in other locations just as easily. Although the Add Printer Wizard initially suggests that users search Active Directory for printers located nearby, the wizard also permits the user to backspace over the suggested search string and enter another printer location query instead. This functionality also made it possible to locate printers in close proximity to some other point of reference, such as an office or computer lab.
Lessons Learned
ITG staff and others learned a lot from the experience of pilot testing printer location tracking. For example, ITG staff learned how the technology must be configured and how configuration choices might affect employees across the company. The following elaborates on some of the key lessons learned:
Agreeing on a standard naming convention was challenging. Developing the initial location naming convention was challenging because of the global nature of employees and printers at Microsoft. To be able to recommend a naming convention that was usable company-wide, ITG had to learn where every printer was physically located, and come up with a recommendation that would be easy for users. In turn, to do this they had to conduct an audit to determine the countries, cities, buildings, building floors, and rooms in which printer were located. ITG also had to evaluate the corporate network to determine the physical scope of each network subnet, that is, to learn how many printers resided on each subnet.
Agreeing on a standard naming configuration was made even more challenging because of the need for collaboration and agreement across multiple groups within ITG. Network-support staff preferred a convention that would make its jobs easier, while end-user support staff preferred a convention that would simplify the task of locating printers. In the end, staff agreed on the latter approach, on the grounds that it would result in the greatest gains in employee efficiency across the company.
Publishing printers in Active Directory turned out to be easy. Publishing printers within Active Directory was such a simple administrative process ITG was able to make the functionality available to employees without disruption to the company. For its pilot testing ITG was able to publish all the printers of a building, then simply instruct employees within the building via e-mail how to search for printers located closest to them.
Printer naming conventions need to be practical. Traditionally at Microsoft, legacy printers have been named after a Windows NT-based server that might be located nowhere near the printer. While this naming convention made sense to administrators who worked on the print servers, it made no sense to employees. The pilot testing of printer location tracking demonstrated not only how easy printers are to locate, but the exercise also helped to point out how inefficient the old approach to naming and finding printers had been. Currently, ITG has published printers in Active Directory using a naming convention that is meaningful to them and to other employees.
Recording printer locations must become part of the existing work flow. Since the advent of DHCP-capable printers, ITG has had little reason to record where every printer is located. That's because DHCP technology enabled ITG staff to move printers freely from place to place without having to worry about whether they would continue to work properly. But now, to develop a standard naming convention for printers so that employees can consult Active Directory to locate those printers, ITG staff must make it standard practice to keep track of those locations.
Future Direction
Currently printers from more than seven buildings on the Redmond campus have been published within Active Directory using the method ITG developed while pilot testing. In the future ITG will publish additional printers within Active Directory on a building-by-building basis until all printers company-wide have been published.
Publishing printers within Active Directory is key to supporting Microsoft's mobile work force. With the printer-location-tracking capabilities of the Windows 2000 Advanced Server and Windows 2000 Professional operating systems, mobile employees at Microsoft can easily access the printer of their choice from wherever they happen to be working on any given day. For example, if they need a printer with special graphics capabilities, they can easily locate it, whether they are working in their usual office or elsewhere. If they are working at a new office, they can easily learn the location of the nearest printer to them. Alternatively, if they are preparing documents for a presentation at an office that's several hours travel time from them, they can have those documents printed out on a printer at that office while they are en route.
They can do all this because ITG will use the Active Directory service of Windows 2000 Advanced Server and Windows 2000 Professional to list information about the location and capabilities of hundreds of printers throughout Microsoft. As ITG expands this list, more and more employees will be able to find printers based on their location and/or capabilities. This approach not only will help employees use the printer technology at Microsoft more efficiently, but also may help employees to collectively share documents more efficiently with each other since printers close to one another will become much easier to locate.
Intellimirror Management Technologies
Business Problem
To keep support costs low and user satisfaction high, ITG strives to identify areas with room for improvement inside Microsoft's internal computing infrastructure. This approach was especially applicable in the deployments of Windows 2000 Professional and Windows 2000 Advanced Server. For those deployments, ITG carefully reviewed existing system designs and identified areas where new technology could be used to increase productivity and lower the total cost of ownership.
One such area was obvious due to its sheer size: The number of desktop computers. Microsoft has more than 90,000 of them within the company. Slightly more than half of them are employees' primary desktop computers, while virtually all the rest are used for testing beta software.
Microsoft employees rely on computers to perform their day-to-day job functions. Even though most of these employees are technically sophisticated, few of them have the time to troubleshoot installation and configuration issues. This is because a large part of troubleshooting involves searching for the installation locations of needed software. ITG planners estimate that Microsoft spends more than $400,000 annually on helpdesk support calls from employees trying to locate the software they need to do their jobs.
Money had also been spent to ensure that employees have adequate hardware needed to backup desktop computers. Microsoft has spent up to $800,000 each year procuring Jazz drives, Zip drives, and other backup equipment so that employees can backup desktop computers own their own.
As part of the internal deployments of Windows 2000 Professional and Windows 2000 Advanced Server, ITG identified features of IntelliMirror change and configuration management technologies that could be used to simplify support, make employees more efficient, and save the company money.
ITG was interested in two features in particular: My Documents folder redirection, which is a User Data Management feature, and Application Publication, which is a Software Installation and Maintenance feature. ITG was interested in My Document folder redirection because the feature makes possible a secure and cost effective backup solution for users of Windows 2000 Professional. Application Publication was viewed as a cost savings feature as well, since the feature makes it possible to reduce time locating applications.
Because those features and technologies were in beta, documentation was not yet adequate to support the deployment company-wide. In response, ITG did extensive hands-on work or pilot testing to ensure that the beta would be sufficiently scalable and reliable before beginning the company-wide deployment. The following text discusses the steps ITG had taken to perform the pilot testing prior to beginning the company-wide deployment of IntelliMirror management technologies.
Pilot Scope
By pilot testing the IntelliMirror management technologies, ITG hoped to accomplish the following goals:
Validate that IntelliMirror functionality would be beneficial to a wide user base
Learn how to deploy and support My Documents folder redirection.
Learn how to deploy and support Application Publication
Test the beta of IntelliMirror management technologies to ensure that they scale up to a large enterprise environment.
Report issues to product development so that those issues would be resolved before product release.
Develop an operations framework for deployment and support.
Develop an end user communication and training framework for deployment and support
Demonstrate that the technologies could scale to five hundred concurrent users and then proceed with a company-wide deployment.
ITG conducted its pilot testing of IntelliMirror management technologies in an environment consisting of the following:
A Windows 2000–based Active Directory directory service running in mixed mode.
Five hundred desktop computers running Windows 2000 Professional.
Dedicated file servers running Windows 2000 Advanced Server.
To kick off the pilot ITG asked five hundred employees to use the technologies as part of their day-to-day work. Planning, strategizing, and developing the operations framework for deployment and support was carried out by planners from the following areas within ITG:
Helpdesk.
Windows 2000 Active Directory deployment planning and strategy.
IntelliMirror management technologies planning and strategy.
Windows 2000 Active Directory security strategy.
Pilot Implementation
ITG needed to build a pilot test environment that would allow them to evaluate the technologies to determine which of those technologies it would use company-wide. ITG needed to understand how to deploy and support those technologies, as well as select the technologies that best supported the way that employees within the company need to work.
Training and Support
In preparation for deploying widely, ITG developed an operations framework for support, during the pilot. The operations framework for support calls for a self-help-based knowledge center (and training helpdesk technicians in the concept) and a multitier support structure within ITG.
To build the knowledge center for deployment of the IntelliMirror management technologies, ITG used Internet Information Server and the Hypertext Markup Language. As ITG was called upon for support they documented issues and then published the information to an Intranet-based knowledge center. Providing ample self-help is one approach that ITG uses to drive down support costs, while increasing employee satisfaction.
ITG used a three-tier support structure during the pilot. This approach streamlined problem resolution through the assignment of simple problems to less-experienced staff and more challenging problems to expert staff. It also enabled the less-experienced staff to build skills on the job without getting in over their heads, and it enabled expert staff to stay abreast of technology to focus on developing self-help-based knowledge centers and training tools.
First-Tier Support — Responsible for taking initial internal support calls and troubleshooting basic problems such as monitoring disk space and checking Group Policy applied correctly.
Second-Tier Support — Responsible for resolving any issues that first-tier support could not resolve quickly. Also responsible for automating day-to-day work performed by first-tier support, adding new content to the knowledge center, and monitoring backup and restore processes.
Third-Tier Support — Responsible for resolving any issues that second-tier support could not resolve quickly. Also responsible for advanced troubleshooting and diagnostics and for resolving issues related to Windows 2000 Active Directory, networking, and implementing Group Policy. Third-tier support was also responsible for informing internal users when upgrades and maintenance would be needed.
Pilot Testing My Documents Folder Redirection
The pilot testing of My Documents Folder redirection involved the following tasks:
Building dedicated Windows 2000–based file servers.
Adding internal users to the pilot.
Activating the Windows 2000 Group Policy Objects.
Developing user-awareness and feature-awareness campaigns.
Building Dedicated File Servers — The My Documents folder residing on computers running the Windows 2000 Professional operating system is the default location for storing data and text files associated with Microsoft Word, Microsoft Excel, and a wide variety of other applications. Although the My Documents folder is typically associated with local disk storage, the IntelliMirror management technologies integrated into Windows 2000 enables administrators to "redirect" the My Documents folder to virtually anywhere in the company. ITG views this redirection capability as key to providing a cost effective backup solution to employees who want to take advantage of it.
A locally stored "My Documents" folder within the users profile is moved to the server. Mobile clients were advised to make the folder available offline so they could access it if the network became unavailable. (Note: When working online, access to the My Documents folder is by way of the server itself.) For example, in Figure 6 a number of My Documents folders are shown residing on a server and optionally cached locally. Client computers are running the Windows 2000 Professional operating system, and the file server is running the Windows 2000 Advanced Server operating system.
.gif "Bb742603.wn2kdp06(en-us,TechNet.10).gif")
Figure 6: Locally stored and redirected My Documents folders
For pilot testing, ITG used a dedicated file server with 50 gigabytes of storage, and running the Windows 2000 Advanced Server network operating system. ITG built the file server based on the assumption that 100 megabytes of storage would be sufficient for each user during the testing. For performance and reliability, ITG configured the file server to use hardware RAID 5.
Because My Documents folder redirection uses built-in Windows 2000–based file-sharing technology, ITG had no need to add or configure Windows 2000 services to enable the feature. Instead, ITG used the Advanced Folder redirection capabilities of Windows 2000 Group Policy to add a security group for each path of the network shares they created. Then, on each network share, ITG granted the group "Everyone" status for Read, Execute, and List folder contents the security group for the network share was granted full control. Last, they enabled automatic caching of documents, on their Windows 2000-based file server.
As it turned out, ITG found enabling automatic caching of documents to be very straightforward. As they created each network share they also enabled the settings through the Computer Management Microsoft Management Console snap-in included in Windows 2000 Advanced Server as seen in Figure 7.
.gif "Bb742603.wn2kdp07(en-us,TechNet.10).gif")
Figure 7: Automatic Caching of Documents
Adding Internal Users to the Pilot — Once ITG built the pilot testing environment, they developed a process to add internal users to the pilot. This process involved first creating Windows 2000 Global Security Groups and then adding internal users to the groups.
ITG created the Windows 2000 Global Security Groups through the Users and Computers snap-in of Active Directory. They then created a new Global Security Group for each network share they created. See Table 4 for more on how ITG correlated Global Security Group names to the network-share paths.
Table 4 ITG's correlation between Global Security Group names and network-share paths
Global Security Group Name |
Network-Share Path |
|---|---|
GP-sdt-ZAW1-MyDocuments-1 |
\\ZAW-1\MyDocuments-1\%username% |
GP-sdt-ZAW1-MyDocuments-2 |
\\ZAW-1\MyDocuments-2\%username% |
GP-sdt-ZAW1-MyDocuments-3 |
\\ZAW-1\MyDocuments-3\%username% |
GP-sdt-ZAW1-MyDocuments-4 |
\\ZAW-1\MyDocuments-4\%username% |
GP-sdt-ZAW1-MyDocuments-5 |
\\ZAW-1\MyDocuments-5\%username% |
GP-sdt-ZAW1-MyDocuments-6 |
\\ZAW-1\MyDocuments-6\%username% |
When ITG created each of the Global Security Groups, they also edited preferences for the redirection of the My Documents folder. They decided to select the "move contents" check box (as illustrated in Figure 8), because they wanted a way to later create another Security Group and redirect existing folders to another location. In other words, they planned ahead for the problem of running out of disk space. When disk space became full, ITG created another Security Group with a new path and then populated that group with users. Windows 2000 then "moved" existing folders and their contents from the original location to the new location provided by ITG. This approach enabled administrators to avoid having to copy the folder contents manually. (Note: As a policy, ITG strives to keep internal users informed of behind-the-scenes activities such as moving user data from one location to another, by sending those users e-mail)
To increase folder security ITG decided to select the "grant the user exclusive rights to My Documents" check box as seen in Figure 8, to ensure that only the folder owner would be able to view the folder contents.
.gif "Bb742603.wn2kdp08(en-us,TechNet.10).gif")
Figure 8: ITG's My Document folder redirection preferences
In preparation for the pilot ITG created each Security Group and then "disabled" it, that is, made it inactive. The benefit of this approach was that ITG was able to set up each Security Group without having to immediately put it to use. ITG would later "enable" each Security Group shortly before the testing of My Documents folder redirection was to get under way.
After creating all the required Global Security Groups, ITG assigned up to 200 internal users to each security group. ITG imposed this limit so as to decrease the likelihood of a folder from becoming full. (Note that 50GB of storage was allocated to the 200 users)
In addition, ITG planned for unforeseen events by adding the names of its pilot testers to Exchange 5.5 e-mail distribution lists so they could easily communicate about any issues they were having. The distribution lists were organized so that members of the distribution list corresponded to logical partitions, with each distribution list following a one-to-one correspondence with a Global Security Group (for more detail see Table 5). ITG made the distribution lists secure, so that only an administrator of IntelliMirror may mail the distribution lists.
Table 5 Correlation between Exchange 5.5 distribution lists and Global Security Groups
Domain Account |
Distribution List |
Alias |
Global Security Group |
|---|---|---|---|
Alicia |
ITG ZAW1 MyDocuments-1 |
ITZ1D1 |
GP-sdt-ZAW1-MyDocuments-1 |
Alan |
ITG ZAW1 MyDocuments-1 |
ITZ1D1 |
GP-sdt-ZAW1-MyDocuments-1 |
Albert |
ITG ZAW1 MyDocuments-1 |
ITZ1D1 |
GP-sdt-ZAW1-MyDocuments-1 |
Frank |
ITG ZAW1 MyDocuments-2 |
ITZ1D2 |
GP-sdt-ZAW1-MyDocuments-2 |
Jan |
ITG ZAW1 MyDocuments-3 |
ITZ1D3 |
GP-sdt-ZAW1-MyDocuments-3 |
To streamline communications from administrators to users, ITG also compiled all the distribution lists into a master list (as shown in Table 6). Through the master distribution list administrators could communicate en masse, for example, when they needed to upgrade the servers. Through individual distribution lists, administrators could communicate more to a targeted audience, for example, when they needed to inform users a logical partition was nearly out of disk space.
ITG chose not to implement quotas on My Documents shares. This decision took into consideration ITG's legacy computing infrastructure and how ITG views employees will use My Document folder redirection in the future. For example, most groups within Microsoft have access to one or more file servers built for the purpose of retaining group project-data. Employees have chosen to store personal data, such as documents, on these servers.
In order to reduce costs associated with tape backup and retention ITG plans to segregate group project-data from personal user-data. This will permit ITG to base tape retention on the classification of the data being backed up. Group project-data is often retained for seven or more years, while personal user-data is only retained for thirty days. ITG has chosen not to implement quotas on My Document shares in order to ensure employees have adequate space to store personal user-data. It is thought that employees will be more inclined to use My Document redirection if they have ample storage for personal data. In short, disk-space is considered less expensive than retaining personal user-data for many years. Moving forward, segregation of data by classification is essential to further driving down support costs within the company.
Instead ITG plans to implement NetIQ alerts on the servers to notify ITG administrators of IntelliMirror when partitions approaches 25% of capacity.
Table 6 The addition of many aliases to a master alias for communications en masse
Nested Alias |
Added to Secured Distribution List Name |
Added to Secured Alias |
|---|---|---|
ITZ1D1 |
ITG Support for My Documents Redirection |
ITZ-EVERONE |
ITZ1D2 |
ITG Support for My Documents Redirection |
ITZ-EVERONE |
ITZ1D3 |
ITG Support for My Documents Redirection |
ITZ-EVERONE |
ITZ1D4 |
ITG Support for My Documents Redirection |
ITZ-EVERONE |
ITZ1D5 |
ITG Support for My Document Redirection |
ITZ-EVERONE |
ITZ1D6 |
ITG Support for My Documents Redirection |
ITZ-EVERONE |
Activating Windows 2000 Group Policy Object — ITG began its formal pilot testing of My Documents folder redirection when they "enabled" each of the Global Security Groups they had earlier created then immediately "disabled." This approach enabled ITG to identify product problems and report them to development for resolution before proceeding far with the formal testing. To activate each security group, ITG accessed Active Directory Users and Computers snap-in and made the group "active", by clearing the disabled flag.
User awareness and education campaigns — Another important aspect of ITG's pilot testing of the IntelliMirror management technologies was a series of campaigns designed to increase awareness among users and provide them education. ITG used two key approaches to user awareness and education: e-mail and the group's intranet Web site. E-mail was an important aspect of creating awareness, because ITG was able to configure My Documents folder redirection without user's being aware. Therefore ITG needed to let users know what features ITG had deployed by providing steps the user would need to make in order to begin to use the feature. The e-mail was key to how ITG initiated user feedback, by asking users to begin to take advantage of My Document folder redirection.
To begin its testing, ITG distributed e-mail to all users who were selected for the pilot test. This e-mail included the URL to the IntelliMirror management technologies intranet knowledge center and the aliases of users who could provide feedback. ITG also provided users detailed information on IntelliMirror management technologies so they would know what to look for.
Pilot testing Application Publication
Through the testing, ITG learned how to configure and administer the Application Publication and how to prepare applications for publication in a wider internal deployment.
To launch this part of the testing, ITG located application-installation routines, prepared applications for publication, and then edited a Windows 2000 Group Policy to publish each application. The following text discusses ITG's approach in each area.
Locate Application Installation Routines. ITG stores commonly used applications on dedicated file servers so that employees can locate them easily. To locate the installation routines for each application, ITG audited a half-dozen file servers, to build the list of applications to publish.
As part of the process of locating these routines, ITG classified each application according to its software licensing agreement. For example, Microsoft has site licenses for several third-party applications, while others are licensed for a specific number of users. ITG studied its records so as to determine exactly what each licensing agreement called for before the group began to publish applications.
Prepare Applications for Publication. ITG used a final classification to determine how best to prepare an application for publication. The classification was based on the design of the application-installation routines and the nature of the testing to be done. Table 7 illustrates the class of each application and the preparation required by ITG for each class prior to publication. As of the time of this writing the majority of applications published by ITG have been legacy applications published using a ZAW Down-level Application Package (ZAP) file. ITG refers to ZAW Down-level Application Package files, simply as ZAP files, because the file extension associated with the file is .zap.
Table 7 Classes of preparation requirements and applications
Preparation Class |
Application Class |
|---|---|
Native Windows Installer |
Application that uses Windows Installer as its setup engine. |
Repackage as Windows Installer |
Application that does not use Windows Installer as its setup engine. A Windows Installer repackaging tool has been used to take before and after snapshots of the files & registry settings changed by the non-Windows Installer setup. A Windows Installer package (.msi file) is generated from these changes. |
LEGACY |
Application that does not use Windows Installer as its setup engine. A legacy deployment file (given a .zap) extension) describes how to install the application. |
ITG used a third party tool called WinINSTALL LE to aid in repackaging applications for Application Publishing. ITG used WinINSTALL LE to create Windows Installer (.msi) packages for installing applications on Microsoft Windows 2000.
Edit a Group Policy to Publish Applications. ITG published applications to the Add/Remove Programs control panel by using the graphical user interface of the Group Policy editor snap-in invoked by the User and Computer Administration tools of Active Directory service.
First, ITG installed the administrative tools included with Windows 2000 Advanced Server through the Add/Remove Programs control panel. Second, they accessed Active Directory User and Computer Administrative tools. Third, they edited a Group Policy that was created by ITG security staff for the purpose of publishing applications for testing.
ITG prepared legacy applications for Application Publication, to test the publication of applications to the Add/Remove Programs control panel of Windows 2000 Professional.
To access the Group Policy User Interface (illustrated in Figure 9) from the User and Computer Administration tools, ITG did the following:
Right-clicked the Redmond.corp.Microsoft.com "container" to display the Properties page dialog box and selected the Group Policy tab of that dialog box.
Once the Group Policy tab was in view, ITG highlighted the Group Policy they wanted to modify and selected Edit to bring up the Group Policy dialog box. In this example, ITG decided to publish applications to users' Add/Remove Programs control panel. So they selected User Configuration and then Software Installation, before graphically dragging and dropping .ZAP and .MSI files (which they had created themselves) into the right pane as seen in Figure 9.
.gif "Bb742603.wn2kdp09(en-us,TechNet.10).gif")
Figure 9: Group Policy User Interface of Active Directory User and Computer administration tool
As ITG dragged and dropped the internally developed ZAP files, from a server share used for application deployment, into the Group Policy User Interface, the Deploy Software dialog box (illustrated in Figure 10) came into view.
.gif "Bb742603.wn2kdp10(en-us,TechNet.10).gif")
Figure 10: Advanced publishing or assignment dialog box
Advanced Publishing or Assignment was chosen to bring into view the dialog box illustrated in Figure 11. The Categories tab was then chosen to display a list of available categories under which the application could be published. Because the example is a line-of-business application, the Line of Business Applications category was selected (as illustrated in Figure 11). After selecting the Line of Business Apps category, the Security tab (illustrated in Figure 11) was selected, to apply security permissions to the published application.
.gif "Bb742603.wn2kdp11(en-us,TechNet.10).gif")
Figure 11: Advanced publishing properties for the example application
From the security tab, ITG granted permissions to internal testers first so that they could validate and verify that applications would install properly. After the application had been tested to ensure it had been published properly, ITG modified the security permissions to allow everyone else in the pilot to install the applications as well.
Figure 12 illustrates the Add /Remove programs graphical users interface, available to users running Windows 2000 Professional. Applications were published to all users who were participants in the pilot following testing. Internal users were then able to easily locate and install published applications through the Add/Remove programs user interface illustrated in Figure 12.
.gif "Bb742603.wn2kdp12(en-us,TechNet.10).gif")
Figure 12: Applications published to Add / Remove programs
Results
The completion of the pilot testing of the IntelliMirror management technologies revealed My Documents folder redirection and Application Publication to be two features ITG will take advantage of to enhance employee productivity by deploying company-wide. ITG based its findings not only on feature set and functionality but also on an understanding of corporate culture and the tools that employees need to become more efficient and stay that way. Below are a few of the more significant results:
Applications were published easily. The graphical user interface of the Group Policy administration tool made the process of selection and editing Group Policy an easy task. For example, the ability to drag and drop .ZAP and .MSI files into the user interface made Application Publication easy for administrators to do. In addition, security settings were applied quickly and Group Policy was displayed promptly.
My Documents contents were securely filed and stored. The pilot test revealed that My Documents Folder redirection appeared effortless and seamless to internal users. IntelliMirror management features redirected data across the network quickly. ITG found the redirected and locally cached data to be secure in the environment and surprisingly easy to back up.
Planning for capacity was simplified. Pilot testing the IntelliMirror management technologies better positioned ITG for a company-wide deployment. Based upon what was learned from the pilot test ITG decided to scale its production file servers to 300GB of storage.
Table 8 illustrates how ITG decided to scale its production servers by partitioning the available storage into logical drives, creating a folder on each logical partition, then sharing the folder across the network. Multiple shares per server will be used due to a corporate backup limit of 50GB/share per day. A backup schedule consisting of weekly full, and daily differentials (using a thirty day tape retention and rotation schedule) will be used in a later company-wide deployment.
Table 8 Server-side planning and construction
Access through share name |
Logical volume |
Storage |
For users whose e-mail names begin with: |
|---|---|---|---|
MyDocuments-1 |
D$ |
50 GB |
A – E |
MyDocuments-2 |
E$ |
50 GB |
F – I |
MyDocuments-3 |
F$ |
50 GB |
J – M |
MyDocuments-4 |
G$ |
50 GB |
N – Q |
MyDocuments-5 |
H$ |
50 GB |
R – U |
MyDocuments-6 |
I$ |
50 GB |
V – Z |
Deploying Windows Installer-based applications was found to be self-healing. Many of the applications that ITG published were packaged to use Windows Installer technology. Such applications can detect missing dynamic link libraries (DLLs) and then search, locate, and install the missing files without the need for user intervention.
Publishing self-healing applications required more time, but the benefits were obvious almost from the onset. ITG found that applications it published were able to recover from missing files. Some also were able to recover from missing or invalid registry settings. The Windows Installer–based applications were able to perform the recovery on their own by detecting the missing file and registry settings and recover from them by running their associated installation programs.
Lessons Learned
Based on its experiences pilot testing IntelliMirror management technologies, ITG was able to validate and confirm its deployment plans. ITG also was able to identify a number of challenges and their workarounds. Here are some the most valuable lessons ITG learned from the pilot testing of IntelliMirror management technologies:
It was important to work around simple problems before deploying widely. Many applications used at Microsoft depend on data files in order to run, load, and display information. Some of those applications search and locate required data files using a technique that can pose a problem when the data files are redirected. ITG tested and evaluated many applications to determine the effect to the application when the application's data file is redirected.
What happened was this: A few applications failed to function normally after staff redirected the folder containing the application's data files. As a workaround, ITG educated internal users not to put specific data files into redirected folders until the ITG developers resolved the problem. Most of the applications that failed did so for simple reasons, such as a hard-coded path to the data file in the registry.
Pilot testing in a small-scale environment was beneficial. ITG first pilot tested using a parallel environment consisting of dedicated test servers, Group Policies, Organizational Units, and a Windows 2000–based test domain. The test environment and the production environment both "trusted" one another so that users would be able to access other areas of the company. This environment was especially valuable because it allowed ITG to prepare for a later company-wide deployment without needing to build a very large infrastructure. The small-scale environment also helped ITG to gain experience and test theories before trying anything out in production.
Let My Documents folder redirection do the work. ITG staff learned that if they pre-created folders for people on their file server, My Documents folder redirection would fail. This is because redirection code checked the ownership of the folder when users logged on and, if the owner of the folder was not the assigned user, redirection failed. This design prevented non-administrators from gaining access to data by pre-creating another user's folders.
My Documents Redirection creates and initializes users' folders using the ACLs specified by the Security Policy Group. Properly setting the redirection path using the form \\servername\sharename\%username% will create the users' folders with the security ACLs specified automatically.
It was important to consider what each packaging method can do. As part of the pilot testing, ITG thoughtfully evaluated Application Publication to determine how the group should best make applications available within the company. As part of its evaluation, ITG compared Native MSI, Repacked MSI and legacy ZAP methods of packaging in order to understand the benefits of each method. As it turned out ZAP files were easy to create and use while learning. However, other packaging approaches were viewed to be better suited for real-world use.
With offline synchronization documents are available when the network is slow or completely unavailable. Microsoft employees routinely travel, and when they do they often don't have access to computers they frequently use. In the case of My Document folder redirection, employees are able to use the built-in offline synchronization capabilities of IntelliMirror to ensure that they always have the most recent documents stored locally before traveling. With synchronization the local My Documents cache is synchronized with the remote content, before logging off from the network. This feature ensures that employees are able to continue working with documents even when the network is not up to it. When employees logon to the network, modified files stored in their local My Documents folder are synchronized with copies located on a back-end server.
Considering how employees require technology and information is important. At Microsoft ITG continually strives to make services and technology available that will save money and better support the way employees work. ITG closely examined employee needs, to ensure that in the end, employees company-wide would benefit from its approach at deploying and configuring Windows 2000 Advanced Server. In the case of My Document folder redirection, ITG decided to make that technology available to employees who request it. This allows ITG to properly add users to e-mail distribution lists, while performing other configurations needed to make the service available. ITG then is able to scale its servers at the time employees are given the service. To increase employee satisfaction and reduce support costs, employees are provided instruction on how the service is used, what benefits it provides and any scenarios that should be avoided at the time they sign up.
Future Direction
While the majority of employees at Microsoft will benefit from the My Documents folder redirection and Application Publication features, other Microsoft employees will benefit from different IntelliMirror management technologies. For example, in other areas of the company ITG has identified groups of 100–200 users that are believed to benefit from other IntelliMirror management technologies. For these users, ITG will begin to pilot test Application Assignment Roaming User Profiles, and Remote Installation Services (RIS) to complement My Documents folder redirection and Application Publication already being deployed en masse.
Elsewhere in the company System Management Server (SMS) 2.0 is at use enhancing the desktop management capabilities made available by IntelliMirror management technologies. ITG currently has 13,000 SMS 2.0 clients running throughout Microsoft's corporate campus in the USA and another 1,500 running throughout Dublin Ireland. Within the next several months ITG plans to deploy SMS 2.0 to another 24,000 desktops where they plan to take advantage of asset management. Deploying SMS 2.0 widely will better position ITG to continue to take advantage of the product well into the future.
As of the time of this writing ITG has published over one hundred and twenty applications to Add/Remove programs control panel using Application Publication. ITG will continue to publish additional applications, making them easy for employees to locate and install. In the future ITG will make published applications available to employees who work in areas of the company outside of Microsoft corporate campus. In preparation for the company-wide deployment, ITG is planning to pilot test a Windows 2000-based Distributed File System, which it views to be beneficial in supporting users of IntelliMirror management technologies.
In the future ITG plans to use Software Installation and Maintenance technologies to simplify the deployments of virus-protection software and security updates by applying a Windows 2000-based policy at the domain level. In this way, vital software that requires the installation of a few files will be deployed to many machines quickly. Issues that are of security concern to Microsoft will most likely be resolved by machine assignment, where-as applications that install many files at once will generally be assigned to users. ITG also plans to use RIS, Application Assignment and My Document folder redirection together, to make machine replacement a simpler task to complete.
TAPI 3.0 Integrated Technologies
Business Problem
Just as computers are a key component of Microsoft's data-networking infrastructure, telephones are a key component of the company's telecommunications infrastructure. Both infrastructures provide vital links within Microsoft and between Microsoft and the rest of the world. Traditionally, however, they have been separate. This is because traditionally data networking and telecommunications have been based on such vastly divergent technologies that it had been nearly impossible to integrate them seamlessly.
Because such integration is so desirable within large enterprises, the Microsoft Windows 2000 operating systems includes features specifically designed to address the problem. One such feature is the Telephony Application Programming Interfaces (TAPI). As part of its deployment of Windows 2000 throughout Microsoft, ITG will enable computers running Windows 2000 Professional to control corporate telephone switches. The first step in this deployment, a series of pilot tests, is the subject of this section.
Pilot Scope
In their TAPI 3.0 pilot test, ITG sought to understand what would be needed to maintain, administer, and integrate TAPI 3.0 with existing phone switches. In the pilot ITG did this by adding TAPI 3.0 to a single phone switch that supported more than 1,500 employees in one building. The primary goal of the pilot was to understand the workflow process in move/add/change operations, needed to support TAPI enabled desktops.
Two ITG telecommunications experts were assigned to the pilot, which was designed to take place over a two-month period. One of the experts focused on understanding what would be needed to maintain, administer, and deploy TAPI 3.0, while the other focused on understanding what would be needed to integrate TAPI 3.0 with existing phone switches.
Because TAPI 3.0 was deployed while in beta, ITG had to partner with product-development engineers every step in planning and testing so they could be sure of prompt resolution of any problems that arose.
Pilot Implementation
To minimize the risk associated with evaluating beta software, ITG decided to base its pilot on its own telephones and those of product development, rather than on other employees. This approach would enable ITG to understand the issues involved in maintaining, administering, and deploying TAPI 3.0–based telephony without impact to anyone.
The hardware environment for this pilot test was very simple: a single Compaq ProLiant 1850R, two Ethernet cards, cables, and a location close to an existing Intecom Corporation phone switch were sufficient.
Here is how the hardware installation proceeded: First, engineers connected the primary network interface card to the Intecom phone switch using a private cross-connect cable. The private cross-connect is a special kind of cable that enables the networking of two computers without the need for a network hub or router. For all practical purposes, the wire appears identical to an Ethernet patch cable although the pins are wired somewhat differently. Next, the engineers cabled the secondary network-interface card to a Cisco ATM Catalyst for corporate network connectivity. Figure 13 illustrates this physical architecture.
.gif "Bb742603.wn2kdp13(en-us,TechNet.10).gif")
Figure 13: Physical Architecture
Third, the engineers installed Windows 2000 Advanced Server on the Compaq server. They configured the primary network interface card to use a static IP address and the secondary network interface card to use the Dynamic Host Configuration Protocol (DHCP).
As part of the default installation of Windows 2000 Advanced Server, the engineers also configured TAPI 3.0. A Telephony Service Provider (TSP) was acquired from Intecom Corporation and configured on the server running Windows 2000 Advanced Server. A configuration file had to be built for the Intecom TSP on the Intecom phone switch. This configuration file would make phone-device identification numbers available to TAPI 3.0.
Next, the engineers used the TAPI Administration Snap-in, included with Windows 2000 Advanced Server, to build a second configuration file on the server running Windows 2000 Advanced Server. This configuration file is necessary to associate Windows NT domain account information and network identification numbers with phone-device identification numbers.
Next, the engineers configured computers running Windows 2000 Professional to use telephony by running the Telephony Client Setup. Also known as tcmsetup.exe, this utility is included with Windows 2000 Professional and can be invoked from the command line. Once the engineers completed this setup, the employees connected to the phone switch used for the pilot could place calls by using the Phone Dialer application included in Windows 2000 Professional.
Here is how this was designed to work: The employee selects the name or phone number of the person he or she wants to call. In response, Phone Dialer instructs the TAPI server to go "off hook" and dial the specified phone number. The TAPI server refers to its configuration file to obtain the telephone-port ID number associated with the Windows NT domain account of the caller. The TAPI server then instructs the phone switch to take that telephone port number off hook and dial the specified phone number.
Figure 14 illustrates how a single user would put the pilot system to use.
.gif "Bb742603.wn2kdp14(en-us,TechNet.10).gif")
Figure 14: The pilot environment
ITG used an Intranet-based Web site to share frequently asked questions with employees who later participated in the pilot. Having helpdesk technicians participate in the pilot test to develop self-help-based solutions such as frequently asked questions is an approach ITG routinely uses to keep support costs low and user satisfaction high.
Results
As a result of pilot testing TAPI 3.0, ITG became competent with the technology, understanding what was needed to maintain, administer, and deploy the technology in their environment. Here are a few of the most crucial results of the pilot test:
Developed tools to simplify administration in their environment — ITG staff used the pilot as an opportunity to identify areas that could benefit from automation. For example, one such area lies in the management and maintenance of configuration settings on both the TAPI server and the phone switch. These settings are critical to a properly configured system. Each configuration file contains user telephone port settings that must correspond with the users' telephone ports in use at their offices.
At Microsoft, the phone system includes more than 68,000 dial-tone ports alone. Employees often change offices, and, as a result, more than 400 telephone ports must be changed each week. Each such change typically involves assigning an employee a different port number that corresponds to the telephone port assigned to his or her new location. To eliminate much of the management and maintenance associated with manually updating port settings on two systems, ITG developed an application with the Microsoft Visual Basic development system to automate the updating of those settings in their environment.
Improved integration with third-party phone switches — Microsoft uses telephone switches provided by Intecom Corporation inside the United States and switches provided by Nortel Networks for virtually everywhere else. Each phone switch integrated with beta software is a critical test bed to ensure that Windows 2000 Advanced Server and Windows 2000 Professional are enterprise ready.
Lessons Learned
Below are some of the key lessons learned as a result of the pilot test.
Adding desktop support for telephony did not disrupt users. ITG found that adding support for TAPI 3.0 to the existing telephone system was possible without disruption to users. Employees who chose to use this capability from their desktop were able to add support for the technology simply by running the Telephony Client Setup utility. Employees who chose not to use TAPI 3.0 for desktop telephony were free to not configure their workstation to take advantage of that technology.
Enterprise TAPI users must have accurate up to date inventory record. Most problems that ITG encountered with TAPI were related back to configuration issues, such as incorrect phone numbers, and network domain information. The process of granting a user access to TAPI requires that an administrator obtain the users Windows NT domain account, and telephone configuration. This information needed to be stored accurately on both the TAPI server, and the phone switch.
Convergence of data networking with telecommunications. ITG telecommunications experts considered the deployment of TAPI 3.0 as a convergence of traditional telecommunications and traditional data networking. Traditional telecommunications staff needed to learn about Windows 2000 Advanced Server support in addition to supporting traditional telecommunications equipment, such as proprietary switches provided by Intecom and Nortel. The pilot focused on leveraging computer systems staff with telecom staff to transfer knowledge between groups.
Future Direction
As of this writing, ITG has made telephony available to more than 2,200 employees through the process described in this document. Based on the success of this pilot, ITG telecommunications experts plan on making the technology available to an additional 26,000 desktop computers within the company before Windows 2000 is released.
By targeting a larger internal audience, ITG will broaden the internal testing of TAPI 3.0 to ensure that the product is scalable, reliable, and easy to manage in its environment. When they succeed, ITG will then deploy TAPI 3.0 within the Microsoft call centers. ITG views the deployment of TAPI 3.0 within the Microsoft call centers as vital to the redesign of those systems throughout the company. As such, scalability and reliability are critical to the success.
When ITG successfully deploys TAPI 3.0 in the Microsoft call centers, ITG plans to integrate customer data with phone calls, using TAPI 3.0. This will make it possible for support engineers to have more comprehensive information about each customer when they call so the support engineer will be able to assist customers and resolve issues more efficiently.
Conclusion
Pilot testing allowed ITG to plan and strategize the deployments of technologies that later become used more widely. The following are some of the key lessons learned that were common to each of the pilots discussed.
Understanding feature dependencies was key to scheduling. Most core technologies of Windows 2000 are dependent upon the availability of other base technologies. For example, pilot testing Printers in Active Directory, and IntelliMirror management technologies were dependent upon an Active Directory directory service being in place.
By understanding feature dependencies, deployment planners were able to prioritize pilot testing and other deployment activities. The understanding has helped ITG to reduce the number of people involved in the preparation and deployment planning. This understanding allowed ITG to have ample time to work out support issues, while continuing to perform other day-to-day responsibilities.
Parallel testing environment was beneficial. As a rule, all changes that needed to be performed were first tested in a parallel environment, built especially for such tests. The parallel environment was designed to closely resemble the production environment. The test environment was a very effective measure to mitigate the risk associated with deploying beta software and reduce disruption to the company.
ITG is deploying Windows 2000 while in beta, therefore ITG need to test incremental releases of the product in its parallel environment first to ensure that they did not introduce any instability in its production environment.
Early planning was key. Planning for a company-wide software deployment nearly always requires ITG to evaluate some of its business processes to determine how it could best make use of new technology. This has been especially true for Windows 2000 Professional, and Windows 2000 Advanced Server. Both deployments have benefited from early planning, and accurate and up-to-date asset management. Accurate and up-to-date records of physical printer locations, computers and network subnets have helped ITG to better prepare for company-wide deployments.
Early planning was also key in determining how roles and responsibilities of groups need to change in order to take advantage of the discrete delegation of administrative authority of Active Directory. ITG plans to take advantage of this, by delegating authority to people who need it, so that issues are resolved faster and with higher employee satisfaction than ever before.
Future Direction
The pilot testing of integrated Windows 2000 technologies was a vital step in ITG's deployment planning and strategy. The pilot testing allowed ITG to learn about the technologies, plan for their support and deployments, and to identify areas of the company that would be key to deploy those technologies.
In the coming months, ITG will continue to deploy the technologies discussed in this paper throughout the company, and will complete pilot testing of other key technologies. ITG expects that the results of its planning, and deployments will increase employees' efficiency and productive, save the company money, and create a more robust computing infrastructure.
For More Information
Latest information on Microsoft Windows 2000 Advanced Server and Windows 2000 Professional can be found at: https://www.microsoft.com/windows
To view additional IT Showcase material, please visit https://www.microsoft.com/technet/itsolutions/msit/default.mspx.
For any questions, comments or suggestions on this document, or to obtain additional information about Microsoft IT Showcase, please send email to showcase@microsoft.com
Appendix
The following is an example of a ZAW Down-level Application Package (ZAP) template ITG used. ITG customized the template for each of applications tested. Other forms of packaging such a repackaged Windows Installer or native Windows Installer were found to have greater benefit to employees. However, the ZAP templates were found to be easy to create and use while learning about Application Publication.
; FriendlyName and SetupCommand are the only required keys in the Application section.
; Email contact: <your alias>
[Application]
FriendlyName = Winsock Proxy 2.0
DisplayVersion = 2.0
SetupCommand = \\sample-file-server\sample-share\SETUP.EXE
Publisher = Microsoft
URL = https://microsoft/proxy1
; The [ext] [CLSIDs] and [progIDs] sections are all optional
[ext]
; note you can put a dot in front the extension or leave it out
; text after the first = is optional and ignored
; but the first = is required (or the whole line will be ignored)
; example:
; XLS=
[CLSIDs]
; all key words are case insensitive
; CLSIDs should have LocalServer32,
; InprocServer32, and/or InprocHandler32 after the =
; examples:
;{00000000-0000-0000-0000-000000000000}=InprocServer32,InprocHandler32
;{12345678-1234-1234-1234-1234567890ab}=LocalServer32
[progIDs]
;example:
;{00000000-0000-0000-0000-000000000000}=word.document.8