Windows 2000 Lab System Upgrade: Good Idea, Bad Idea?

Size: px

Start display at page:

Download "Windows 2000 Lab System Upgrade: Good Idea, Bad Idea?"

Morgan Copeland
5 years ago
Views:

1 Windows 2000 Lab System Upgrade: Good Idea, Bad Idea? Jesse Ballard University of Wyoming P.O. Box 3945 Laramie, WY (307) James Osborn University of Wyoming P.O. Box 3945 Laramie, WY (307) ABSTRACT In order to keep on the leading edge of technology and to take advantage of new administrative features, we at University of Wyoming decided to upgrade our Windows NT 4.0 lab system to a Windows 2000 based lab system. This paper will detail the planning that went into this project and the numerous issues that were faced. Some of the planning topics that we will discuss are: Hardware requirements and the need to upgrade machines Software testing and the need to find updated versions, or replace legacy programs Political ramifications of such a campus-wide upgrade Developing a workable time-line for the upgrade process In addition to detailing the planning process of the upgrade, we will also discuss some of the problems and issues encountered during the first stages of the upgrade process. Keywords Windows 2000, upgrade, lab system, operating systems 1. INTRODUCTION In August of 1999 the Academic Support Unit at the University of Wyoming began investigating the logistics involved in migrating to the then future Microsoft Windows 2000 platform. We began looking into the operating system upgrade with specific technical questions in mind, but as we examined the upgrade process it became very clear that there were several more issues than just technical details that would need to be resolved. Convincing the campus community of the need to move to the new operating system and obtaining the funds needed for the upgrades appeared to be the two significant concerns we faced. We decided early on in the process not to force the upgrade LEAVE THIS TEXT BOX IN PLACE AND BLANK of Windows 2000 onto the academic computing labs, but rather present the upgrade as an option. Once the option was presented, we then proceeded with the upgrade based on the feedback received from the various colleges, departments and computer committees. Upon deciding to go forward with the migration to Windows 2000, we again began looking at the technical concerns involved with the upgrade. Many issues have been raised so far in the process and at the writing of this paper even more are being discovered. Communication between internal units of Information Technology (IT) and also with outside departments has been key in making sure that the issues and problems that arise are addressed in a timely manner. As technical concerns have arisen, budgeting factors have become evident and the need to find reliable sources to fund the upgrade has been necessary. We wanted to avoid having to rely on year-end funds to finance the upgrade, because year-end funds are not a guaranteed source. Funding has been provided through a variety of computer fee committees and Information Technology. At the writing of this paper, the upgrade process has not been completed and will not be until the beginning of the Fall 2000 semester, which, for the University of Wyoming, is the last week in August. This paper focuses on the issues, both technical and non-technical, outlined above that the Academic Support Unit has faced so far in the upgrade process. It is hoped by thoroughly planning the upgrade, starting almost a year in advance of its completion, we will be able to predict and avoid numerous problems that can arise with such a significant change in our lab system. 2. Background In the Fall of 1997 the support and the funding sources for Academic Computing at the University of Wyoming were completely revamped with the introduction of a student computer fee. With the introduction of a computer fee, the University also established student majority fee committees to govern the decisions on the use of the computer fees. The fee structure was established so each student pays $20 a semester to his or her individual colleges and $20 a semester to a central source. Each individual college established committees to govern college fee monies and a central committee, overseen by an IT chair, was established to oversee the use of the centralized funds. Each

2 college committee has one student and one faculty member that represent their college on the Central Student Fee Committee (CSFC). The exception is the A&S college committee, which has two student and two faculty representatives because it has proportionally twice the enrollment of the other colleges. The CSFC also took on the role of overseeing the actions of the various college committees to make sure that student computer fee money was only being expended to benefit the student computing on campus and not being used for other purposes. To help define what the various computer fee committees roles were designated to be, the CSFC created operating guidelines which all the college committees, along with the CSFC, must follow in their spending of computer fee monies. With the advent of the computer fee committees IT s support of Academic Computing was also adjusted. The Academic Support Unit within IT became the acting arm of the CSFC and college committees. Four full time employees and around 80 student employees make up the Academic Support Unit. Of the full time employees, there is a working manager, a lab coordinator, a training consultant, and a ResNet consultant. Of the 80 student workers there are 4 lab technicians, two ResNet technicians, one office assistant and around 75 Lab Assistants. In addition to the Academic Support Unit, development and support of the lab system is also provided through the PC Team in IT s Telecommunication and Systems Support Services area. The members of the PC Team are responsible for the servers, the base configurations of the workstations and the development of the UWStudent domain. The PC Team is also responsible for the installation and support of any server-side software that is placed on the domain. Since the Fall of 1997 at the University of Wyoming, we have been running a lab system composed of a NT Domain structure and NT 4.0 workstations. In our lab system, we effectively use roaming profiles and student storage for over 10,000 accounts. With the roaming profiles, students are able to make changes to their accounts on one machine and move to another machine with the changes following them. This use of roaming profiles allows students to retain mail configuration settings, specific backgrounds, drive mappings, etc. With the need to meet changes in class requirements and to upgrade the lab system with current releases of software, we completely rebuild all lab nodes twice a year. The two rebuilds are in December, between the Fall and Spring semesters, and in August, just before the beginning of the Fall semester. To do the rebuilds on our 700+ lab nodes in a timely manner, we use an imaging software called Ghost. This software allows us to create a base image of one PC and then distribute that image to hundreds of other PCs. 3. Why Upgrade When we first began looking at Windows 2000 as an upgrade to our current NT 4.0 lab system the first items we needed to identify were the benefits to the new OS. We needed to find out why we wanted to upgrade. The first reason behind the upgrade was to correspond with a section of the CSFC Operating Guidelines that states that in order to stay current and emulate industry standards, software will be upgraded on a 3 year rotation cycle. Since our NT 4.0 lab system came into existence in the summer of 1997, the upgrade to Windows 2000 in the summer of 2000 fits exactly in with the required rotation cycle. Windows 2000 offers a variety of administrative features that made it very attractive to the PCTeam personnel as well as the Academic Support Unit. In the architecture of a Windows 2000 domain, the need for domain servers is replaced with Active directory servers. An active directory structure in our UWStudent domain, allows us to do a variety of administrative tasks that were not possible in Windows NT4.0. Some of the features we plan on incorporating in the lab system are: Organizational Units to set specific policies and permissions for individual lab machines as well as groups of users. Kerberous authentication for both our NT Domain and Unix accounts. This will eliminate the need for two separate accounts and passwords. Group policies to grant fine-grain control to various entities without having to give them all or nothing. Security configuration templates to control file and directory level security on the local workstations. The Plug and Play capabilities of Windows 2000 are a very attractive feature to us in the Academic Support Unit. With Windows 2000 plug and play capabilities, we will no longer need to build Ghost images for specific types of hardware, instead we can create images based solely on the software loaded in a particular lab without the need to worry about the variety of sound cards, video cards and network adapters that plague us in our NT 4.0 lab system. To date, all of the hardware devices present on all the machines that will be running the Windows 2000 lab system have drivers included with the Windows 2000 media. In Windows 2000 we also have the ability to add drivers to our server side media for hardware that does not currently have drivers included with Windows Microsoft has recognized the use of imaging software to distribute operating systems and with Windows 2000 it has included a program called sysprep that automates the routine tasks that need to be completed after dumping down an image. Tasks that sysprep helps run are: changing the SID, changing the machine name, setting the admin password and running the plug and play setup routine again to find the drivers specific to the hardware on the computer. 4. Support and Approval Needs Even though we as the Academic Support Unit saw the benefits of moving to the Windows 2000 platform, we still needed to get approval from various campus entities to go ahead with the upgrade. The first group we needed to obtain approval from was the PC Team, since they would be responsible for the server side support and helping us create the base workstation images.

3 Fortunately the idea of upgrading to Windows 2000 was a joint venture between the Academic Support Unit and the PC Team. In obtaining approval from the PC Team to go ahead with the upgrade, we did not have to detail why the upgrade would be a positive move, but rather show that we had the support of the administration and the computer fee committees. Once receiving the support of the PC Team, on the condition that the project would be supported by the other entities involved, our next task was to obtain approval from the CSFC. Again we were fortunate in the fact that the CSFC operating guidelines stated that software was to be upgraded on a 3-year rotation cycle. Because of the guidelines, our task of convincing them of the need to upgrade was greatly lessened, but we still had to provide information on the benefits to moving to the new OS. In addition explaining the benefits of the new OS, we also had to provide the committee with the costs that would be associated with the upgrade. The costs associated with the upgrade of the lab systems were not small. In addition to the cost of licensing the new software, hardware upgrades were also needed on a variety of machines. Like other Microsoft OS upgrades, the minimum requirements had been raised above what was needed to run NT 4.0. Previous to the Windows 2000 upgrade, our minimum requirements were: Pentium 100 MHz or greater 32 MB of RAM 2 GIG Hard Drive With the upgrade, we changed the minimum requirements to: Pentium 166 MHz or greater 64 MBs of RAM 4 GIG Hard Drive The CSFC agreed to fund the upgrades for the machines they were responsible for. Also, by agreeing to fund the upgrade on their machines, the CSFC also set a precedent that the other committees would also fund the needed upgrades for the college controlled labs. By having a student-controlled committee commit to the upgrade, the pressure on IT from other campus departments was greatly reduced because it was seen as a decision the students supported and were willing to fund. In presenting the proposed change to the lab system to the various colleges and departments we never received negative feedback, or refusal to fund the needed upgrades. 5. Informing the Campus of the Change Once approval was given to go ahead with the project, and funding was obtained, our next task was to inform the campus of the upcoming change. In looking at how to inform the campus of the upgrade, we established a list of core groups we wanted to contact. The first groups contacted were the individual college committees. Even though all the college committees had representatives on the CSFC, we wanted to make sure the information regarding the change was available to all members of the committees. In communication with the college committees we made sure to do full inventories of the machines they supported and provided them with a detailed list of what would need to be upgraded or replaced. In the information we provided to them, we also made sure to include estimated cost of upgrades and if replacements were needed, we tried to provide them with those costs as well. Since computer committees do not control all the computer labs that run the UWStudent lab system, we also needed to provide various individual departments with upgrade information. We distributed this information by identifying the responsible parties, which in most cases were individuals, and meeting with them directly. In these meetings we provided them with cost estimates on the upgrades and also explained to them how the new system would run. We also recognized the need to inform as many faculty members of the upcoming changes as we could. By alerting faculty of the changes, we educated them on their need to make sure software they submitted was Windows 2000 compliant. We alerted the faculty by sending a generic to a faculty listserve that is in place at UW. We were also proactive in contacting all the faculty members that are currently running programs on our NT 4.0 lab system. We contacted these faculty members to make sure their programs were Windows 2000 compliant and also to see if they had upgrades for us to implement. In our testing to date, if a program is able to run under NT 4.0, it is possible to get it to function under Windows But, as always it is best to be safe and inform the faculty members of the change. Another group we needed to inform of the changes were departmental consultants within IT itself. The departmental consultants needed to be informed so when faculty members questioned them on the upgrade they could provide educated answers, or direct them to those who could. Also, in the past, when the Lab system has undergone a major change, such as moving to a new OS, faculty members tend to want to follow the change and upgrade their own PCs. 6. Gathering Info The need to gather information regarding Windows 2000 and the proposed upgrade has come in three stages. Two of the stages we have completed at the writing of this paper and we are currently in the middle of the third stage. The first stage of information gathering focused on obtaining information about Windows 2000 itself. In order to make an educated decision on upgrading to Windows 2000 we needed to be aware of what changes would occur in the upgrade, if it would be cost effective to implement and if our current resources were up to the task. To gather this information we turned to various reviews of Windows 2000, examined the latest releases of the Betas, talked to peers who were also looking at upgrading, and also obtained information from various vendors when it was available. Microsoft itself provides a variety of information on the differences between NT 4.0 and Windows In looking at

4 many of the white papers that they published, we were able to get a good feel for how things would change and what concerns would arise. The second stage of information gathering focused on our internal setup and identifying what hardware would need to be upgraded and/or replaced. Unfortunately not all of the labs that run the UWStudent lab system have uniform machines. The computer vendors vary from Gateways, to Digitals to Compaqs. In order to determine whether the hardware on all the machines were compatible with Windows 2000 we had to do an inventory of the entire lab system. In this inventory process we gathered the following info on each machine: CPU Speed Hard Drive Size Amount of RAM Video Card Network Card Sound Card Zip drive, or no Zip Drive Miscellaneous components We are currently working on finishing up the third stage of information gathering. In this stage we are examining existing software packages and new software packages to determine if they will run on Windows As stated earlier in this paper, we discovered if a program runs effectively under NT 4.0, we have been able to get it to run under Windows We have also discovered several software packages that would not run under NT 4.0 work without any problems on Windows 2000, which has delighted some professors. 7. Time Line Outlined here is a timeline that we established to try and follow during our planning and development stages. August 99: Began discussing internally the possibility of upgrading to Windows 2000 October 99: Approached the Central Student Fee Committee about the release of Windows 2000 and the possibility of upgrading the lab system. November 99: The Central Student Fee Committee approved the upgraded and provided funding. We began informing departments and college committees of the impending change. We established the minimum requirements for the upgrade needs. January and February 00: Worked with the various departments and committees to inventory their computers and establish their budget needs for the upgrades. March 00: One Full Time Staff from the Academic Support Unit and two from the PC Team attended formal Windows 2000 training. Informed Campus of the lab system upgrade. April 00: Converted all our office machines to Windows We began looking at the documentation and web pages to determine where changes would be needed. We began working on the automated Windows 2000 install and examine hardware driver needs. May 00: Began testing existing software and newly submitted software. June 00: Continued product testing. Began working on automated installs for software. The first security templates were released and tested. Gathered final software requests for development. July 00: We continue to work on security templates. A finalized base build released for testing. Begin finalized development on lab specific software. August 00: Finalize the lab build. Test, test and re-test the lab build. Build the various images needed for specific labs. Install and implement to new lab system. September 00: Put out any fires that may arise with the new lab system. Continue to improve and evolve the lab system. 8. Post Paper Plans Once we finish up gathering the info we have outlined, we will begin working on finalizing the lab build. In close cooperation with the PC Team, we will test and finalize a base lab build, which will include Windows 2000 and a standardized set of software products that will be available in all labs. Once the base lab build is finalized we will develop specific software installation routines for lab specific software. At UW we create software installation routines in two ways, the first is with Microsoft s SMS installer. SMS installer allows us to package all the files and registry entries that are created when a product is installed into one self-extracting executable. If a products is unable to be effectively packaged with the SMS installer, we use a product called Scriptit. This is a very basic windows scripting tool that automates the keystrokes that would be needed to install a program. We have also identified several things that will need to be done after the writing of this paper. These involve a great deal of work as well and should not be overlooked or ignored when deciding whether or not to upgrade. We know we will need to train our student workers in the use and support of Windows Some of the screens have moved to different locations or are completely different. Our students will need to have this information in order to continue supporting users in the labs. We are planning on a full-day, intensive session to show our employees the crucial differences in the OS and the overall structure of our lab system. Preparing for this training is proving to be somewhat challenging as we will not know until final implementation exactly what will be different. We expect to have a final build at the beginning of August and until that time we cannot anticipate the final look and function of our system. This is one thing that we can plan for in advance only to a point; the fine details must wait until the end of the process. All of our documentation will need to be revised or rewritten. Again, until we have a final build to work from, we cannot effectively make changes to our existing documentation. We

5 have, however, done a careful analysis of existing materials and identified those things we know will be changing. We can be fairly certain that all of our screen captures and references to Office 97 or Windows NT will need to be changed. By taking this preliminary look at our materials, we can at least gauge the scope of the revisions necessary in the future. We know how much work we will have to do at the last minute and can better budget our time and resources. While it s far from the perfect situation, we at least know what we re facing. We will also have to reeducate some of our users. Fortunately, the user interfaces for Windows NT and Windows 2000 are very similar. The typical student lab user rarely accesses those things that have moved or changed. There will be new versions of software and new packages on the lab system, so we must be ready to support these. We will need to make sure we can educate the users about the new packages on the system and how or why they can be used. For this reason, the free one night courses we offer to students are also changing a bit to adapt to the new system. Overall, the biggest challenge we face with the development of this lab system after the writing of this paper is trying to plan for the unknown. The lab system is still in development and changes every week, possibly every day. It is very difficult to anticipate what problems are going to arise with the system. It is also difficult to work too far ahead because things are not finalized. We cannot prepare to market or support a product that isn t yet finished. This has made planning and preparation all the more important to us. We have discovered that the more planning we do now, the fewer problems we should encounter further down the road. While this may seem rather common sense, actually experiencing it on such a grand scale as we have has been a learning experience. We hope that we can help express to the readers of this paper just how critical extensive research, advance preparation, and detailed planning are when undertaking a project as large as redesigning and implementing a lab system across campus.

Strategic Action Plan. for Web Accessibility at Brown University

Strategic Action Plan. for Web Accessibility at Brown University Strategic Action Plan for Web Accessibility at Brown University May 15, 2018 INTRODUCTION Diversity and inclusion are central to Brown University s mission, and the University is committed to sustaining