|
|
Contact |
|
Desktop Computer Management System - Project PlanPrepared by Alistair Roberts, IT ServicesObjectivesThis project has two primary objectives: (i) To bring University desktop computing under a single authentication and management umbrella in order to promote best practice in support and utilisation of resources while lowering the total cost of ownership; and (ii) To move University desktop computing to a fully client/server model, promoting good data management practice and encouraging collaborative work practices. In addition it will improve IT service delivery through desktop computer redundancy and safer, more flexible data availability. ScopeThis project will deliver the following: (i) File serving services to all schools and departments where they are connected to the central University network, up to a maximum average capacity of 100MB per staff member, 20MB per student, averaged across private, group and public volumes and user profiles. (ii) Centralised single point of authentication for desktop PCs and associated file/printing services, Macintosh file/print server access, and third party systems which comply with the requirements to interoperate with NDS or LDAP for authentication purposes. This will mean that typically users will only have one username and password combination for access to all computing services, however full compliance would require some re-writing of code for existing systems which may or may not be deemed worthwhile. In such cases users will need to maintain additional username/password combinations as at present. (iii) Desktop management services to all lease scheme and ITS supported areas using Windows NT. Desktop management services include: a. remote distribution of mainstream and common usage applications and updates b. automatic drive connection based on login ID c. remote control facilities to desktop computers d. roaming profiles allowing users to store personalised settings on a central server e. backup of central fileservers only f. centralised auditing of software usage and distribution g. user policies to limit potential inadvertent damage by users based on user/group needs (iv) Migration of backup services from desktop computers (except laptops) to file servers. SponsorThe sponsor of the Desktop Computer Management Project is the Deputy Principal, Mr Chris Chapman. StakeholdersThe major stakeholders in the entire project are as follows: Professor Don McNicol Vice-Chancellor Professor Rudi Lidl Deputy Vice-Chancellor Mr Chris Chapman Deputy Principal Mr John Jauncey Director, IT Services Phase 3 stakeholders are the heads of schools and departments in areas currently serviced by the PC Lease scheme. Phase 4 stakeholders are the heads of department for all other schools and departments, as well as their respective IT support personnel. Phase 5 stakeholders are the student population, as well as academic staff who will benefit from the extension of NDS and desktop services to students. DescriptionDirectory Services have come to the fore in the last few years as organisations grapple with the problems of managing resources in large distributed computing networks. Novell has long been a leading player in this market. Novell Directory Services (NDS) has been on the market for about five years now and although it started by being tied to the Novell NetWare platform, with the newest release, NDS 8.0, it is now effectively platform independent. A key strength of NDS, which sets it apart from its competitors, is its ability to manage resources in a more complex manner than that afforded by Unix, Windows NT or AppleShare. Specifically this is the ability to have nested users, machines and resources as groups or as individuals, all contained within ever larger groupings. This has significant advantages for large organisations that need to take advantage of less simplistic groupings of resources than those offered by competitors. In addition, NDS provides the backbone or file structure whereby data spread across a variety of hardware devices and platforms can be available and controlled via a single point of entry. A key issue within the University today is security. Novell differs from Microsoft in a very specific way in which its security model is implemented. Currently to ensure a secure zone we run many separate Windows NT domains with a complex system of inter-domain trust relationships. This is cumbersome and lacks the scalability required for an organisation of this size. Novell NDS offers the ability to unify all this under one administration and access structure and, importantly, NDS has the ability to delegate the security control of specific areas to specific administrators. To give an example, it would obviously be important for all of Human Resources to be secure, possibly even from Administrators within ITS. Novell makes this possible by nominating control over an area within NDS (eg the HR branch of the tree) to a specific trusted HR systems administrator who can retain exclusive control. If this is done, even a higher-level systems administrator who controls the entire tree cannot access that branch within the tree unless the delegated HR systems administrator allows it. Equally that delegated HR systems administrator may be unable to administer other areas within the NDS tree unless allowed to do so. This means in effect that while we can have linkages across all systems, they can be finely tuned to specific security needs of individual areas, and sensitive areas can be assured that their information is secure. Microsoft does not offer this ability, as a top level administrator can always take ownership of areas within the structure. This difference has been highlighted on http://www.novell.com/advantage/nds/ad-security.html In addition to these security considerations, currently we have many systems running mission critical functions hosted on many machines or systems. At the moment these systems mostly authenticate users separately. This means that if someone leaves, it is necessary to ensure that every single account for that user on every different system that person had access to is removed or disabled. In addition, systems such as VNC, the remote control agent for desktop PCs used by, amongst others, ITS, has no ability to be centrally updated. This means that manual password changing on potentially thousands of machines is necessary every time an ITS staff member leaves his or her employment. Naturally this is a mammoth task, leaving us open to some potentially serious security holes due to our inability to centrally update passwords. There are few serious alternative products to Novell NDS available on the market today. IBM, Netscape and Microsoft all market LDAP based directory services however they lack the maturity and the strengths of the market leader, Novell. Gartner Group (http://www.gartner.com) rates Novell as the undisputed leader in the directory market. Microsoft will be making a big push in this area with Active Directory, which is bundled with Windows 2000 Advanced Server, however it is platform specific (Windows 2000) and as such does not meet our requirements for Solaris hosting. Add to that the fact that this is a new product, and that Novell have already released a Windows 2000 client for NDS and the compatibility issue is all in favour of Novell. ComponentsIn order to meet each objective it is proposed to use a range of tools, which are being referred to under the broad umbrella term of NDS. NDS in itself is a single but important component of the Novell suite available under the Academic Licensing Agreement. As we do not propose to implement Novell NetWare on a large scale it is important to differentiate the product. NDS is in effect the backbone of the proposed Desktop Management solution. The main components of the Novell NDS Suite we will use include: NDS (Novell Directory Services) provides the central authentication framework using an LDAP database hosted on Unix (Solaris) servers maintained by ITS Systems group and located in each centre. NDS also provides a central directory tree, which is the method by which staff and students gain access to networked resources in a logical, consistent and easily understood manner. NDS Corporate edition is the backbone of this, NDS eDirectory sits on top of this and would be used in the future for service delivery to students via the Web. Novell ZENworks for desktops is an administration package which would be used by ITS Client Services staff and administrators to centrally install and uninstall applications, patches and utilities to desktop computers individually or by group. This package runs on top of NDS. The benefits of this package are that it centralises updating of desktop computers, ensuring consistency and the rapid deployment of new software versions and patches. It is an essential service in a modern network and we do not currently have anything in this category. In addition, ZENworks provides secure remote control facilities that use centralised (ie NDS) authentication, which can be used to replace the inherently insecure VNC product currently in use. Novell Managewise is described as a comprehensive management tool. It works in conjunction with other components of the Novell ALA suite and is used for remote, single location management of NT servers and desktop PCs (as well as NetWare servers); hardware and software inventories; graphical network mapping; monitoring of servers and the NDS tree itself. It is designed for preventative maintenance. Other components we will use include: Windows NT Server will remain an integral part of desktop delivery services, although their functions may become more specific purpose Sun Servers running on industrial grade hardware, which is consistent with the existing University infrastructure. Solaris (Sun Unix) machines will be the new mainstay of the operation. Unix mimics Windows and Apple file servers on the same machine by using either SAMBA or its commercial equivalent, PCNetlink, and CAP (Columbia AppleTalk Protocol). The advantages are that Unix machines are significantly faster and more efficient large scale file servers that Windows NT servers offering the same services, and by hosting all major services on this equipment we gain high reliability of service on a single platform. File servers allow us to concentrate all corporate data in a few secure locations where access can be controlled and audited. Backups can be centralised for greater efficiency and reliability, and remote access to individual files becomes easier as well as more secure. Legato Networker backup software already in use by ITS for file server backup. This will be a key component of the new backup services. Implementation PlanImplementation would consist of five implementation phases stretching over approximately 3-4 years, implemented sequentially. Timeframes are based on estimates and could vary depending on staff resourcing. Phase 1: Installation and testing of NDS backbone structureTimeframe: 3-6 months Resources required: (i) One FTE in Systems for Systems setup and admin work, and implementation of NDS according to plans developed with NDS expert and management (ii) One Novell NDS expert as required for short periods (up to 20 days) (iii) One FTE in client services for front end/desktop development and testing. Would need NDS experience and/or qualifications. (iv) Manager to oversee the process (v) Hardware listed in Appendix 1 total cost $188,811. Capacity based on an allocation of 200MB per staff member, reduced to 100MB by mirroring and striping for reliability. Outcomes: (i) All Sun servers installed, fully load tested and running file services in all locations to normal Systems group standards. (ii) NDS installed and authenticating users on Sun servers under testing. (iii) NDS tree (stage 1) planned and tested. (iv) Desktop management PC policies developed and tested (v) Standard desktop packages prepared and tested for distribution by ZENWorks. (vi) Preparation of training notes and materials for staff. (vii) Development of standards and procedures for both systems maintenance and desktop delivery/support. Production of accompanying documentation. (viii) Initial acceptance testing completed Risks: (i) NDS may be more difficult than anticipated to implement on standard university environment Solaris machines. (ii) Correct structure of the NDS tree is crucial from the start if we fail to design this properly at this stage there could be delays and inefficiencies in the future. To this end we anticipate drawing on the expertise of Novells in-house consultants to assist with the planning stages. (iii) Inadequate human resourcing could result in delays (iv) Learning curves with technical staff unused to NDS may lead to delays. Training courses would be worthwhile to avoid this. Phase 2: Testing and staged implementation within IT ServicesTimeframe: 3-4 months Resources required: (i) One FTE in Systems for ongoing Systems setup and admin work, and implementation of NDS according to plans developed with NDS expert and management (ii) One Novell NDS expert as required for short periods (up to 20 days) (iii) One FTE in client services for front end/desktop development and testing. (iv) One FTE in client services (or lease scheme) for desktop updating and rollout (v) Manager to oversee the process Outcomes: (i) ITS Staff briefed and familiarised as necessary with the change to authentication and data storage practices. (ii) Training of Client Services support staff to allow them to support the system as more users come on line. (iii) Training notes and materials updated based on experiences in this stage. (iv) CAP and SAMBA file serving in use within ITS for document storage and personal file space. (v) Migration of existing file services to appropriate locations on the NDS tree. (vi) Print queues migrated to NDS control, where feasible (vii) NDS in use as primary authentication mechanism for all staff. (viii) Desktop backups removed except from laptops (ix) Stress testing of desktop systems including ZENworks, ManageWise. Risks: (i) ITS has very disparate technical needs and is unlikely to be a good model for the rest of the university in terms of application or data usage. Lessons learned from this stage may not always apply elsewhere. (ii) Staff may not use the new file services (due to the nature of ITS work). (iii) Security breaches could occur if mistakes are made at this stage. We will need to have the structure reviewed by a third party with strong security qualifications to ensure that we have adequately provided for security. This would be a role for the Novell consultant. Phase 3: Staged implementation across PC lease scheme departments and schoolsTimeframe: 9-12 months Resources required: (i) One FTE in Systems for ongoing Systems setup and admin work, and implementation of NDS according to plans developed with NDS expert and management (ii) One FTE in client services for front end/desktop development and testing. (iii) Two FTE in lease scheme for desktop updating and rollout (a ratio of 1:80 will be required) (iv) Manager to oversee the process Outcomes: (i) File structure skeletons devised and implemented in consultation with heads of department and key staff. This will be different for each area and will need to be tailored to the needs and work practices of each department or school. (ii) Staff trained and familiar with new file systems, able to navigate comfortably around their group and personal areas, and aware of the available flexibility (eg swapping computers and desks). (iii) Staff briefed on security considerations and procedures. (iv) Review and update training procedures, briefing Client Services staff about updates. (v) CAP and SAMBA file serving in use within departments for document storage and personal file space. (vi) All corporate data moved to file servers, removed from desktop systems and located appropriately on the NDS tree. (vii) Print queues migrated to NDS control, where feasible (viii) NDS in use as primary authentication mechanism for all staff. (ix) Desktop backups decommissioned except from laptops (x) Continuous addition and refinement of resources within the NDS tree (xi) Continuous development/adaptation of new packages and appropriate customisation for distribution via ZENworks Risks: (i) Staff may have unrealistic expectations of the benefits to them. (ii) Staff may find the additional drive mappings confusing, resulting in extra calls to the helpdesk. (iii) File structures may be misunderstood or misused despite being accepted by heads of department and key staff. Further education and consultation may be required. (iv) Staff may clog the system by copying rubbish files to the file servers. Education regarding what is appropriate use is required to forestall this, and staff need to understand that they can use existing PC hard disks for this purpose as they always have. Phase 4: Staged implementation across the rest of the schools and departmentsTimeframe: 12-18 months Resources required: (i) One FTE in Systems for ongoing Systems admin work related to NDS. (ii) One FTE in client services for front end/desktop development and testing. (iii) Two FTE in lease scheme for desktop updating and rollout (a ratio of 1:80 will be required) (iv) Manager to oversee the process Outcomes: (i) File structure skeletons devised and implemented in consultation with heads of department and key staff. This will be different for each area and will need to be tailored to the needs and work practices of each department or school. (ii) Staff trained and familiar with new file systems, able to navigate comfortably around their group and personal areas, and aware of the available flexibility (eg swapping computers and desks). (iii) Staff briefed on security considerations and procedures. (iv) Review and update training procedures, briefing Client Services staff about updates. (v) CAP and SAMBA file serving in use within departments for document storage and personal file space. (vi) All corporate data moved to file servers, removed from desktop systems (vii) Print queues migrated to NDS control, where feasible (viii) NDS in use as primary authentication mechanism for all staff. (ix) Desktop backups decommissioned except from laptops (x) Continuous addition and refinement of resources within the NDS tree (xi) Continuous development/adaptation of new packages and appropriate customisation for distribution via ZENworks Risks: (i) Staff may have unrealistic expectations of the benefits to them. (ii) Staff may find the additional drive mappings confusing, resulting in extra calls to the helpdesk. (iii) File structures may be misunderstood or misused despite being accepted by heads of department and key staff. Further education and consultation may be required. (iv) Staff may clog the system by copying rubbish files to the file servers. Education regarding what is appropriate use is required to forestall this, and staff need to understand that they can use existing PC hard disks for this purpose as they always have. Phase 5: Desktop services to student labs and general student populationTimeframe: 6-12 months Resources required: (i) One FTE in Systems to migrate existing staff NDS tree to new equipment, re-utilise 2 year old hardware for student services. (ii) One FTE in Client Services for front end/desktop development, desktop policy development and testing. (iii) Two FTE in Client Services for desktop updating and rollout. (iv) Resources from Infrastructure to assist in making information within Keystone available to NDS to allow automated allocation of students to groups by course (v) Manager to oversee the process (vi) Additional hardware see appendix 2 Outcomes: (i) Students will be allocated their own personal home directory with a maximum of 20MB storage space on separate systems dedicated for student use. Calculated on an expected total of 15,000 students (not FTE) means a total storage capacity of 330GB. If mirrored and striped, capacity will be 660GB (ii) This will be accessible from any university lab (Macintosh, Windows or Unix platform) as well as via Tassie Access dialup facilities. (iii) Student home directories will be backed up onto tape. (iv) Students will be automatically grouped according to enrolment using information extracted from Keystone at enrolment time. (v) Students will have a single username/password combination for all university resources except in special circumstances. (vi) Using NDS, students will only be able to access resources and information to which they are entitled. (vii) Students will be able to run traditional POP mail clients from their home directories, obviating the need to carry floppy disks. It is possible that web mail may be implemented by this time, using this disk space, but that is outside the scope of this proposal. (viii) Just-In-Time application delivery will be utilised wherever possible so that students will have applications required for their coursework made available on Windows NT PCs as soon as they log in, even if the application was not previously installed on the machine. Risks: (i) Data recovery requests from careless students could overload the systems group. To avoid this it may be necessary to put a cap on recoveries, eg 3 recoveries per year for free, afterwards a charge. Alternatively a waiting system could be in place, discouraging unimportant requests. (ii) Problems may occur with grouping according to keystone data. This is not likely to pose major technical hurdles, but if it does, the most important services can be delivered anyway without this additional information.
Last Modified: 06-Mar-2003 |