microsoft windows nt strategy document and installation guide · page 1 prepared by : jon steel...

Prepared By : Jon Steel

Date : 30 August 1996

Document : STRATEGY.DOC

{COMPANY}

MICROSOFT WINDOWS NT

STRATEGY DOCUMENT AND INSTALLATION GUIDE

1. Table of Contents - {COMPANY} NT Documentation Page

1. TABLE OF CONTENTS - {COMPANY} NT DOCUMENTATION............................................................ 2

2. STATUS REPORT ON THE {COMPANY} NT PROJECT.......................................................................... 7

2.1. MACHINES........................................................................................................Error! Bookmark not defined. 2.2. NETWORK ENVIROMENT ..............................................................................Error! Bookmark not defined. 2.3. DOCUMENTATION..........................................................................................Error! Bookmark not defined.

3. INTRODUCTION TO WINDOWS NT.......................................................................................................... 12

3.1. THE MICROSOFT NETWORKING FAMILY.....................................................................................................12 3.2. WINDOWS NT WORKSTATION 3.5................................................................................................................12 3.3. CLIENTS..............................................................................................................................................................12 3.4. WINDOWS NT WORKSTATION ......................................................................................................................12 3.5. ARCHITECTURE OVERVIEW ...........................................................................................................................12 3.6. ENVIRONMENT SUBSYSTEMS..........................................................................................................................13 3.7. EXECUTIVE SERVICES......................................................................................................................................13 3.8. THE MEMORY MODEL OF WINDOWS NT....................................................................................................13

4. NT AND {COMPANY}...................................................................................................................................... 13

5. AUDIT OF WORKSTATIONS ACROSS {COMPANY}........................................................................... 15

5.1. CREATION OF THE “CONFIG” PROGRAM.....................................................................................................15 5.2. INSTALLATION OF “CONFIG” PROGRAM IN BETA ENVIROMENT ...........................................................17 5.3. CREATION OF BETA REPORT FROM “CONFIG”..........................................................................................18 5.4. RE-EVALUATION OF “CONFIG” PROGRAM..................................................................................................20

6. DOCUMENTATION OF WINDOWS NT 3.51............................................................................................. 21

6.1. OVERVIEW OF NT FILE SYSTEMS..................................................................................................................21 6.2. THE FILE ALLOCATION TABLE (FAT) FILE SYSTEM................................................................................21 6.3. FAT NAMING CONVENTIONS .........................................................................................................................21 6.4. FAT FILE SYSTEM CONSIDERATIONS...........................................................................................................21 6.5. THE HIGH-PERFORMANCE FILE SYSTEM (HPFS)........................................................................................22 6.6. NT FILE SYSTEM (NTFS) ................................................................................................................................22 6.7. DESIGN GOALS OF NTFS..................................................................................................................................22 6.8. NTFS NAMING CONVENTIONS.......................................................................................................................23 6.9. NTFS FILE SYSTEM CONSIDERATIONS.........................................................................................................23 6.10. FILE SYSTEM ADVANTAGES AND DISADVANTAGES................................................................................24 6.11. NAMESPACE UNDER WINDOWS NT 3.5 NTFS AND FAT ........................................................................24 6.12. USING COPY AND XCOPY WITH LONG FILENAMES.................................................................................24 6.13. CASE SENSITIVE FILENAMES........................................................................................................................25 6.14. CREATING AND FORMATTING PARTITIONS ..............................................................................................25 6.15. WINDOWS NT RESOURCE SECURITY MODEL...........................................................................................25 6.16. WINDOWS NT OBJECTS.................................................................................................................................25 6.17. ACCESS CONTROL LISTS................................................................................................................................25 6.18. ACCESS CONTROL ENTRIES ..........................................................................................................................26 6.19. SECURING ACCESS TO RESOURCES ..............................................................................................................26 6.20. MANDATORY LOGON.....................................................................................................................................26 6.21. ACCESS TOKENS ..............................................................................................................................................26 6.22. SECURITY IDS..................................................................................................................................................27 6.23. CHECKING PERMISSIONS................................................................................................................................27 6.24. OPTIMIZING PERMISSION CHECKING ..........................................................................................................27 6.25. OVERVIEW OF W INDOWS NT NETWORK ARCHITECTURE .....................................................................28 6.26. COMPONENTS AND INTERFACES.................................................................................................................28 6.27. NETWORK COMPONENTS AND OSI.............................................................................................................28

6.28. BOUNDARY LAYERS.......................................................................................................................................29 6.29. NDIS 3.0 (NETWORK DRIVER INTERFACE SPECIFICATION)...................................................................29 6.30. COMPONENTS BUILT INTO WINDOWS NT................................................................................................30 6.31. WINDOWS NT NETWORK PROTOCOLS.......................................................................................................30 6.32. NET BEUI..........................................................................................................................................................31 6.33. STRATEGIES FOR USING NET BEUI ..............................................................................................................31 6.34. NWLINK IPX/SPX..........................................................................................................................................32 6.35. TCP/IP...............................................................................................................................................................32 6.36. DLC ...................................................................................................................................................................32 6.37. IPC MECHANISMS FOR DISTRIBUTED PROCESSING...................................................................................33 6.38. IPC CLIENT ......................................................................................................................................................33 6.39. IPC SERVER......................................................................................................................................................33 6.40. INTERPROCESS COMMUNICATION (IPC) MECHANISMS...........................................................................33 6.41. NAMED PIPES..................................................................................................................................................33 6.42. MAILSLOTS......................................................................................................................................................33 6.43. PROGRAMMING INTERFACES ........................................................................................................................34 6.44. NET BIOS..........................................................................................................................................................34 6.45. WINDOWS SOCKETS.......................................................................................................................................34 6.46. REMOTE PROCEDURE CALLS (RPC)............................................................................................................34 6.47. NETWORK DYNAMIC DATA EXCHANGE (NET DDE)...............................................................................35 6.48. FILE AND PRINT SHARING COMPONENTS..................................................................................................35 6.49. ...........................................................................................................................................................................35 6.50. THE WORKSTATION SERVICE......................................................................................................................35 6.51. WORKSTATION SERVICE DEPENDENCIES..................................................................................................35 6.52. ACCESSING A REMOTE FILE .........................................................................................................................36 6.53. THE SERVER SERVICE ....................................................................................................................................36 6.54. MULTIPLE UNIVERSAL NAMING CONVENTION PROVIDER (MUP).......................................................36 6.55. UNIVERSAL NAMING CONVENTION (UNC) NAMES..................................................................................37 6.56. WHY MUP?.....................................................................................................................................................37 6.57. THE MULTI-PROVIDER ROUTER (MPR) .....................................................................................................37

7. DOCUMENTATION OF WINDOWS NT WORKSTATION.................................................................... 38

7.1. INSTALLATION PROCEDURES FOR WINDOWS NT WORKSTATION .........................................................38 7.2. STANDARD INSTALLATION TABLE - PLEASE FILL IN PRIOR TO INSTALLATION.................................40

7.2.1. Compaq Prolinea Installation Guide.................................................................................................41 7.2.2. Installation of other important software ............................................................................................ 46 7.2.3. Service Pack 4 Installation - Compulsory ......................................................................................... 48

7.3. INSTALLATION DOCUMENT ON PORTABLE PC’S.......................................................................................51 7.3.1. Problems arising when using Portables............................................................................................. 51 7.3.2. Docking Stations .................................................................................................................................... 51 7.3.3. Power Management................................................................................................................................ 51 7.3.4. Plug and Play.......................................................................................................................................... 51 7.3.5. Portable Peripherals.............................................................................................................................. 52 7.3.6. Viglen Dossier Advanced 486 Installation Guide............................................................................ 53

8. DOCUMENTATION OF WINDOWS NT SERVER .................................................................................... 55

8.1. INSTALLATION GUIDE TO WINDOWS NT SERVER - GENERIC..................................................................55

9. INTRODUCTION TO THE BROWSER SERVICE..................................................................................... 61

9.1. BROWSER SERVER ROLES................................................................................................................................61 9.2. MASTER BROWSER...........................................................................................................................................61 9.3. PREFERRED MASTER BROWSER.....................................................................................................................61 9.4. BACKUP BROWSERS..........................................................................................................................................61 9.5. POTENTIAL BROWSER.....................................................................................................................................61 9.6. NON-BROWSER..................................................................................................................................................61 9.7. THE BROWSE PROCESS .....................................................................................................................................62 9.8. BROWSER CRITERIA .........................................................................................................................................62 9.9. THE BROWSER ELECTION PROCESS ...............................................................................................................62

9.10. CONFIGURING A BROWSER............................................................................................................................63 9.11. CONFIGURING A PREFERRED MASTER BROWSER.....................................................................................63 9.12. BROWSER OPERATIONS.................................................................................................................................63 9.13. BROWSER ANNOUNCEMENTS.......................................................................................................................63 9.14. ALL SERVERS...................................................................................................................................................64 9.15. BACKUP BROWSERS........................................................................................................................................64 9.16. MASTER BROWSERS.......................................................................................................................................64 9.17. MASTER BROWSER.........................................................................................................................................64 9.18. DETERMINING THE NUMBER OF BROWSERS.............................................................................................64 9.19. HOW CLIENT COMPUTERS ACCESS THE BROWSE LIST...........................................................................64 9.20. BROWSING FAILURES .....................................................................................................................................65 9.21. NON-BROWSER COMPUTERS ........................................................................................................................65 9.22. BACKUP BROWSERS........................................................................................................................................65 9.23. MASTER BROWSER.........................................................................................................................................65 9.24. SERVER SHUT DOWN.....................................................................................................................................65 9.25. BROWSING ACROSS MULTIPLE WORKGROUPS AND/OR DOMAINS.......................................................65

10. IMPLEMENTING WINS ON A WINDOWS NT SERVER ...................................................................... 67

10.1. INTRODUCTION AND OVERVIEW OF WINS ...............................................................................................67 10.2. WINS IMPLEMENTATION .............................................................................................................................67 10.3. FOUR SCENARIOS............................................................................................................................................67

10.3.1. Dual-Hub WINS Environment ............................................................................................................ 68 10.3.2. Hub/Local WINS Environment........................................................................................................... 69 10.3.3. Hub/Dual Local WINS Environment.................................................................................................70 10.3.4. Hub/Dual "Spoke" WINS Environment ............................................................................................ 71

10.4. COMMENTS......................................................................................................................................................72 10.5. WINS IN {COMPANY} .................................................................................................................................72

11. DOCUMENTATION OF NT USER ENVIROMENT.................................................................................. 73

11.1. THE DOMAIN MODEL ....................................................................................................................................73 11.1.1. Background........................................................................................................................................... 74 11.1.2. Objectives ............................................................................................................................................... 74 11.1.3. The windows NT domain model ......................................................................................................... 74 11.1.4. The Master Domain model .................................................................................................................. 74 11.1.5. Trust Relationships .............................................................................................................................. 74 11.1.6. Domain Rules ........................................................................................................................................ 75 11.1.7. Trusting versus Trusted Domains...................................................................................................... 75 11.1.8. Setting up Trust Relationships........................................................................................................... 75 11.1.9. Establishing a route for passing validations.................................................................................. 76 11.1.10. {COMPANY} Resource Domains..................................................................................................... 77 11.1.11. Primary and Backup Domain Controllers .................................................................................... 80 11.1.12. Domain Network Traffic .................................................................................................................... 80 11.1.13. Domain Browsing............................................................................................................................... 80 11.1.14. WINS Replication............................................................................................................................... 80 11.1.15. Directory replication......................................................................................................................... 80 11.1.16. User accounts database (SAM) replication .................................................................................. 80 11.1.17. Naming conventions.......................................................................................................................... 81 11.1.18. Domain Name...................................................................................................................................... 81 11.1.19. Server Name ........................................................................................................................................ 81 11.1.20. Workstation Name.............................................................................................................................. 82 11.1.21. Resource Name ...................................................................................................................................82 11.1.22. Local Group ........................................................................................................................................ 82 11.1.23. Global Groups .................................................................................................................................... 82 11.1.24. Network administration.................................................................................................................... 82 11.1.25. Summary............................................................................................................................................... 82

11.2. OVERVIEW OF USER AND GROUP ACCOUNTS............................................................................................83 11.2.1. Multiple User Accounts for Security.................................................................................................83 11.2.2. Creating User Accounts ...................................................................................................................... 83

11.2.3. Copying User Accounts ....................................................................................................................... 83 11.2.4. New User Items Copied........................................................................................................................ 83 11.2.5. New User Items Settings after Copying ............................................................................................ 83 11.2.6. Renaming User Accounts .................................................................................................................... 84 11.2.7. Deleting and Disabling User Accounts ............................................................................................ 84 11.2.8. Deleting User Accounts ....................................................................................................................... 84 11.2.9. Setting the User Environment Profile............................................................................................... 84 11.2.10. Logon Script Name ............................................................................................................................ 84 11.2.11. Home Directory...................................................................................................................................84 11.2.12. Assigning Group Membership......................................................................................................... 84 11.2.13. Group Accounts ..................................................................................................................................85

11.2.13.1. Local Groups ....................................................................................................................................85 11.2.13.2. Global Groups..................................................................................................................................85 11.2.13.3. Default Group Accounts ..................................................................................................................85

11.2.13.3.1. Guests........................................................................................................................................85 11.2.13.3.2. Users..........................................................................................................................................86 11.2.13.3.3. Power Users ..............................................................................................................................86 11.2.13.3.4. Administrators................................ ................................ ................................ ...........................86 11.2.13.3.5. Replicator..................................................................................................................................86 11.2.13.3.6. Backup Operators .....................................................................................................................86

11.2.13.4. Deleting Local Groups Account.......................................................................................................86 11.3. MANAGING SECURITY POLICIES..................................................................................................................87

11.3.1. The Account Policy .............................................................................................................................. 87 11.3.2. The User Rights Policy ........................................................................................................................ 87

11.4. USER LEVELS....................................................................................................................................................88 11.5. USER PROFILE CONFIGURATION ..................................................................................................................91 11.6. LOGIN SCRIPTS & CONFIGURATION............................................................................................................94 11.7. NETWORK PRINTING WITH NT ...................................................................................................................96

11.7.1. Overview of Printing with NT............................................................................................................. 96 11.7.1.1. Windows NT Printing Terminology ...................................................................................................96 11.7.1.2. Printing Device versus Printer............................................................................................................96 11.7.1.3. Printer Versus Print Queue................................ ................................ ................................ .................96 11.7.1.4. Physical Versus Logical Printer Port ..................................................................................................96 11.7.1.5. Local and Remote Printers and Printing Devices ................................................................................96 11.7.1.6. Printer Pools .......................................................................................................................................96 11.7.1.7. Using Print Manager ................................ ................................ ................................ ...........................97 11.7.1.8. Creating a Printer ................................................................................................................................97 11.7.1.9. Connecting to a Printer.......................................................................................................................97 11.7.1.10. Administering Remote Printers.........................................................................................................97 11.7.1.11. Implementing Printer Pools ..............................................................................................................98

11.7.2. Printing in {COMPANY}..................................................................................................................... 98

12. DOCUMENTATION OF RAS ....................................................................................................................... 99

12.1. OVERVIEW OF RAS.........................................................................................................................................99 12.1.1. Supported Dial-in Servers .................................................................................................................. 99 12.1.2. Supported Dial-in Clients................................................................................................................... 99 12.1.3. Supported Network Interfaces ........................................................................................................... 99 12.1.4. Windows NT RAS Connection Limitations....................................................................................100 12.1.5. RAS Software Compression..............................................................................................................100 12.1.6. Scalability ............................................................................................................................................100 12.1.7. WAN Support .......................................................................................................................................100

12.1.7.1. Standard phone lines (Public Switched Telephone Networks)................................ .........................100 12.1.7.2. ..........................................................................................................................................................100 12.1.7.3. Integrated Services Digital Network (ISDN)................................ ................................ ....................100

12.1.8. RAS Security........................................................................................................................................100 12.1.9. Integrated Domain Security .............................................................................................................101 12.1.10. Encrypted Authentication and Log on.........................................................................................101 12.1.11. Auditing .............................................................................................................................................101

12.1.12. Intermediary Security Hosts ...........................................................................................................101 12.1.13. Call Back Security ...........................................................................................................................101

12.2. INSTALLATION OF RAS ON A SERVER......................................................................................................102 12.3. INSTALLATION GUIDE OF RAS ON NT CLIENT ......................................................................................105

13. USER GUIDE TO NT WORKSTATION....................................................................................................107

14. APPENDIX 1 - GLOSSARY OF TERMS USED WITHIN THIS DOCUMENTATION.....................122

2. Status Report on the {COMPANY} NT Project 16/08/96 George Bruce has implemented our “config” program on his servers, and we will be collating

the figures of all the hardware within the next week or so. This, in line with the new standards that have been recommended, will give us a direct costing comparison for an implementation of NT Workstation.

We have now received Steve Donkins Portable PC for testing of an implementation of NT. The

machine is a 486/66 and has only 12Mb memory at present. I have asked Scott to order a 16Mb card as we discussed (which will make it 20Mb) - but NT runs (albeit slow) perfectly OK. The only problem seems to be screen drivers and corruption’s - but I believe that we can probably sort this out quickly.

A standard Workstation Installation Guide is to be created - documenting how to install NT

Workstation 3.51 across the LAN, Via Floppy Disks and Via CD-ROM. This document will also explain how to install and configure for certain hardware devices (such as CD-ROM’s, PCMCIA Cards etc.). Various different workstation types will be identified.

20/8/96 Delay from George - he will be pursuing this next week After discussions with Alu -Suisse in Zurich this week, a Hardware Standard Recommendation

for Windows NT has been put forward to the IT Council. This means that we can now identify which machines in {COMPANY} are already compatible with the Standard - and which need to be upgraded or replaced.

Screen Drivers have been sorted out - Standard VGA Drivers work well Microsoft’s only answer to Docking Stations appear in a document on their Web Site - Please

check documentation of Portables In effect, we have to deal with portables producing the “Some Services have not started” error

when not docked. I believe that NT4 may be the only solution to this problem. However, although slightly irritating to be told in effect that the portable is not docked every time - the machine works well.

We have got the Nokia Cellular Data Card working in the Viglen Portable. However, I believe

that there are also a number of other PCMCIA cards and devices that need to be tested. I have yet to write an installation guide for this card - although it is promising that the card works !

I have documented how the User Profiles and Login Scripts should be set up in a domain.

These “standards” need to be reviewed and discussed between {COMPANY} - but they offer the same capabilities as the Novell Login Scripts. We have yet to test a “roaming” user - but the user ID TESTING is an example of how low-level user ID’s should be set up - and has been tested within our domain.

The Standard Installation Guide is progressing well, with detailed installation notes for as much

hardware as possible

23/8/96 The portable now has an installation standard on it - with a full documented installation of the Nokia Data Card, a 28.8 Modem PCMCIA Card, MS Office (Local) as well as RAS. The portable seems to work well. Implementation of the Standard now needs to be achieved on a Toshiba Portable.

The portable now has an installation standard on it - with a full documented installation of the

Nokia Data Card, a 28.8 Modem PCMCIA Card, MS Office (Local) as well as RAS. The portable seems to work well. Implementation of the Standard now needs to be achieved on a Toshiba Portable.

We have successfully implemented 5 operating Workstations on the domain, including the

“email” workstation of Austin and Justin’s. They are operating this workstation as if it were a 3.1 Windows Environment. They are not, however, logged into the NT Domain - but instead logged into Novell only.

This has now been fully documented and Testing is a user that works well on the Domain. The

user is highly restricted, for test purposes only. A tentative document explaining User Levels has been created. However, this has to be

discussed further within IS and a standard needs to be reached A full document explaining the different user levels has been created. Before I go any further

with t his document, I wish to create a meeting to discuss with relevant parties on the format of this document

A test User Profile has been created and documented - TESTING will become the standard low-

level user profile A test of the User Login Scripts has been created and documented. The Standard Installation Guide has progressed extremely well, and is almost complete. A document explaining how the Servers should be set up is being created - this document

takes the {COMPANY} Standards for the “arianne” project - and caters the installation for either MS install or Compaq Install. I believe that this document should also explain recommended hardware configurations and a hardware installation guide.

Documentation of RAS has been fully completed. This has been successfully implemented on

several Servers - and Windows NT 3.51 and Windows ‘95 Clients have successfully logged into the network remotely.

3/9/96 The documentation of the NT Strategy has progressed extremely well, and a meeting has been set up between Rudi, Nick and myself to discuss the project. Although the documentation is still very much in its draft format, the content is almost complete and will soon be available to other business clusters if the go-ahead from Nick and Rudi has been obtained

The meeting brought up several different areas which need to be looked into before the

strategy document can be finalised. Rudi came up with the following : a Workstation Language Types - obviously, Language Settings for the workstation should be

based on the location of that workstation b. Server Language Type - it would be best if the servers are set up in English so that there will be

no problems with administration of servers c. Time Settings and Time Zones - how this is to be synchronised across the WAN. From this

subject, a complete chapter has been created in the Strategy Document explaining how TIMESERV should be implemented across the {COMPANY} Domain

d. The Resource Domain Model - Rudi wanted to finalise an exact model, which has been

documented fu lly Nick also wanted to discuss User Levels and User Environments prior to the strategy being

taken up. 9/9/96 We will be installing a Backup Domain Controller in York Prepress on our domain that will

slightly differ from the Standard Configuration in Clients that access Netware Servers. The strategy document was sent out to Chris Pearson and an NT Consultant who agreed that the strategy documentation and installation instructions were easy to understand and would be followed.

10/9/96 Based on the prerequisites of Strategy Documentation, the Strategy Document and Installation

Guide has mostly been completed. Installation Instructions for certain machine types will be prepared once certain machine types have been procured.

3. Preliminary Minutes of the Recommendations to the IT Council

The following is a paraphrase of the document sent to the Workgroup for Windows Operating Systems attendees of August 13&14 1996 in Alu Suisse Lonza - prepared by Dr Marc Weibel

3.1.1. Recommended Product If a move to the next generation operating systems is required (because of their features or because new generations of application software will run only under such operating systems), then NT is the Mandatory solution. If a business case can be presented that cannot be solved using this solution, other means may be used. A business case is any requirement the user has to enable him to conduct his business activity.

3.1.2. Impact of group wide applications None

3.1.3. Security impact : NT better than Windows 3.x and Windows ‘95 Data Security with NTFS on the workstation renders unauthorised access to the Hard Disk very difficult (Using a DOS Boot Disk will not enable the user to see the Hard Disk) Access to workstations require the user to log into NT Configuration cannot easily be changed. The System Directory and registry can be protected It is possible to prevent users from accessing unauthorised Network resources using a User Profile

3.1.4. Implementation Schedule Organisations may choose their individual implementation schedule as their business needs dictate The need for a mandatory update will be periodically reviewed in the light of the support of current software and operating systems.

3.1.5. Recommended minimum machine specifications for new purchases The minimum specifications for new PC’s are : Pentium 133Mhz with 32Mb RAM, 2Mb Video Memory, 17” Monitor and 1Gb Hard Disk Space

3.1.6. Costs involved Software upgrade cost per seat/user : Windows NT 3.51 purchased under select MVLP -A agreement 405.00 ChF Office ‘95 Standard upgrade 305.00 ChF Total price for Software 710.00 ChF Minimum price for workstation upgrade - 405.00 ChF (the cost of only the Operating System - since Windows NT can still run 16Bit MS Office) Hardware upgrade costs : New Workstation approximate cost 5,000.00 ChF Workstation Upgrading (Maximum) 1,000.00 ChF 1 Manday per PC 1,200.00 ChF Training NT Users 500.00 ChF Initial Support 200.00 ChF Incompatible Software/Old Applications may have to be converted or replaced. The cost of this must be determined from case to case. We have approximately 5500 PC’s in the corporation If the upgrade is to be done immediately (outside the normal Hardware replacement cycle) and simultaneously in an entire organisation approximately 50% of the PC’s would have to be discarded, 30% could be upgraded and NT would be able to run NT as is. If the upgrade was to be done piecemeal as natural replacement needs arise, the cost would be practically negligible.

3.1.7. Necessary standards for Applications Documents may be produced with high level software. However - interchange format will be at the published common level for the foreseeable future. The file naming convention for interchange will be 8.3 (DOS Standard).

3.1.8. Consequences from untimely introduction of new OS Too Early ?? New Applications missing and less sophisticated and not debugged ?? Large replacement of Hardware ?? Large impact on manpower to support new OS Too Late ?? Old Operating System to manage means increased cost ?? More applications to maintain and migrate ?? Inefficient use of new Hardware ?? Multiple OS and old applications

4. Introduction to Windows NT The following text gives an overview to Windows NT and has taken text from Microsoft’s own standard text to explain what Windows NT is.

4.1. The Microsoft Networking Family Both the Microsoft® Windows NT™ Server network operating system and the Windows NT Workstation operating system provide a 32-bit operating system for users who require a fast, multitasking environment. Corporate systems managers use Windows NT Workstation to establish a general purpose computing environment, which at the same time can reliably host a line of business applications. Developers and engineers, as well as financial and technical users, can take advantage of these operating systems for business needs such as mechanical and electronic design automation, architectural planning, engineering and construction, manufacturing and process control, custom software development, accounting, financial analysis, investment trader workstations, and real-time systems. In addition, any user who needs the power of a multiprocessing system can use the Microsoft Windows NT™ operating system to run multiple applications at the same time.

4.2. Windows NT Workstation 3.5 The Microsoft Windows NT Workstation 3.5 operating system includes all the capabilities of the Windows® for Workgroups operating system with integrated networking elevated to a more powerful, multitasking level. Windows NT Workstation can be used alone as a powerful desktop operating system, networked in a peer-to-peer Workgroup environment, or used as a workstation in a Windows NT Server 3.5 domain environment. Windows NT Workstation 3.5 can be used as a client in the Microsoft BackOffice strategy, accessing resources from all the BackOffice products.

4.3. Clients Windows for Workgroups is a peer-to-peer network client based on the Microsoft Windows® operating system and designed for resource sharing among small numbers of people with similar tasks. The Microsoft Windows operating system version 3.x is intended primarily for the single user in a desktop environment based on the Microsoft MS-DOS® operating system. The Windows and Windows for Workgroups are both ideal products for group or small business environments

4.4. Windows NT Workstation Windows NT Workstation combines the power of a 32-bit multitasking workstation with the ease of use, compatibility, and productivity of a personal computer. It provides unlimited outbound peer-to-peer connections and up to 10 simultaneous inbound connections. Remote Access Service (RAS) supports one inbound session for a user who is dialling in using a modem. Windows NT Workstation supports up to two processors in a symmetric multiprocessing environment. These features are a few of the reasons why Windows NT Workstation 3.5 is a powerful multitasking client desktop operating system.

4.5. Architecture Overview The Windows NT operating system uses an object model to provide user access to local and network resources, and to run applications of various types. An object can be thought of as any resource within the Windows NT system, such as files, directories, and printers. The object model used by Windows NT is that of a modular operating system, composed of a group of relatively independent components. Each component performs a specific task within the context of the operating system as a whole. This is accomplished through subsystems and executive services that form the foundation on which applications can run.

4.6. Environment Subsystems One of the features of Windows NT is its ability to execute applications written for multiple operating systems. This is accomplished through the environment subsystems in Windows NT. The environment subsystems can run applications written for several operating systems by emulating those operating systems.

4.7. Executive Services Underneath the user applications lies the Windows NT operating system. The Windows NT operating system provides the support for user applications. It comprises many components, the majority of which are called the Executive and its Managers. The Executive Services can be compared to a company president who oversees an entire organisation. In Windows NT the Executive Services co-ordinate the activities of the operating system, such as providing access to hard disk resources, printers, memory, and the network. The Managers can be compared to vice presidents who oversee specific areas of the company. In Windows NT the Manager services are the actual code that manages the specific functions overseen by the Executive.

4.8. The Memory Model of Windows NT The memory architecture for Windows NT is a demand-paged, virtual memory system. It is based on a flat, linear address space accessed by 32-bit addresses. Windows NT uses a 32-bit flat memory model, which means that applications can access up to 2 GB of RAM directly, rather than 64K segments, allowing programmers to create larger applications. The Virtual Memory Manager maps virtual addresses for the application into physical pages in the computer's memory (1). In doing so, it hides the organisation of physical memory from the application. This ensures that when applications call for memory locations they are mapped to non-conflicting memory addresses. Demand paging refers to a method by which data is moved in pages from (2 ) physical memory to a temporary paging file on-disk (3). As the data is needed by an application, it is paged back into physical memory. The algorithm for paging is optimised to perform per-process paging as opposed to systemwide paging.

5. NT and {COMPANY} The following chapter describ es the benefits of Windows NT Workstation in {COMPANY}. Obviously, the functionality of a 32 bit Operating System on the desktop will allow faster and larger desktop workstations to be more fully utilised, but this document has not been developed to argue the case between OS/2 Warp, Windows NT and Windows ‘95 as a Desktop Solution - instead to argue the case for Windows NT Workstation above 16 bit Desktop Operating Systems such as Windows for Workgroups and 3.x. The major differences between NT and Windows 3.x is the fact that different hardware platforms can be utilised. Because NT utilises a “Microkernel Operation architecture” - rather than a classical Operating System architecture - only the Hardware Abstraction Layer (HAL) needs to be updated for different hardware types. This means that NT can run on Intel x86 Machines, Dec Alpha APX machines, MIPS R4x00 Machines and Motorola Power PC 60x. Future versions of NT are due to also run on Intel i860 and SPARC technology. This single difference, though, does not really help us since we are running only Intel machines in {COMPANY}. However, it means that the Operating System is geared for the future, and if Intel platforms were suddenly superseded - then other technologies are already running NT. NT as an operating system is also an open operating system. At present NT can run OS/2, Win16, Win32, POSIX and DOS Applications - often much better than it the native OS that the application was developed for. NT4 should increase this level of support to include Windows 95 applications. However, there are still applications which will not run under NT - especially some older DOS

Applications that try to directly control hardware. These applications are rare, though, and at present none of the tested {COMPANY} applications have failed under either version of NT. Since NT has been correctly configured for various different hardware platforms, NT has been written specifically to control the most important hardware platform - Intel x86. The 32bit and 64bit technology in Intel PC’s can only be correctly controlled using a 32bit operating system. Although an 80486 can theoretically handle 2Gb RAM and most PC’s can be configured to hold at least 64Mb RAM - DOS restricts this to 16Mb, and therefore any Windows 3.x user has the same problem. Windows NT can see as much memory as the user can install - and does not have a limit on the resource allocation table in a similar vein to 16bit Windows - therefore relegating memory and resource problems to the past. Windows NT has also been written with pre-emptive multitasking in mind, therefore any application has access to a task scheduler which switched a variety of processes into or out of the CPU, either according to a set time schedule or based upon the existence of some high-priority event, such as an interrupt. This means that applications running in the background will have a higher use of the processor if the foreground applications are not being utilised. Windows NT also utilises multithreading, allowing multiple demands to be made to a single application. As an example - a correctly developed Windows NT application will accept input from a user while the last input is being written to disk, rather than an “hourglass” appearing to the user. SMP - or Parallel Processing also takes multithreading and a program can execute a thread on its own CPU, thereby speeding up the application. Windows NT has support for up to 4 processors with the Native support - and certain hardware platforms can even support up to 20 Processors. As can be seen, Windows NT is a very, very powerful operating system in its own right. However, NT is a Networking Operating System, and has certain benefits over other 32bit Network Operating Systems. Every subsystem in Windows NT has been designed with connectivity and networking in mind - in a similar vein to OS/2. But Windows NT goes a step further - it provides built in networking features that go beyond anything packaged with any other operating system, even beating the NEXTstep Operating System. One of the largest problems encountered in an Enterprise Network, is administration of a large number of users who “roam” the WAN. Under Novell Netware 3.1x - each user is set up on a single Network Server. If a user wishes to access 2 Servers, then 2 different user ID’s need to be set up. If a user then “roams” across the WAN to a remote site - the only way that user is able to log onto the network is if they can access their local fileserver - often meaning a very slow connection. Under Windows NT Server - a network can be viewed as a domain. The user ID’s set up in the domain are shared across the WAN with other Domain controllers. All of the security information is passed between one domain controller and another. This means that when a user wishes to log onto the network, they will always be authenticated by the nearest Domain Controller - in our example, this would mean that they would be authenticated by a local server - therefore enabling that user to access the network quickly. NT also utilises IP as its core Network Protocol. NT has some exceptionally advanced applications allowing an NT machine to interface with other network systems much more easily than other NOS’s - especially across Wide Area Networks. Applications such as RAS and RPC allow full control of networks completely remotely without the cost of expensive hardware items.

6. Audit of Workstations across {COMPANY} To enable us to correctly identify exactly which machines in {COMPANY} are suitable for upgrade or replacement for Windows NT - then a Hardware Audit needs to take place. However, an audit is time-consuming and can be expensive without specialist software installed across the network. It is, however, possible to estimate very accurately the hardware that exists on the LAN using a program that will create a report based on each machine it runs on. This program, providing that it does not interfere with how the users operate or whether it requires user input, can be placed across the network - and the reports could be collated into a final “audit” report. We decided to use Microsoft’s MSD (Microsoft Diagnostics). This application comes with DOS and Windows 3.1x - so should be located on all PC’s across the Network. It can also be run without user intervention - and even if the program “crashes” - then it does not affect the DOS environment. The only disadvantage is the report that the program generates. Because the program dumps as much as it can to a file - then the report has to be “sorted through” using a text macro or something similar. Sometimes, MSD will not run at all on some machines. However, since this is rare - and only occurs in a 10% of cases we tested - then we can be sure that the report is 90% accurate.

6.1. Creation of the “CONFIG” program The “ CONFIG” program will run MSD and log the results to a unique filename based on the network address of the machine. The program will run automatically, requiring no user intervention and should run only once on each machine. This is easy to implement, by placing a simple command into the System Login Script, we can have every PC running MSD and auditing a report to a file. Once we collate a number of these report files, we can then run a macro of some sort over these files and pull out information for the audit. To get MSD to run automatically from the system login script, the /P identifier should be used. This produces an automatic report from the system without asking for user input. The problem comes with the name of the file to utilise. Either we could use the user names from the Netware Environment Variable %LOGIN_NAME or, if possible, we could try to use something more physical, such as the MAC Address of the workstation. I believe that it is probably more pre ferable to use %NETWORK_ADDRESS instead, since this does not change. An area on each server should be created where EVERYONE (including GUEST) has write/read access, but only SUPERVISOR has delete access. I recommend something like SYS:CONFIG or something similar - so that it can be standardised across all groups. Network Address : 00A0 247C 5202 Computer : Compaq/Compaq, 486DX Memory : 640K, 15360K Ext, 1024K XMS Video : VGA, Cirrus Network : Novell, Shell 4.20.00 OS Version : MS-DOS Version 6.20, Windows 3.10 Bus Type : ISA/AT/Classic Bus Video BIOS Version : CL-GD543x PCI VGA BIOS Version 1.23 Physical Station Number : 00A0:245D:7261 A : Floppy Drive, 3.5" 1.44M C : Fixed Disk, CMOS Type 65 1123M 1216M D : CD-ROM Drive

These values can be extrapolated from the TXT files using a “hunt and seek” macro on each text file.

The information gathered will be invaluable in working out how many PC’s on the WAN are suitable for upgrading to Windows NT Workstation. This would then give us the basis for costs involved in upgrading hardware etc. etc.

6.2. Installation of “CONFIG” program in Beta Environment To see whether the program would work, we decided to install the “CONFIG” program across a single network in {COMPANY} Avonbank. {COMPANY} Avonbank, who use LMG_UK_AB_PROD_1 as their main server, had the following inserted into the System Login Script. This meant that every user ran this batch program. It was recommended that these commands be placed at the START of the System Login Script, so no problems occur with the user’s Drive Mappings. : : DOS SET CONFIG2="%P_STATION" << 4 MAP ROOT G: = LMG_UK_AB_PROD_1\SYS:CONFIG #COMMAND /C G:\CONFIG.BAT MAP DEL G: DOS SET CONFIG2= : : The program sets a DOS Environment Variable, CONFIG2, as the last 8 digits of the Workstations MAC Address - which should be unique. A drive is then mapped to an area where the user has READ WRITE and CREATE rights, but NOT DELETE rights. The System Login Script then runs the following Batch Program : @echo off if exist G:\%config2% goto end echo please wait...retrieving information about this computer. echo Any problems, please call User Support. @G:\msd /p g:\%config2% >null :end The Batch Program looks in the shared area for a file with the same value as the MAC Address of the Workstation. If this file does not exist, then MSD is ran and a report file is generated with the same name as the users MAC Address. If, however, the users MAC Address has already GOT a file in the area - then control is passed back to the System Login Script. The version of MSD that is in the area MUST be Version 2.11 or above. Only this version will discover whether the client has a Pentium Processor or not. Unfortunately, it is still not possible to distinguish what speed of processor is present.

6.3. Creation of Beta Report from “CONFIG” Using a Word Macro - together with a copy of the MSD Reports - an excel spreadsheet was very quickly compiled. From this spreadsheet - we could tell how many computers in the environment tested were 486 Processor Machines, how much memory was in the machines - and what make of machines were in the field. The following table is a list of the above values :

USER Physical Station Number:

Computer Type Memory C: Total Space

1 CBOAR 00a0:243c:48bd IBM/IBM, 486DX 12 517 2 PSCOLLECITO 00A0:245D:7261 Compaq/Compaq, Pentium(TM) 16 1216 3 AGUNN 00A0:2497:A452 Compaq/Compaq, Pentium(TM) 16 1216 5 SSMITH 0060:8c32:d802 Compaq/Compaq, Pentium(TM) 16 605 6 MAILADM 0060:8C32:DB13 AST/IBM, 486SX 4 115 7 0060:8C32:DE0A AST/IBM, 80386 4 80 9 0060:8c32:df70 AST/IBM, 80386 4 81

10 IPIFF 0060:8C32:E0CD AST/IBM, 486SX 8 115 11 MAILADM 0060:8C32:E1F3 American Megatrend, 80386 8 31 12 RHARRISON 0060:8C32:E262 Award/Award, 486DX 8 515 13 JSAVIDGE 0060:8C32:E28F AST/IBM, 486DX 8 115 14 NSPILLER 0060:8C32:E291 Award/Award, 486DX 8 202 15 JEVANS 0060:8c32:e2a1 IBM/IBM, 486DX 12 517 16 JPACKER 0060:8C32:E2B5 AST/IBM, 80386 4 80 17 MAILADM 0060:8C32:E4BF AST/IBM, 80386 4 80 18 DHARRIS 0060:8C32:E4E6 Phoenix/Phoenix, 486DX 16 406 19 0060:8C32:E4FA AST/IBM, 80386 8 80 20 SEDGERLEY 0060:8C32:E50F Award/Award, 486DX 8 515 21 AHILYER 0060:8c32:e513 Compaq/Compaq, Pentium(TM) 16 403 22 0060:8C32:E516 American Megatrend, 80386 8 31 23 MKEEGAN 0060:8C32:E51C Award/Award, 486DX 8 515 24 PMORGAN 0060:8C32:E51E Compaq/Compaq, 486DX 8 200 25 KWYATT 0060:8c33:e797 AST/IBM, 80386 8 80 26 AUTO_MAIL 0060:8c33:e7a1 AST/IBM, 486DX 4 115 27 PDEMARTINES 0060:8C50:AE28 Zenith Data System, 80386 4 79 28 AMAHER 0060:8CBC:1A97 AST/IBM, 486DX 16 202 29 SPEASTON 0060:8cea:e93b IBM/IBM, 486DX 12 514 30 0060:8cea:e95d AST/IBM, 80386 4 80 31 MAILADM 0060:8CEB:BF77 AST/IBM, 80386 4 80 32 MAILADM 0060:8ceb:c094 AST/IBM, 80386 4 202 33 DJOHNSON 0060:8CEB:C617 Compaq/Compaq, 486DX 8 198 34 MAILADM 0020:af12:a7ac IBM/IBM, 486DX 8 126 35 0020:AF13:3A76 Unknown/Award, 486DX 8 202 36 KGORDON 0020:af13:3a7a IBM/IBM, 486DX 8 514 37 APICARIELLO 0020:AF13:3A86 IBM/IBM, 486DX 8 126 38 AMASSEY 0020:af1c:7ff4 Compaq/Compaq, Pentium(TM) 16 605 39 SHUGHES 0020:AF1C:9481 AST/IBM, 80386 4 80 40 SHUGHES 0020:af1c:9481 IBM/IBM, 486DX 24 433 42 DJORDAN 0020:AF1C:9564 IBM/IBM, 486DX 8 433 43 KPLESSIER 0020:AF45:922F Compaq/Compaq, 486DX 8 197 44 PSHAW 0020:af45:9243 Compaq/Compaq, Pentium(TM) 16 406 45 AHARRIS 0020:AF45:9351 Compaq/Compaq, 486DX 8 198 46 IJENNINGS 0020:af5a:03b4 American Megatrend, 486DX 16 324 47 JHALL 0020:AF88:6D6A Phoenix/Phoenix, 486DX 16 406 48 JSTURTRIDGE 0000:c064:60a7 IBM/IBM, 486DX 12 517 49 CCLAYTON 0000:c0ca:6ba7 Compaq/Compaq, Pentium(TM) 16 605 50 0000:C0D6:6BA7 Compaq/Compaq, Pentium(TM) 8 254 51 HJONES 0000:c0d8:6ba7 Unknown/Unknown, 486SX 8 199

Based on the assumption (see section 2) of the standard, recommended workstation being a 486 DX with a minimum of 24Mb RAM and a 500Mb Hard Disk - we can see that almost all of the above machines need to be either upgraded or removed. The recommendation is that if a machine costs more than CHF1000 to upgrade, then it should be replaced with a new machine.

The following prices are given so that comparisons can be made. 4MB Module: £75.00 8MB Module: £128.00 16MB Module: £250.00 The Cost of a 1.2GB IDE Hard Disk Drive is £139.00

Upgrade Path Approximate Costs

RAM Upgrade - 4Mb-24Mb 1x4Mb ? 3x8Mb CHF700 RAM Upgrade - 8Mb-24Mb 1x8Mb ? 3x8Mb CHF450 RAM Upgrade - 12Mb-24Mb 3x4Mb ? 3x8Mb CHF700 RAM Upgrade - 16Mb-24Mb 2x8Mb ? 3x8Mb CHF230 RAM Upgrade - 20Mb-24Mb 2x8Mb+1x4Mb ? 3x8Mb CHF230 RAM Upgrade - 4Mb-32Mb 1x4Mb ? 2x16Mb CHF900 RAM Upgrade 8Mb-32Mb 1x8Mb ? 4x8Mb CHF700 RAM Upgrade - 12Mb-32Mb 3x4Mb ? 2x16Mb CHF900 RAM Upgrade 16Mb-32Mb 2x8Mb ? 4x8Mb CHF500 RAM Upgrade 20Mb-32Mb 2x8Mb+1x4Mb ? 4x8Mb CHF500 RAM Upgrade 24Mb-32Mb 3x8Mb ? 4x8Mb CHF250 Hard Drive Upgrade - IDE 500Mb CHF250 New Minimum Standard PC - 586/133/1.6GbHD&32Mb RAM

CHF2700

Based on our maximum upgrade cost of CHF1000, then it can be assumed that almost any type of upgrade can be permitted - the only time a new PC should be investigated is when upgrading a standard desktop machine with only 4Mb or 12Mb to a 32Mb machine, as above. Obviously, there will be other “mixtures” of memory SIMMS in PC’s across the company - so each should be investigated on its own merits. Also, memory SIMMS may be re-used in new PC’s if required - therefore reducing the costs. However, the above table gives a good approximation to upgrade costs. Note, these upgrade paths should be discussed with the manufacturer or support supplier for each machine since many machines have strict rules concerning memory upgrade paths.

6.4. Re-evaluation of “CONFIG” program The results of the Beta test were successful enough to be put into practice across the WAN. After discussing (via email) with George Bruce - he has offered to install this across several servers. I also sent an email to our administrators to receive back a list of Network Administrators for servers in the WAN. Once I receive this list, then we can go ahead and forward these administrators with details of the “config” program.

7. Documentation of Windows NT 3.51 This being probably the largest section of the {COMPANY} Standards - it details exactly how both the Workstation and the Server should be set up and configured - and exactly how certain applications should be c onfigured to run on the different hardware platforms.

7.1. Overview of NT File Systems In choosing a file system, it is important to note that you can format multiple partitions with different file systems on the same Windows NT workstation, depending on the operating system and security needs of the computer. File System Supporting Operating Systems FAT MS-DOS, Windows NT, and OS/2 HPFS OS/2 and Windows NT NTFS Windows NT

7.2. The File Allocation Table (FAT) File System The FAT file system is widely used and supported by a variety of operating systems, such as MS-DOS, Windows NT, and OS/2. If you plan to dual boot your Windows NT Workstation computer with the MS-DOS operating system, the system partition must be formatted with the FAT file system.

7.3. FAT Naming Conventions The MS-DOS FAT file and directory naming convention can consist of three parts: a filename of up to eight characters, a period (.) separator, and a three-character extension. The following table describes some basic characteristics of the File Allocation Table on Windows NT 3.5. Filename/Directory length 255 File Size 4 GB (232 bytes) Partition Size 4 GB (232 bytes) Attributes Read-only, Archive, System, and Hidden Directories *Linked List Accessible Through MS-DOS, OS/2, and Windows NT * Linked List = To enable MS-DOS to locate a file, the file's directory entry contains its beginning FAT entry number. This FAT entry, in turn, contains the entry number of the next cluster if the file is larger than one cluster, or a marker that designates this is the last cluster. A file whose size implies that it occupies 10 clusters will have 10 FAT entries and 9 FAT links. This method of storing the information of files forms the linked list.

7.4. FAT File System Considerations The following considerations are important in implementing a FAT file system: You cannot undelete a file on any of the supported file systems because undelete utilities

access the hardware directly, which is not allowed under the Windows NT operating system. However, if the deleted file is on a FAT partition and the system is restarted under the MS-DOS operating system, it may be possible to undelete the file if it has not been written over.

FAT has minimal file-system overhead (less than 1 MB). FAT is the most efficient file system for partitions less than 200 MB. Performance declines with

large numbers of files, because FAT uses a linked list for the directory structure. If the amount

of data in a file grows, the file becomes fragmented on the hard disk, and the process of retrieving the file from disk becomes slower.

FAT is the required file system for the boot partition on ARC-compliant computers (RISC

processors-based computers supported by Windows NT). A FAT partition cannot be protected by the file or directory security features of Windows NT.

7.5. The High-Performance File System (HPFS) HPFS is the same file system supported by OS/2. Windows NT provides no enhancements to the HPFS file system. It is typically used to ease the migration from OS/2 to Windows NT. HPFS is no longer supported by Microsoft with Windows NT for Future Versions of NT.

7.6. NT File System (NTFS) NTFS is the preferred file system under Windows NT for a number of reasons, primarily security. However, there may be cases where it is necessary to use another file system on the same computer as Windows NT Workstation. If the computer will be running another operating system, at least one partition must be formatted with a file system supported by that operating system. Only Windows NT supports NTFS. Another advantage of NTFS is that it has considerably larger partition capacities than the other file systems. Under NTFS, a file can be up to 16 Gigabytes in size. The minimum NTFS partition size is 5 MB.

7.6.1. Design Goals of NTFS Here are some of the design goals of NTFS: Provide improved reliability (desirable for high-end computers and file servers). NTFS is a recoverable file system because it keeps track of transactions against the file system.

When a CHKDSK is performed on FAT or HPFS, the consistency of pointers within the directory, allocation, and file tables are being checked. NTFS will automatically log all directory and file updates. That information can be used to redo or undo failed operations due to system failure, power loss, and so on.

In addition, NTFS supports hot fixing. Hot fixing is a trouble shooting technique. For example,

if an error occurs because of a bad sector on the hard disk, the file system moves the information to a different sector and marks the original sector as bad. This is all done transparently to any applications that are performing disk I/O, i.e. the application never knows that there were any problems with the hard drive.

Support the Windows NT security model, so that permissions and auditing can be configured on files and directories. Remove the file and partition size limitations of FAT and HPFS file systems. NTFS supports much larger file and partition sizes than the previous file systems.

7.6.2. NTFS Naming Conventions The following rules must be observed when naming NTFS files: File and directory names can be up to 255 characters long, including extensions. Names preserve case, but are not case-sensitive. NTFS makes no distinction between filenames

based on case. Names can contain any characters (including spaces) except the following: ? " / \ < > * | :

7.6.3. NTFS File System Considerations The following considerations are important in implementing a NTFS file system: Recoverability is designed into NTFS so that users will not have to run a disk repair utility on

an NTFS partition. NTFS provides security on files and directories, but no file encryption. There is no way in which a deleted file can be undeleted on an NTFS partition. NTFS utilises more system file overhead than FAT or HPFS. The recommended minimum partition size for an NTFS partition is 50 MB because of the

overhead involved in using NTFS. It is not possible to format a floppy disk with NTFS because of the amount of overhead

involved in NTFS. Fragmentation is greatly reduced on NTFS partitions. NTFS always attempts to locate a

contiguous block of hard disk space large enough to hold the entire file being stored. Once on the drive, if a file grows in size, it could potentially become fragmented depending on the drives disk space usage. To un-fragment the file, copy the file to another drive and copy it back to the original drive again. When it is copied back to the original drive, NTFS will attempt to place it in a contiguous block on the drive.

The following table describes some basic characteristics of the NTFS File System. Filename/Directory length 255 File Size 16 EB (264 bytes) Partition Size 16 EB (264 bytes) Attributes *Further extended Directories B-tree Accessible Through Windows NT *Further extended = such as maintaining the file creation, as well as last modified, date and time for files and directories

7.7. File System Advantages and Disadvantages Here's a summary of the advantages and disadvantages of each of the file systems. File System Advantages Disadvantages FAT Low system overhead. Using FAT with drives or Best for drives and/or partitions over 200 MB may partitions under about 200 decrease performance. MB. Cannot set permissions on files or directories. HPFS Best for drives in the Not effic ient for a volume of 200-400 MB range. under 200 MB, because of Attempts to avoid overhead involved. fragmentation by searching Does not support Hot Fixing. for a band that can hold Cannot set file or directory the entire file. permissions on Windows NT HPFS partitions. NTFS Best for use on volumes of Not recommended for use on about 400 MB or more. volumes smaller than 400 MB, Recoverability because of impact on (transaction logging) performance. Disk space designed into NTFS is such overhead ranges from 1 to 5 that a user should never MB depending on size of the have to run any sort of partition. disk repair utility on an NTFS partition. It is possible to set permissions on files and directories.

7.8. Namespace Under Windows NT 3.5 NTFS and FAT Under Windows NT 3.5, long filenames are converted to 8.3 names to create an alias for supporting MS-DOS-based clients. This conversion takes the first 6 characters of the long name and uses a ~number suffix to keep the name unique. For example, in the graphic below, My Term Paper A.doc becomes MYTERM~1.DOC and successive iterations would look like MYTERM~2.DOC, MYTERM~3.DOC, MYTERM~4.DOC After the fourth file with the same first 6 characters, the naming convention changes. The fifth attempt will use the first two characters of the long name, but the next four will be generated by a hashing algorithm. For example, after the fourth attempt, My Term Paper E.doc becomes MY0F58~5.DOC. Notice the last two characters are "~5". Only when the hashing of the middle 4 characters fails to produce a unique name will the ~5 be incremented to a ~6 and so on. This method is used on both NTFS and FAT partitions to create alias' for long filenames.

7.9. Using COPY and XCOPY with Long Filenames By default, COPY and XCOPY attempt to copy a file using its long filename. Therefore, when copying a file with a long filename from either HPFS or NTFS to FAT, the following error will occur if FAT long filenames are turned off: “The filename, directory name, or volume label syntax is incorrect.” When using COPY or XCOPY to copy from an NTFS partition to a FAT partition, consider using the /n switch. This switch will have COPY or XCOPY use the short 8.3 NTFS generated filename when copying

the file from an NTFS partition. When trying to copy a file from an HPFS partition, the file will have to be renamed when copying to a FAT partition that has long filenames turned off, since HPFS does not generate short filenames.

7.10. Case Sensitive Filenames NTFS supports case sensitive names, a requirement of POSIX. However, MS-DOS, WIN 16, OS/2, and the Win32 application programming interface do not currently support case sensitive naming. Therefore, any applications running in any of these environments may be confused by files with case sensitive names. It is not recommended to use Case Sensitive Filenames.

7.11. Creating and Formatting Partitions Disk Administrator is a graphical tool for managing hard disk drives. This tool encompasses and extends the functionality of character-based disk management tools, such as MS-DOS Fdisk and the Microsoft LAN Manager local area network software Fault Tolerance character applications, into one graphical interface. Primarily, it is used to set up, configure, and organise the system's hard disk(s) to function more efficiently. As you recall, partitioning the hard disk on a new computer is performed during initial set-up when you install Windows NT. After Windows NT is installed, use Disk Administrator to make changes to the computer's hard disks or to partition a new hard disk.

7.12. Windows NT Resource Security Model Windows NT protects its resources, including files, printers, and applications, by controlling access to them. For a resource to be protected or secured, the resource must be accessible to authorised users and inaccessible to unauthorised users. There are two basic approaches to resource security. One method associates an access code with each resource. Any user who knows the code receives access. Another method associates users with resources. Any user that is granted permission to the resource receives access. In Windows NT, users are associated with a resource.

7.13. Windows NT Objects All Windows NT resources are represented as objects that can be accessed only by authorised Windows NT services and users. An object in Windows NT is defined as a set of data used by the system, and the set of actions that manipulate that data. For example, a file object consists of data stored in a file and a set of functions that allow you to read, write, or delete data in that file. This definition can be applied to any object used by the system, including memory, printers, or processes. Everything in Windows NT is represented to the operating system as an object. The following are examples of Windows NT objects: Directories Symbolic links Printers Processes Network shares Ports Devices Windows Files Threads

7.14. Access Control Lists All functions used to access an object, (for example, open a file), are directly associated with a specific object. In addition, the users and groups that are permitted to use the function are also associated with the object. Only users with the appropriate rights are allowed to use functions on an object. As a result, functions from one process cannot access objects that belong to another process. This characteristic of

objects provides built -in security. Access to each object is controlled through an Access Control List (ACL). The A CL contains the user (and group) accounts that have access and permissions to the object. When a user wants to access an object, the system checks the user's security identifier and group memberships with the ACL to determine whether or not this user is allowed to complete the request.

7.15. Access Control Entries Every user of the system needs to have a user account which can be added to resource access control lists. This includes applications and services which need to access resources as well as people. When an administrator grants access to a resource, the user account is added to the ACL for that resource along with any specific permissions. For example User-1 has read permissions to a file, while User-2 has read, write, and delete permissions to the same file. These ACL entries are called Access Control Entries (ACEs). Each entry identifies a user or group and the permissions that have been granted or denied for the object. An ACE is added to the ACL for each user or group that is granted or denied acces s to an object. Entries that deny access are listed first in the ACL, and entries that permit access will be listed next. The only time this order is changed is if a company has written their own application that edits the ACL of a resource. In this case, they can place the ACE anywhere in the ACL they wish.

7.16. Securing Access to Resources Access to resources begins with the user logging on. Windows NT requires that users log on before they can access any resources. When a user successfully logs on, he or she receives an access token that remains with the user process until logging off. Each time the user attempts to access a resource, the access token is compared to the resource ACL to determine whether access is granted or denied.

7.17. Mandatory Logon Windows NT requires each user to provide a unique username and password to log on to a computer. This mandatory logon process cannot be disabled. When a user logs on to Windows NT, the security subsystem creates an access token for the user. The access token includes information such as the user's name and the groups to which the user belongs. Access to the system is allowed after the user has received this access token. During the time a user is logged into a system they are identified to the system by this access token.

7.18. Access Tokens When a user's process attempts to access any object, Windows NT checks the user ID and list of groups in the user process's access token against the object's Access Control List (ACL). This check determines if the user is granted the requested access to the object. The access token is permanently attached to each of the user's processes and serves as the process's "identity card" whenever it attempts to use system resources. Access tokens are objects and have attributes and services just like any other system object.

7.19. Security IDs Even though user and group identifications are represented here as names, the computer actually stores this information as a security identifier (SID) and group security identifiers (group SIDs). A SID is a unique identifier used to represent a user, group, or some type of security authority. SIDs are used within access tokens and ACLs instead of usernames or group names. A SID is represented as a unique number, such as: S-1-5-21-76965814-1898335404-322544488-1001 The result of identifying users by SIDs is that the same user account name may have been created multiple times on the same computer, but each instance of the account name will have a unique SID. For example, you have user account for User-1. If you delete this account and create a new account for User-1 using the same name, the new account will not have access to the same resources as the old account. This is a result of the SID being different, even when the account name is the same.

7.20. Checking Permissions Windows NT compares the information in the access token to the information in the ACL to determine whether or not access should be granted. When a user attempts to access a resource on the system, the security subsystem compares the user's access token to the ACL to validate or deny the requested permission to the resource. It goes through the following steps: 1. Starting at the top of the ACL, it checks each Access Control Entry (ACE) to see if it explicitly

denies the user (or any of the groups that appear in the user's access token) the type of access that is being requested.

2. It checks to see if the type of access requested has been explicitly granted to the user or any of

the groups in the user's access token. 3. It repeats step 1 and 2 for each entry in the ACL until either it has encountered a deny, or until

it has accumulated all the necessary permissions to grant the requested access. 4. If neither a deny or a grant appears in the ACL for each of the requested permissions, the user

will be denied access.

7.21. Optimising Permission Checking When Windows NT grants access to an object, what it really does is gives the user's process a pointer (handle) to the object. A handle is an identifier used internally by the system to identify and access a resource. The system also creates a list of allowed permissions called the list of granted access rights. This information is then stored in the user's process. In this way, an ACL is only checked when the object is initially opened. Subsequent actions performed on an opened object are checked against the list of granted access rights that have been stored in the user's process table for that handle.

7.22. Overview of Windows NT Network Architecture A significant difference between the Microsoft Windows NT operating system and other operating systems is that networking capabilities are built into Windows NT. With MS-DOS, Windows 3.x, and OS/2, networking was added on top of the operating system. By providing both client and server capabilities within Windows NT, your computer is able to participate with other network computers to share files, printers, and applications. A Windows NT-based computer can participate as either a client or server in a distributed application environment, as well as in a peer-to-peer networking environment. Windows NT provides the ability to interoperate in many different network environments simultaneously from a single Windows NT computer.

7.23. Components and Interfaces To support such a diverse network interoperability, Windows NT provides modular network components. This means a network component, such as a network protocol, can be replaced with a newer version without affecting the networking components. In addition, new components can be integrated with the default networking components to provide increased interoperability with other networking operating systems. Windows NT networking components can be organised into three categories: file system drivers, transport protocols, and network adapter card drivers. Each plays a distinctive role. These components communicate with each other through interface layers known as boundary layers. Boundary layers translate data into a format the receiving component understands. The boundary layers include programming interfaces, the Transport Driver Interface (TDI), and NDIS 3.0.

7.24. Network Components and OSI The Windows NT networking components and the boundary layers can be compared to the seven-layer OSI model. File system drivers access system resources, such as an I/O call to an NTFS partition or a network file. They operate at the Application and Presentation layer of the OSI model, receiving input from user mode applications. FAT, HPFS, and NTFS each have their own file system driver for local file partitions. In addition, there are several file system drivers for use in a network environment. Transport protocols define the rules governing communications between two computers. They operate at the Date Link layer and typically cover responsibilities up to the Session layer in the OSI model. Each transport protocol has advantages and disadvantages in its implementation, although it is possible to install and run several protocols at once.

Network adapter card drivers co-ordinate communication between network adapter card and the computer's hardware and software. For every network adapter card, there is a network adapter card driver. These drivers must be NDIS 3.0 compliant to operate with Windows NT. Network adapter card drivers operate at the Media Access Control sublayer while the card itself represents the Physical layer of the OSI model.

7.25. Boundary Layers A boundary is the unified interface between the layers in the Windows NT network architecture model. Creating boundaries as a breakpoint in the network layers helps open the system to outside development. It makes it easier for vendors to develop network drivers and services, since the functionality that must be implemented between the layers is well defined. Vendors only need to program between the boundary layers instead of writing to the entire OSI model. Boundary layers eliminate the need for rewriting software written for adjacent layers by allowing software to be mixed and matched. There are two significant boundary layers in the Windows NT network architecture: the NDIS 3.0 layer and the Transport Driver Interface (TDI) boundary layer. The NDIS 3.0 boundary layer provides the interface to the network driver interface specification (NDIS) wrapper and device drivers. The TDI boundary layer provides a common interface for a driver, such as the Windows NT redirector and server, to communicate with the various network transports. This allows redirectors and servers to remain independent from transports. Unlike NDIS, there is no driver for TDI, it is simply a standard for passing messages between two layers in the network architecture.

7.26. NDIS 3.0 (Network Driver Interface Specification) The NDIS 3.0 boundary layer provides the interface to the NDIS wrapper and network adapter card drivers. All transport protocols call the NDIS interface to access network adapter cards. NDIS (Network Driver Interface Specification) is a standard that allows for multiple network adapters and multiple protocols to coexist in a single computer. NDIS permits the high-level protocol components to be independent of the network interface card by providing a standard interface. The network adapter card driver is at the very bottom of the Windows NT network architecture. Since Windows NT supports NDIS 3.0, it requires network adapter card drivers written to the NDIS 3.0 specification. NDIS 3.0 allows an unlimited number of network adapter cards in a computer and an unlimited number of protocols that can be bound to a single adapter card. Boundary layer components are examples of the modular Windows NT network components.

7.27. Components Built into Windows NT At the centre of the Windows NT networking environment are the components that provide the user with the ability to create and access resources across the network Windows NT networking components, from the bottom layer going up, include: Transport protocols (DLC, NetBEUI, NWLink IPX/SPX, and TCP/IP). File System Drivers. Named pipes (NPFS) and mailslots (MSFS) provide inter-process communication (IPC) over a

network. The Server (SRV) and Workstation (RDR) services provide file and print sharing. The Server

allows resources to be made available on a network and the Workstation provides the ability to access network resources.

Programming Interfaces (NetBIOS, Windows Sockets, RPC, NetDDE). The Multiple UNC Provider (MUP) and Multi-Provider Router (MPR). The UNC and the MUP

make it possible to write applications that use a single API to communicate on the network using any network vendor's redirector. These are helper components which determine which file system driver to use when a network request is made.

7.28. Windows NT Network Protocols Above the NDIS wrapper are the transport protocols. Windows NT ships with four transport protocols: NWLink, TCP/IP, NetBEUI, and DLC.

7.29. NetBEUI NetBEUI stands for NetBIOS Extended User Interface and was first introduced by IBM in 1985. NetBEUI was developed for small departmental LANs of 20 to 200 computers. It was assumed that these LANs would be connected by gateways to other LAN segments and mainframes. NetBEUI's primary disadvantage is that it cannot be routed, so it must be connected using bridges and not routers. As such, it is primarily used in a local area network consisting of mainly Microsoft clients and servers, including LAN Manager. NetBIOS extended user interface (NetBEUI) was first introduced by IBM in 1985. It is a small, efficient, and fast protocol. When NetBEUI was developed in 1985, it was assumed that LANs would be segmented into workgroups of 20 to 200 computers and that gateways would be used to connect that LAN segment to other LAN segments or a mainframe. NetBEUI is optimised for very high performance when used in departmental LANs or LAN segments. For traffic within a LAN segment, NetBEUI is the fastest of the protocols shipped with Windows NT. The version of NetBEUI shipping with Windows NT is NetBEUI 3.0. NetBEUI 3.0 corrects some limitations in previous versions of NetBEUI, including the following: NetBEUI 3.0, along with the TDI layer, eliminates the previous limitation of 254 sessions to a

server on one network adapter card. NetBEUI 3.0 is completely self-tuning. NetBEUI 3.0 provides much better performance over slow links than did previous versions of

NetBEUI. Strictly speaking, NetBEUI 3.0 is not truly NetBEUI. Instead, it is a NetBIOS Frame (NBF) format protocol. NetBEUI uses the NetBIOS interface as its upper-level interface, but NBF conforms to the Transport Driver Interface (TDI) instead. NBF is completely compatible and interoperable with the NetBEUI shipped with past Microsoft networking products, however, and is referred to as NetBEUI on Windows NT screens. The following table summarises the advantages and disadvantages of NetBEUI.

Advantages Disadvantages Tuned for small LAN communication, and therefore is very fast

Not routable

Good error protection Performance across WANs is poor

Small memory usage

7.30. Strategies for Using NetBEUI Because NetBEUI is very fast for small LAN communications but provides poorer performance for WAN communications, one recommended method for setting up a network is to use both NetBEUI and another protocol, such as TCP/IP, on each computer that may need to access computers across a Router or on a WAN.

When you install both protocols on each computer and set NetBEUI as the first protocol to be used, Windows NT uses NetBEUI for the communication between Windows NT computers within each LAN segment and TCP/IP for communication across routers and to other parts of your WAN.

As can be seen, there are certainly advantages of having NetBEUI in a network - but these can be weighed against the idea of having another protocol to cope with in the Network. There are certainly advantages of having a single protocol throughout the WAN. Primarily, the idea of having NetBEUI on local networks is so that the workstations sitting on the same segment can converse much more rapidly than if they were solely using TCP/IP. The overhead in traffic terms is almost 1/3 compared to the packet sizes that are normally broadcasted across a LAN. But, you have the best of both worlds - NetBEUI throughout LAN Segments and IP across WAN Segments.

7.31. NWLink IPX/SPX NWLink is an IPX/SPX-compatible protocol for Windows NT. It can be used to establish connections between Windows NT-based computers and MS-DOS-, OS/2-, Windows -, or other Windows NT-based computers through a variety of communication mechanisms. It is often used in environments that consist of both Microsoft and Novell networks, in which the Microsoft clients need access to resources on NetWare file servers. NWLink is simply a protocol. By itself, it does not allow a Windows NT computer to access files or printers on a NetWare server, or to act as a file or print server to a NetWare client. To access files or printers on a NetWare server, you must use a redirector, such as Microsoft Client Service for NetWare (CSNW) or Novell NetWare Client for Windows NT.

7.32. TCP/IP TCP/IP stands for Transmission Control Protocol/Internet Protocol and is an industry-standard suite of protocols designed for wide-area networking. It was developed in 1969, resulting from a Defense Advanced Research Projects Agency (DARPA) research project on network interconnection. TCP/IP is commonly used in wide area networks that consist of a variety of network hosts. DARPA developed TCP/IP to connect its research networks together. This combination of networks continued to grow and now includes many government agencies, universities, and corporations. This global wide area network is referred to as the Internet. In Windows NT, TCP/IP allows users to connect to the Internet as well as any machine running TCP/IP and providing TCP/IP services.

7.33. DLC DLC stands for Data Link Control, unlike the other protocols in Windows NT (NetBEUI, NWLink IPX/SPX, TCP/IP), the DLC protocol is not designed to be a primary protocol for use between personal computers, as it does not provide a NetBIOS interface. DLC only provides applications with direct access to the data link layer, and thus is not used by the Windows NT redirector. Since the redirector cannot use DLC, this protocol is not used for normal session communication between Windows NT-based computers.

DLC only needs to be installed on computers performing the above tasks and not on the other computers on the network. An example would be a print server sending data to a network HP® printer. Client computers sending print jobs to the network printer do not need to be using the DLC protocol, only the print server communicating directly with the printer needs the DLC protocol installed.

7.34. IPC Mechanisms for Distributed Processing In distributed computing, the computing task is divided into two sections, a client component and a server component. The goal is to move the actual application processing from the client computer to a server system with the power to run large applications. Windows NT-based computers can perform the role of either the client or the server for distributed application support.

7.35. IPC Client The client component of a client-server application is typically the user interface for the application. It runs on the client computer and utilises a smaller amount of computing power than the server application, but typically requires a lot of network bandwidth to communicate with the server component.

7.36. IPC Server The server component of a client-server application typically requires larger amounts of data storage, computing power, or specialised hardware. It includes operations such as database lookups and updates, or mainframe data access.

7.37. Interprocess Communication (IPC) Mechanisms There must be a network connection between the client and server portions of distributed applications that allows data to flow in both directions. There are a number of different ways to establish this connection. Windows NT provides several different Interprocess Communication (IPC) mechanisms. Included are: Named Pipes File Systems (NPFS) Mailslots File Systems (MSFS) NetBIOS Windows Sockets Remote Procedure Calls (RPC) Network Dynamic Data Exchange (Net DDE)

7.38. Named Pipes Named pipes provide connection-oriented messaging services that allow applications to share memory over the network. Windows NT provides a special application programming interface (API) which increases security when using named pipes. One feature added to named pipes is impersonation. When using impersonation, the server can change its security identifier to that of the client at the other end of the connection. For example, suppose a database server system uses named pipes to receive read and write requests from clients. When a request comes in, the database server program can impersonate the client before attempting to perform the request. Thus, if the client does not have the authority to perform the function the request would be denied, even though the server program might have the proper permissions to complete the task.

7.39. Mailslots Mailslots are used to provide connection-less messaging services on a local area network. Windows NT implements second-class mailslots, which are used most commonly for the following: Registration of computer, workgroup or domain, and user names on the network The Computer Browser service Sending broadcast messages to computers or users

7.40. Programming Interfaces The following programming interfaces provide communication between user mode applications and file system drivers.

7.41. NetBIOS NetBIOS is a standard programming interface in the personal computer environment for developing client-server applications. NetBIOS has been used as an IPC mechanism since the introduction of the interface in the early 1980s. From a programming perspective, higher level interfaces such as named pipes and RPC are superior in their flexibility and portability. A NetBIOS client-server application can communicate over various protocols: NetBEUI protocol (NBF), NWLink NetBIOS (NWNBLink), and NetBIOS over TCP/IP (NetBT). The NetBIOS Interface provides the NetBIOS mapping layer between NetBIOS applications and the TDI compliant protocols.

7.42. Windows Sockets The Windows Sockets API provides a standard Windows interface to many transports with different addressing schemes, such as TCP/IP and IPX. The Windows Sockets API was developed to accomplish two things. One was to migrate the sockets interface, developed at the University of California, Berkeley in the early 1980s, into the Windows and Windows NT environments. The other was to help standardise an API for all platforms. Windows NT provides Windows Sockets support on both NWLink and TCP/IP transport protocols.

7.43. Remote Procedure Calls (RPC) The RPC mechanism can use other IPC mechanisms to establish communications between the computers on which the client and the server portions of the application exist. If the client and server are on the same computer, the Local Procedure Call (LPC) mechanism can be used to transfer information between processes and subsystems. This makes RPC the most flexible and portable IPC choice. The components of the remote procedure call mechanism are: Remote Procedure Stub-Packages remote procedure calls to be sent to the server by means of

the RPC runtime. RPC Runtime -Responsible for communications between the local and remote computer,

including the passing of parameters. Application Stub-Accepts RPC requests from the RPC Runtime, unwraps the package, and

makes the appropriate call to the remote procedure. Remote Procedure -The actual procedure that is called over the network. The remote procedure call facility provided in Windows NT is compatible with the Open

Software Foundation's (OSF) distributed computing environment (DCE) specification. Windows NT workstations can use RPC to interoperate with any other workstations that support this standard.

7.44. Network Dynamic Data Exchange (Net DDE) NetDDE provides information sharing capabilities by opening two one-way pipes between applications. NetDDE is an extension of Dynamic Data Exchange (DDE) that can be used between two computers across the network. By default, the NetDDE services are not automatically started. They can be started using Control Panel Services option.

7.45. File and Print Sharing Components The ability to use and share file and print resources is accomplished primarily by two Windows NT components: Workstation (RDR) and Server (SVR). Both the Workstation and Server execute as 32-bit services. These services are implemented as File System Drivers (FSD). There is an FSD for each of the file systems (FAT, HPFS, NTFS, CDFS) as well as the Workstation and Server services.

7.46. The Workstation Service The Workstation service of a Windows NT computer allows that computer to access resources on the network, including the ability to log on to a domain, connect to shared directories and printers, and use client-server applications over the network. All user mode requests go through the Workstation service. This service consists of two components:

The user-mode interface (such as File Manager connections or net use commands). The redirector (RDR.SYS)-The redirector provides file system and print service translation to

access remote drives and printers .

7.47. Workstation Service Dependencies The Workstation service is dependent on the following components: A protocol that exposes the TDI interface at its top level must be started for the Workstation

service to load. Multiple Universal Naming Convention Provider (MUP) The Workstation Service (Redirector) as a File System Driver The redirector is a component through which one computer gains access to another computer. The Windows NT redirector allows connection to Windows NT, Windows for Workgroups, LAN Manager, LAN Server, and other Microsoft Networks servers. The redirector communicates to the protocols via the TDI interface.

7.48. Accessing a Remote File When a process on a Windows NT computer tries to open a file that resides on a remote computer, the following steps occur: The process calls the I/O Manager to request that the file be opened. The I/O Manager recognises that the request is for a file on a remote computer, so it passes it

to the redirector file system driver. The redirector passes the request to lower-level network drivers that transmit it to the remote

Server for processing.

7.49. The Server Service The Windows NT Server service allows a Windows NT computer to create and secure shared resources, such as directories and printers, and to function as a server in a client-server application. Like the redirector, the Server service is implemented as a file system driver and directly interacts with various other file system drivers to satisfy I/O requests such as reading or writing to a file.

The Server service processes the connections requested by client redirectors, and provides them with access to the resources they request. Like the Workstation service, the Server service is composed of two parts: Server service-A service that runs in the SERVICES.EXE process. Unlike the Workstation service, it is not dependent on the MUP service, since the Server is not a UNC provider. It does not attempt to connect to other computers, but other computers connect to it.

SRV.SYS-A file system driver that handles the interaction with the lower layers and interacts directly with various file system devices to satisfy command requests, such as file read and write.

7.50. Multiple Universal Naming Convention Provider (MUP) It is possible to have more than one redirector installed on the system for use with other network operating systems such as NetWare. Applications reside above the redirector and server services in user mode. Like all other layers in the Windows NT networking architecture, there is a single unified interface to access network resources, independent of the redirector(s) installed on the system. This is done through two components: MUP and the Multi-Provider Router (MPR). The MUP provides a communication link between applications that make UNC calls and the redirectors installed on the system. The MUP is a component that finds out which redirector should receive a UNC call from an application. The MPR provides a communication link between applications that make Win32 Network API calls and the redirectors installed on the system.

When applications make I/O calls containing UNC names, these requests are passed to MUP. MUP selects the appropriate UNC provider (redirector) to handle the I/O request.

7.51. Universal Naming Convention (UNC) Names The UNC is a naming convention for describing network servers and share points on those servers. UNC names start with two backslashes followed by the server name. All other fields in the name are separated by a single backslash. A typical UNC name would appear as: \\server\share\subdirectory \filename Not all of the components of the UNC name need to be present with each command; only the share component is required. For example, dir \\server\share can be used to obtain a directory listing of the root of the specified share.

7.52. Why MUP? One of the major design goals for networking in the Windows NT environment was to provide a uniform platform upon which vendors could build networking services. MUP is a vital part in allowing multiple redirectors to coexist in the computer at the same time. MUP frees applications from maintaining UNC provider listings themselves. This allows a client computer to have multiple redirectors loaded, and use File Manager to browse and access network resources without having to a provide unique syntax to each network redirector.

7.53. The Multi-Provider Router (MPR) The MPR provides a communication layer between applications that make Win32 Network API calls and the redirectors installed on the system. Not all programs use UNC names in their I/O requests. Some applications use WNet APIs (which are the Win32 network APIs). The Multi-Provider Router (MPR) was created to support these applications. MPR is very much like MUP. This layer receives WNet commands, determines the appropriate redirector, and passes the command to that redirector. Since different network vendors will use different interfaces for communicating with their redirector, there is a series of provider DLLs between the MPR and the redirectors. The provider DLLs expose a standard interface so that MPR can communicate with the provider, and they know how to take the request from MPR and communicate it to their corresponding redirector. The provider DLLs are supplied by the network vendor that wrote the redirector and should be installed automatically when the redirector is installed.

8. Documentation of Windows NT Workstation As discussed in previous chapters, Windows NT Workstation is the current standard 32 bit Desktop Operating System for {COMPANY}. A t present, only NT 3.51 is recommended for install on workstations - with Service Pack 4. Prior versions of Service Pack and NT may cause problems with certain programs. Newer versions of NT Workstation have not yet been fully tested (at present, the latest version of NT Workstation is only in Beta Release) and there are known problems which have yet to be fixed prior to installation to a corporate site.

8.1. Installation Procedures for Windows NT Workstation The following chapters document how Windows NT Workstation is to be installed on various different platforms with different installation methods. This document has been created to try and explain every step of the installation process, so that any user who has not installed NT Workstation before, can follow the basic steps and create a successful installation. By creating a “standard configuration” across a site, then support of this product will become easier. A standard configuration of a Windows NT Workstation inside {COMPANY} dictates that the following should be adhered to :

a. The Hard Disk should always be formatted to NTFS - NOT FAT, unless a Business Case can be written for special dispensation (e.g. a certain machine needs to continue to be dual-bootable for use with an incompatible software package etc.). We have decided to use NTFS since this file system is slightly faster than FAT and is more secure.

b. Data should not be written to the local Hard Disk unless the machine is a Portable.

Even in this situation, the user must be made aware that data loss is a frequent occurrence, and that data backup is the responsibility of the user. Data that is saved to the local hard disk has a high chance of being lost unless it is backed up. Users should always back up data to the Network, or store copies on Floppy Disks.

c. Portables should always log in locally to the local machine - whereas Desktops should

always log in to the Domain. Users on Desktops should be allowed to roam the WAN - whereas users on Portables should be able to connect to the domain when a portable is connected via a Docking Station or via Remote Access.***

d. A standard “suite” of software should be adhered to as often as possible. If a user

has a specific need to run an untested application, then they should be made aware that the application should be investigated by the Support Team prior to installation who will test it thoroughly and devise a standard installation guide. If the application violates the Windows NT Hardware Abstract Layer standards (HAL) - then the application will not run under Windows NT. This may include Scanning Software or older DOS applications.

e. Hardware that is not in the Windows NT HCL will not necessarily be unsupportable.

The Support Department will investigate hardware as thoroughly as p ossible, but if the hardware is proven to be unsupportable then similar solutions should be sought.

f. A recommendation of standardising the Video Display Adapters to 256 colours at

800x600 resolution should be made unless a user can be shown to require higher resolutions and colour depth (e.g. CAD applications or DTP Design). This then simplifies the installation procedure and leaves every user on the same Video Display Driver. A recommendation to use standard Screen Types has been put in place, i.e. - to use the Standard 15” monitor type with all 15” monitors.

g. The installation set will be located on a local Netware fileserver - this installation set is

copied prior to workstation installation from the {\\AVONBANK_01\SYS\WINNT35} fileserver which will be the master installation set. The workstation to be configured will therefore have to boot up using DOS Netware Client. The reasons behind this is because the DOS netware client is easier to configure than the DOS NT client - and a workstation can be booted up onto the network with a floppy disk and still have room for important programs on the floppy disk such as FORMAT.COM, EDIT.COM as well as FDISK.COM.

A decision not to use the Computer Profile Set-up (WINNTP.EXE) from the Windows NT Resource Kit was made due to limitations and support problems of this product. At a later stage, an installation guide using CPS or SMS may be created. Until that time we have decided to use WINNT.EXE as our standard installation program When creating a workstation installation, then the Standard Installation form must be filled in PRIOR to the installation. It is recommended that these forms be kept on file for access at a later date. This will also help to generate a “support log” of machines in the company. The Administrator of the Domain should give details concerning the IP Address etc. etc. to the Installation Engineer. If the IP Address is not correctly configured in the installation - then problems may occur. It is strongly recommended that the installation steps be adhered to. If not, then the NT Network that is installed and the Workstations configured may not be created to a standard. The installation guides have been created to the latest bug-fixes and with as much understanding of the hardware and software being implemented in the domain. Obviously, please print only the chapters that are required prior to installation. The Standard Installation Table that is completed should be stored by the IS department for reference.

8.2. Standard Installation Table - Please fill in prior to installation Value Example Value

Users Name Jon Steel

Computer Type Compaq Prolinea 5/133 cw 16Mb RAM

NIC Type 3com Etherlink III

NIC Interrupt IRQ 4

NIC Memory Base Address C000 hex

Installation Type Across the Network from \\AVONBANK_01\APPS\NT351

Domain Name to Join LM_PACKAGING

Primary Domain Controller 137.62.150.11

Secondary Domain Controller 137.62.150.12

Default Gateway 137.62.150.126

Primary WINS Server 137.62.150.11

Secondary WINS Server 137.62.150.12

DHCP Server (if used) 137.62.150.15

DNS Server (if used) 137.62.150.16

Workstation Name AVONBANK-W018

Workstation IP Address 137.62.150.97

Netware User Name JSTEEL

Netware User Password PASSWORD

Default Netware Server LMG_UK_AB_PROD_1

Mail User Name JSTEEL

Mail Password PASSWORD

Post-office Path (UNC) \\LMG_UK_AB_PROD_1\DATA \APPS\MAILDATA

Local Printer Names (UNC) \\LMG_UK_AB_PROD_1\ISLASER

Location of Service Pack 4 (UNC) \\AVONBANK_A001\D$\SP4

Application Suite MS Office, MS Mail, FDC

SNMP Community Name Public

SNMP Agent Contact Jon Steel - Extension 315

SNMP Location Avonbank, Bristol

SNMP Services ALL

Installation User ID & Password INSTALL / password

Other Hardware/Software or other requirements

US Robotics 33.6 V34, RAS, Volume Sizes, MS Exchange etc.

8.2.1. Compaq Prolinea Installation Guide This installation guide assumes that the workstation hardware has already been set up and tested thoroughly. BIOS Configuration should have taken place as per the standard Hardware Configuration Document. There are 3 different methods to install a Compaq Prolinea Workstation - over the network (recommended), via CD Rom (if applicable) or Floppy Disk Installation (Not recommended unless workstation is Standalone). Each method is documented. Make sure that the Standard Installation Table has been filled in and is available prior to installation. Installation

Step Over the Network

Installation (RECOMMENDED)

CD-ROM Installation (Standalone Installation)

Floppy Disk Installation (Standalone Installation)

1. Make sure that the Standard Installation form has been completed and that a unique IP address has been assigned to the PC. The Standard Installation Form should then be sent to the Central IS Department

2. Boot the Workstation using the Novell Network Boot Disk provided for the Network Card

Boot the Workstation using the NT Workstation Boot Disk 1

Boot the Workstation using the NT Workstation Boot Disk 1

3. Run Fdisk (supplied on the disk) and delete all partitions. Careful on Compaq’s NOT to delete the BIOS Partition (usually 2Mb). After partitions are deleted - create a new, single, large 16bit FAT partition.

4. Reboot, still using the Boot Disk

5. Format the C: drive - depending on the size of the Hard Disk, this could take some time.

6. Login to the server where NT Workstation resides. NETX usually places F: as the login drive.

7. Map a ROOT Drive (recommended F: - otherwise the automatic batch file will not work) to the location of the NT Files. E.g. - MAP ROOT F: = {servername}\ {volumename}\ {pathname}.

8. The Standard area for installation is AVONBANK_01\ SYS:WINNT35

Change over to this network drive - and change to the i386 directory.

9. run the set -up program using WINNT /T:C:\TEMP /B This command will not ask for Floppy Disks.

10. Enter F:\i386 as the source when prompted

11. This will copy the files from the server to the Hard Disk. Depending on traffic on the network, and the connection used, this may take some time to copy all of the files.

12. After the files have been copied - then remove the floppy disk and reboot.

13. Choose the NT3.51 Installation/Upgrade. Do NOT choose PC-DOS as all temporary files created so far would be deleted and the installation would have to start from scratch

14. NT will now copy files from the temporary directory for installation

15. Choose “ENTER” to set-up NT now

16. Choose “ENTER” for an express set-up

17. Choose “ENTER” to continue without a mass storage device

18. NT will now select the drive to install - press ENTER to install on the “C:FAT” partition

19. Convert the drive to NTFS - Press Enter on this value, then press “C” to convert the drive when prompted

20. Always install NT to C:\WINNT35. This helps when technical support is required

21. NT will now copy the files across from the temporary directory - this is quite fast

22. NT will now save the current configuration and will prompt to remove any floppy disks. Press “Enter” to reboot the system

23. NT will automatically start up and enter the GUI interface

part of the configuration 24. Enter the

COMPUTERNAME as the Name when prompted - NOT the user name

25. Enter “{COMPANY} ” as the Company Name. Click Continue/Continue when finished

26. Enter the Computer Name into the Computer Name box, click Continue/Continue

27. Choose the correct local language - e.g. “English (United Kingdom)”

28. Do NOT install a local printer - click “CANCEL” and then “OK”

29. NT will now attempt to detect the installed Network Card. If NT detects the card - it may come up with an error dialog box with “The Current Netcard Parameters are not verifiably correct and may result in usage problems or system failure. Use them anyway ?” Ignore this error and click “OK”

30. Choose ALL of the protocols to install on the workstation - i.e. NWLink IPX/SPX, TCP/IP and NetBEUI

31. NT will Configure and Bind the protocol stack to the network card

32. NT now copies the applications from the temporary directory area. This is automatic - and may take some time

33. Network configuration will now take place. A dialog box for the IPX/SPX settings will appear. Make sure that the Adapter is correct and that the Frame Type is set to “Auto”. Click on OK

34. A dialog box for the TCP/IP Configuration will now appear. Enter all values that have been entered in the Standard Installation Table. The Subnet Address is

always 255.255.255.128 When finished, click on OK to continue

35. NT will now attempt to start the network - if this part fails, then it will either be due to the NIC not connected or the IP Address has clashed with another. If this point fails - contact user support.

36. If the network successfully connects, a Domain Settings Dialog Box appears. Choose “Domain” and enter the domain name from the Standard Installation Table into this Dialog Box.

37. Highlight the “Create Computer Account in Domain” box - and enter the installation user’s ID and password in this area

38. Click on “OK” to continue. The computer account should create itself in the domain. If this is successful, then icons will be created in the Program Manager, else contact the Domain System Administrator

39. NT now configures the registry and asks for the Administrator Password for the Workstation - enter the given password in both dialog areas and click “OK”

40. Any DOS Applications on the Hard Disk will be searched for and icons will be created. NT will always ask what “Edit.com” is - choose “Dos Editor”

41. Set the Date and Time using the next dialog box

42. The Video Display adapter will now be auto-sensed. Check to make sure that this is the correct adapter by clicking “OK” in the dialog box, then “Test” and making sure that the display is visible for the 5 seconds. Resolutions to set on Workstations is 800x600, 256 colours and 640x480, 16 colours on Laptops and Portables (unless they can

support the Desktop Resolution). Click “OK/OK” to continue

43. The configuration will now be written to disk. This process is slow

44. Do not create a Boot Repair Disk - click “No” when prompted

45. The machine will now reboot. Upon restart, NT will convert the FAT Partition into NTFS (check that enough space is available) - then restart the machine automatically.

46. NT is now installed ! Installation of “Other Software” should now be carried out

8.2.2. Installation of other important software Installation



CD-ROM Installation Floppy Disk Installation

47. Log into the newly configured workstation. Log into the domain as Administrator

48. Start File Manager and map the first available drive (e.g. D:) to \\AVONBANK_W003 \cdrom Make sure that the “Reconnect at Logon” dialog box is NOT selected

49. Start Control Panel 50. Double click on Network 51. Click on “Add Software” 52. Choose “Client Services for

Netware”

53. Click Continue 54. Enter

“{mapped drive}:\i386” as the source

55. Click Continue 56. When the files have copied

across - click again on “Add Software”

57. Choose “TCP/IP Protocol and Related Components” - highlight this option

58. Click Continue 59. Choose “SNMP Service”,

“TCP/IP Network Printing Support” and “Simple TCP/IP Services”

60. Click Continue 61. Enter

“{mapped drive}:\i386” as the source

62. Click Continue 63. The software will copy

across and the SNMP Configuration Dialog will appear

64. Enter the Community name from the Standard Installation Table (Usually “public”)

65. Enter the Trap Destination IP Address as 137.62.150.30

66. Click on “Security” 67. Only Accept from IP Host

should be configured as

137.62.150.30 68. Click OK 69. Click on Agent 70. Contact information should

be the users name in full

71. Location Information should be the Building Name followed by the Users Extension Number

72. Make sure that ALL of the services are selected

73. Click on “OK” 74. Click on “Bindings” 75. Use the Show Bindings

button to select and change the following :

76. NetBIOS Interface - change order to WINS then NWLink NetBIOS then NWLink IPX/SPX then NetBEUI

77. Server - Change order to WINS then NWLink NetBIOS then NWLink IPX/SPX then NetBEUI

78. Workstation - Change order to WINS then NWLink NetBIOS then NWLink IPX/SPX then NetBEUI

79. Click on “OK” 80. Click on “OK” 81. Restart the computer

8.2.3. Service Pack 4 Installation - Compulsory 82. Log onto the PC into the Domain as Administrator

83. Run File Manager and connect the first available drive to \\AVONBANK_A001\D$

84. run UPDATE.EXE which is located in the .\SP4\i386 directory

85. Click on “OK” to start the installation. This should be quite fast

86. Restart Windows when prompted. When NT Loads into the “Blue Screen” - the server build

should appear as well as the Service Pack Revision

8.2.4. Configuration of the Workstation Installation

Step Installation Instructions

87. Log into the newly configured workstation. Log into the domain as Administrator 88. Start the registry editor by selecting File Run from the Program Manager menu and entering

REGEDT32 and press OK 89. Select the window HKEY_LOCAL_MACHINE 90. Select

\SYSTEM\CURRENTCONTROLSET\SERVICES\ BROWSER\PARAMETERS and add the following values Note - do NOT delete existing values. If you are unsure about this step, please contact the System Administrator IMMEDIATELY

91. IsDomainMaster REG_SZ FALSE 92. MaintainServerList REG_SZ FALSE 93. MasterPeriodicity REG_DWORD 1800 (Decimal) 94. BackupPeriodicity REG_DWORD 3600 (Decimal) 95. Select

\SYSTEM\CURRENTCONTROLSET\SERVICES\ LANMANWORKSTATION\PARAMETERS and add the following values Note - do NOT delete existing values. If you are unsure about this step, please contact the System Administrator IMMEDIATELY

96. Interval REG_DWORD 60 (Decimal) 97. KeepConn REG_DWORD 5 (Decimal) 98. Select

\SYSTEM\CURRENTCONTROLSET\SERVICES\ NETLOGON\PARAMETERS and add the following values Note - do NOT delete existing values. If you are unsure about this step, please contact the System Administrator IMMEDIATELY

99. Replication Governer REG_DWORD 75 (Decimal) 100. PulseMaximum REG_DWORD 14400 (Decimal) 101. PulseTimeout1 REG_DWORD 30 (Decimal) 102. Pulse REG_DWORD 1200 (Decimal) 103. Exit the Registry Editor 104. Start the File Manager 105. Click once on the C: Drive - make sure that the Root (\) is highlighted 106. Click on “Security” “Permissions” from the menu 107. Make sure that “Replace Permissions on Subdirectories” is chosen 108. Make sure that “Replace Permissions on Existing Files” is chosen 109. Click on “Everyone” in the “Name” box 110. Change the “Type of Access” to “Special Directory Access”. Change the settings so that

only “READ” and “EXECUTE”is selected - Click on “OK” / “OK” 111. Click on the “TEMP” Directory 112. Click on “Security” “Permissions” from the menu 113. Make sure that “Replace Permissions on Subdirectories” is chosen 114. Make sure that “Replace Permissions on Existing Files” is chosen 115. Click on “Everyone” in the “Name” box 116. Change the “Type of Access” to “Full Control” - Click on “OK” 117. Start up the User Manager for the Local Machine (MUSRMGR.EXE) 118. Click on “Policies” “User Rights” 119. Select “Change System Time and Date” 120. Add the user group “Everyone” - click on “OK” 121. The PC should now be restarted and any further software installed only by the

Administrator.

8.3. Installation Document on Portable PC’s {COMPANY} have a large number of portable PC’s throughout the company. Unfortunately, a lot of these lap-tops are sourced from different manufacturers and do not appear in the HCL. As such, there is a recommendation for Portable purchase - and portables such as the Viglen Dossier is strongly advised NOT to have Windows NT installed on it. However, we have created a Standard Installation Guide for many of these portables although we stress that compatibility with NT is not fully supported.

8.3.1. Problems arising when using Portables Because of the way that portables are designed and manufactured, there are some inherent problems to be wary of when investigating an installation of NT compared to a standard Desktop Machine.

8.3.2. Docking Stations When a portable then goes “on the move” - they lose the network card. Because of the way that NT runs, there is no way to produce 2 separate configurations, 1 for docked and 1 for undocked. Instead, the network protocols and drivers try to load but fail. Because the drivers fail, an error message appears with “Some drivers may have failed” and a second error appears with “Please check event logs”. This is irritating, but does not affect how the system behaves. Microsoft’s solution is to ignore these errors since the machine will continue to work perfectly well - especially if there are no persistent drives trying to be mapped using File Manager. It is envisaged that NT4 will have a facility to have more than 1 hardware profile - therefore giving the user the ability to choose whether the machine is docked or undocked. Another way around this problem is to use PCMCIA Network Adapters in machines which can accept them. Therefore, the PCMCIA card is always present, and the drivers will load correctly.

8.3.3. Power Management It is recommended that NT users run NTFS on their workstations as their File System. Because of the way NTFS works and because of the way that NT runs - it is not recommended to utilise power management features on certain portables - e.g. turning off the hard disk when not in use etc. The reasons behind this are mainly due to the fact that NT does not correctly identify hardware with power management features, and will try and access the hardware (and fail to) when the hardware has been switched off. NT will therefore provide a hardware error - and there is a good chance that the NT session will crash.

8.3.4. Plug and Play At present, Plug and Play is not supported on Windows NT - and is not envisaged to be supported on NT Version 4 either. Plug and Play is the facility to PLUG a device into a computer system, switch on

Using Docking Stations With Windows NT Article ID: Q119505 Revision Date: 21-JUN-1995 The information in this article applies to: - Microsoft Windows NT operating system version 3.1 - Microsoft Windows NT Advanced Server version 3.1 SUMMARY Although the Windows NT Hardware Compatibility List (HCL) does not specify any compatible docking stations for laptop or notebook computers, these devices should work correctly with Windows NT. MORE INFORMATION Because a docking station is really just an extension of the system bus, any system that is listed on the Windows NT HCL should function properly under Windows NT with the docking station attached. Please note, however, that adapters installed in a docking station should be selected from among those listed in the HCL as compatible, just as with any other system. Additionally, if Windows NT is configured with optional adapters installed in a docking station, then is later used away from the docking station, error messages may be displayed at start-up when Windows NT is unable to locate those devices. Aside from these messages, normal operation should be unaffected.

that computer system - whereupon the Operating System automatically recognises the new device, automatically installs any drivers for that device, and then the user can PLAY with the device immediately. The user does not have to be technical to be able to install a device - unlike other non plug-and-play operating systems. The only plug-and-play operating system at present is Windows ‘95 - but plans have been created by Microsoft to incorporate P&P into Windows NT.

8.3.5. Portable Peripherals Because of the way that portables are manufactured, and the variety of manufacture, portables are often very diverse in their hardware specifications. There are normally a large number of different trackballs, screen types and internal CD-ROM Drives. Obviously, there is a good chance that some hardware will not be fully supported by NT. A glance at the NT Hardware Compatibility List shows that there are only a few devices and only a few Portable Manufactures supported by Microsoft. This does not necessarily mean that it is “impossible” to run NT on a certain machine - but it is recommended to choose a portable that is supported by Microsoft. As an example of this, machines such as the Viglen Dossier use an internal Trackball Device which is normally mapped to the 1st Serial Port. It has not been possible to get this device working under NT 3.51 - although connecting a Serial Mouse to the external port or the port on the Docking Station works perfectly. Screen types vary tremendously - and the correct drivers should always be selected wherever possible. It is recommended to use the 16 colour Standard VGA driver for black and white portables and move to a Standard Super VGA Driver with 256 colours for colour portables. However, the drivers should be tested thoroughly before use and the manufacturers should be contacted concerning their recommendations.

8.3.6. Viglen Dossier Advanced 486 Installation Guide Problems with the Viglen Dossier include the following : a. Incompatibility with the 3.51 PCM CIA Driver (we use the 4.0 Driver) b. Incompatibility with the Trackball Device c. No power-management facilities However, if the above problems are discounted - then the machines work well. Installation

Step Over the Network Installation

(RECOMMENDED) Floppy Disk Installation (Standalone

Installation) 122. Boot the Viglen with the Viglen Start-up

Disk. Make sure that the machine is docked in the docking station and that it has access to the network

123. Upon Bootup - go into the BIOS Settings. 124. Make sure that no power management

features are enabled in the BIOS Settings

125. Save the BIOS Configuration and reboot the machine

126. Go through Standard Generic Installation of Windows NT Workstation

127. Make sure Other Software (such as SNMP and TCP Services) have been installed

128. Make sure Service Pack 4 has been installed and the machine has been restarted

129. Log into the Local Machine as Administrator 130. Go into DOS or Filemanager and copy the

PCMCIA.SYS file into \WINNT35\SYSTEM32 \DRIVERS

131. Restart the PC 132. Log into the Local Machine as Administrator 133. Open Control Panel 134. Double Click on Devices 135. Highlight “PCMCIA” 136. Click on the “START” button and make sure

that the service starts. If not, contact the System Administrator

137. Change the “START -UP” to “Boot” - Click “OK” and “Close”

138. Restart the PC - the PCMCIA devic e should now be working and will automatically recognise any PCMCIA cards installed

8.3.7. Toshiba Portables (Satellite Pro and Tecra Range) Installation Guide Due to the way that the Toshiba Portables access their BIOS settings to set hardware options, NT will normally have a problem installing from scratch on these systems. It is therefore recommended to install Windows NT in its own directory when Windows 3.x is still present on the system, and then convert the machine to NTFS at a later stage (erasing the older Windows config and programs). This should get over this problem.

9. Documentation of Windows NT Server Windows NT Server shares its design with NT Workstation. In addition to its capability of running desktop applications, NT Server is targeted for back-end or application service duty such as running SQL Server.

9.1. Installation Guide to Windows NT Server - Generic Please note that if the server is to be installed as an SQL or Collabra Server - then there are special installation instructions that need to be adhered to. Please check with the NT Administrator prior to installation. Installation


Installation Floppy Disk Installation CD Rom Installation

(RECOMMENDED) 139. Make sure that the Standard Installation Form has been completed and a unique IP Address

has been assigned. Make sure that the type of installation has been chosen.

140. Boot up using the Windows NT Server Set-up Boot Disk - Disk 1

141. NT will start and load certain files. Insert Disk 2 when prompted

142. Set-up NT Now by pressing “Enter”

143. Choose “Express” as set-up type

144. Mass Storage Detection - Enter - Continue

145. Insert Disk 3 when prompted

146. Do NOT specify any mass storage device - press “Enter” to continue at this point

Select the correct mass storage device (CD Rom Drive). If the drive has not been selected, and the list does not contain the CD Rom Drive Type - then move over to the Floppy Disk installation and continue using that installation type.

147. Press D to DELETE all partitions. Press “Enter” and then “L” to confirm deletion

148. Press “C” to create a partition. The partition will normally be as large as possible unless there are reasons for multiple volumes. Press “Enter”

149. Press “Enter” to install on the Unformatted Partition. Format using NTFS - press “Enter”

150. The drive will now format. Depending on the volume size and the speed of the hard disk, this may take some time

151. Choose “ \WINNT35” as the location for the NT Files. Press “Enter” to continue

152. Insert Disk 4 when prompted - Press “Enter”

NT will now copy all of the files over to the Hard Disk







159. Remove Floppy Disk - press “Enter” to restart when prompted

160. The machine will now automatically start up NT in the GUI Mode

161. Enter the Computer Name from the Standard Installation Form as “Name” when asked

162. Enter “{COMPANY}” as the Company name when prompted

163. Click “Continue/Continue”

164. Enter the Product ID from the Floppy Disk when asked - Click “Continue/Continue”

165. Choose Domain Controller as Server Security role

166. Choose “Per Server” as Licensing type - and enter the number of licenses purchased. Click on “Continue”

167. Click on the “I agree......” box - click on “OK”

168. Type in the Computername from the standard installation form when required

169. Click on “Continue/Continue”

170. Choose the Local Language from the list - click on “Continue”

171. “CANCEL” to bypass selecting a printer - then click “OK” to continue

172. NT will now automatically select the Network card automatically.

173. Some network cards will produce the error “The current netcard parameters are not verifiably correct...” - Click on “OK” to ignore this message

174. Choose ALL of the protocols - click on “Continue”

175. NT will now carry through

the disk copying process. NT will now carry through copying the files from the cd-rom

176. Insert Disk 5 when prompted - Click on “OK”

















193. Choose the “Auto Frame Type Detection” for the IPX/SPX Protocol - click on “OK”

194. Type in the IP Address and other details from the Standard Installation Table - click on “OK” to continue

195. NT Will now start the network

196. Choose “Backup Domain Controller” as the Server Type - type in the domain name next to this dialog box

197. Enter the Domain Administrator’s user ID and Password - click on “OK” to continue

198. The Program Manager groups should now be set up at this stage

199. Choose “MS-DOS Editor” when asked what application

EDIT.COM is

200. Click on “Continue”

201. Select Date and Time Settings - click on “OK” to continue

202. NT will try to discover the type of Video Adapter installed. Check to make sure this is correct. Click on “OK”

203. Choose 800x600, 256 colours as the screen resolution if possible

204. Click on “TEST to confirm that these settings will work

205. NT will display a test screen. After 5 seconds, NT will ask “Did you see the test bitmap properly”

206. Click “YES” if the screen was confirmed

207. Click on “OK/OK”

208. NT will now save the configuration

209. NT will ask whether you would like to create an Emergency Repair Disk - select “NO”

210. Set-up will now replicate the security account information from the PDC - DO NOT cancel, even though the offer is given

211. Remove any floppy disks, and reboot the machine.

9.2. Insta llation of Gateway Services for Netware Installation


212. Make sure that the Standard Installation Form from chapter 3.1.1 has been completed and an IP Address has been assigned and that the Server has been installed with NT, Service Pack 4 and other software as per the installation instructions

213. You must now make sure there is a group called NTGATEWAY on the NetWare server that the NT Server will connect to. In this group is one user defined, it is NT admin with same password. See following example: NTGATEWAY = (NW-group) NTNEHER (NW-user with password: ntnwgw) This group will also need “Trustee Assignments” allocated for any volumes/directories that need to be accessible from the NT Server. This group must have "Trustee Assignments" (full access) to the postoffice. (E.g. Neher: \\neher\vol1\daten\Maildata) and also to Novell Netware drive for Backup (see IV. Backup) and for the collabra client installation program (see II. Collabra Share Standard Installation Guide, section 3. Installation of the collabra share client/server edition).

214. Open the MAIN group and start CONTROL PANEL.

215. Load GSNW 216. “Gateway Service for NetWare” - This will show your username and the server it connected

you to. Select your preferred server and press GATEWAY 217. “Configure Gateway” - tick the ? Enable Gateway box

Gateway Account : NetWare user called NT-POSTOFFICENAME Password : As supplied

Confirm Password : As supplied 218. Connect drive M: to postoffice. With file-manager connect the NW postoffice and select

"reconnect at next logon". Enter the NetWare path to the local post office on the NetWare server you are connecting to. This should be in the format “\\Servername\Volume\path”. E.g. (\\neher\vol1\daten\Maildata)

219. Press OK followed by another OK 220. Exit Control Panel 221. Select File, Shutdown from the Program Manager menu and select Shutdown and Restart. 222. Once the machine restarts log on as NT-POSTOFFICENAME 223. Open the MAIN program group and start FILE MANAGER 224. Select the directory C:\USERS\DEFAULT 225. Select Disk, Share As from the File Manager menu or use the appropriate button on the tool

bar 226. Change the Share Name to “DEFAULTs” and press OK. Once the system is up and running

this is where the user profiles will be stored. 227. Create the following directory structure :-

D:\APPS \COLLABRA \AGENTMGR \BIN D:\COLLABRA \FMSERVER \FORUMS \REGISTRY D:\DATA D:\MAILSRV

228. Create the following network shares under the File Manager

Share Name Path Permissions APPS C:\APPS Domain Admins - Full, Domain Users - Read COLLABRA C:\COLLABRA Everyone - Full DATA C:\DATA Domain Admins - Full, Domain Users - Read MAILSRV C:\MAILSRV Domain Admins - Full, NT Mail- Full

229. Exit File Manager

9.3. Changes to parameters and registry settings - NT Server Installation


230. Log into the Server as the Administrator 231. Start the registry editor by selecting File Run from the Program Manager menu and entering

REGEDT32 and press OK 232. Select the window HKEY_LOCAL_MACHINE 233. Select

\SYSTEM\CURRENTCONTROLSET\SERVICES\ BROWSER\PARAMETERS and add the following values Note - do NOT delete existing values. If you are unsure about this step, please contact the System Administrator IMMEDIATELY

234. IsDomainMaster REG_SZ FALSE 235. MaintainServerList REG_SZ FALSE

236. MasterPeriodicity REG_DWORD 1800 (Decimal) 237. BackupPeriodicity REG_DWORD 3600 (Decimal) 238. Select

\SYSTEM\CURRENTCONTROLSET\SERVICES\ LANMANWORKSTATION\PARAMETERS and add the following values Note - do NOT delete existing values. If you are unsure about this step, please contact the System Administrator IMMEDIATELY

239. Interval REG_DWORD 60 (Decimal) 240. KeepConn REG_DWORD 5 (Decimal) 241. Select

\SYSTEM\CURRENTCONTROLSET\SERVICES\ NETLOGON\PARAMETERS and add the following values Note - do NOT delete existing values. If you are unsure about this step, please contact the System Administrator IMMEDIATELY

242. Replication Governer REG_DWORD 75 (Decimal) 243. PulseMaximum REG_DWORD 14400 (Decimal) 244. PulseTimeout1 REG_DWORD 30 (Decimal) 245. Pulse REG_DWORD 1200 (Decimal) 246. Exit the Registry Editor 247. Shutdown and Restart

9.4. Installation Guide - NT Server on Compaq Prosignia Installation



Floppy Disk Installation CD Rom Installation

248. Make sure that the Standard Installation Form from chapter 3.1.1 has been completed and an IP Address has been assigned

10. Introduction to the Browser Service To efficiently share resources across a network, users should be able to find out what resources are available. Windows NT provides the Computer Browser service to display a list of currently available resources. The Microsoft Windows NT Computer Browser service provides a centralised location for a list of available network resources. This list is distributed to specially assigned computers that, along with their other normal services, perform browsing services. "Browser" computers eliminate the need for all computers to maintain a list of all shared resources on the network. The Browser service lowers the amount of network traffic needed to build and maintain a list of all shared resources on the network by assigning the Browser role to specific computers. This also frees the CPU time each computer would have had to use creating a network resource list.

10.1. Browser Server Roles The responsibility of providing a list of network resources to clients is distributed among multiple computers on a network. The Browsing roles of these computers are known to the Browser service as Potential Browser, Master Browser, Backup Browser, and Browser Clients (Non-Browsers). Both Windows NT 3.5 Workstations and Windows NT 3.5 Server computers can perform any of these roles. These computers collect and maintain a list of available network resources. These roles are defined below:

10.2. Master Browser The Master Browser is the computer that maintains the master copy of the network resource list, and is responsible for collecting the information used to create the list. It is also responsible for distributing the browse list to the Backup Browsers.

10.3. Preferred Master Browser An administrator can configure a specific computer to be the Preferred Master Browser. When this computer is started, it will designate itself as the Master Browser for the domain or workgroup. If there is already a Master Browser, and other computers are up and running in the workgroup before this one was turned on, the Preferred Master Browser forces an "election." The election process ensures that there will only be one Master Browser per workgroup or domain and results in the Preferred Master Browser assuming the role of the Master Browser. A Preferred Master Browser will not win an election over a Primary Domain Controller as a PDC always functions as the Master Browser of the domain. More about the election process is covered later in this chapter.

10.4. Backup Browsers A Backup Browser is a computer that receives a copy of the network resource list from the Master Browser. It then distributes the list to the Browser clients upon request.

10.5. Potential Browser A Potential Browser is a computer that is capable of a maintaining a network resource (browse) list, but will not do so unless instructed to by a Master Browser.

10.6. Non-Browser A non Browser is a computer that has been configured so that it will not maintain a network resource (browse) list. Client computers are commonly non-Browsers.

10.7. The Browse Process The Windows NT Computer Browser service operates in the following manner: 1. After start-up, all computers that are running the Server service announce their presence to the

Master Browser in their workgroup or domain. This happens regardless of whether they have shared resources to advertise.

2. The first time a client computer attempts to locate available network resources, it contacts the

Master Browser for the domain or workgroup for a list of Backup Browsers. 3. The client then requests the network resource list from a Backup Browser. 4. The Backup Browser responds to the requesting client with a list of domains and workgroups

and the list of servers local to the client's domain or workgroup. 5. The user at the client either selects a local server or a domain or workgroup to view available

servers. 6. Finally the user selects the appropriate server and searches for the desired resource on which

to establish a session to use that resource, and contacts the appropriate server. For example, a Windows NT Workstation computer that belongs to a domain is turned on (Step 1). A domain user logs on to the domain and starts File Manager. The user chooses the Connect Network Drive button on the toolbar and sees "Working..." in the Shared Directories box (Steps 2, 3, and 4). The user sees a list of workgroups and domains and selects the domain to expand the list of computers (Step 5). Then the user selects one of the computers and expands a list of available shared directories on that computer (Step 6).

10.8. Browser Criteria Browser criteria is a means in which to determine the hierarchical order of the different types of computer systems that are in the workgroup or domain. Each Browser computer has certain criteria, depending on the type of system it is. The criteria include: The operating system The operating system version Its current role in the browsing environment The criteria ranking is used during an election. An election is used as a "voting" process in determining which computer should be the Master Browser in the event the current Master Browser is determined unavailable.

10.9. The Browser Election Process The election process insures that only one Master Browser exists per workgroup or domain. An election is initiated by a computer when any of the following occurs: A client computer cannot locate a Master Browser. A Backup Browser attempts to update its network resource list and cannot locate the Master

Browser. A computer that has been designated as a Preferred Master Browser comes on-line. Any of these computers can initiate an election by broadcasting a special packet called an election packet. This election packet contains that requesting computer's criteria value. All Browsers will receive the election packet. When a Browser receives an election packet, the Browser examines the packet and

compares the requesting computer's criteria value with its own election criteria. If the receiving Browser has better election criteria than the issuer of the election packet, the Browser will issue its own election packet and enter what is referred to as an "election in progress" state. This process will continue until a Master Browser is elected, based on having the highest ranking criteria value.

10.10. Configuring a Browser To determine whether or not a Windows NT computer will become a Browser, when it initialises, the Browser service looks in the Registry for the following parameter: \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\Browser\Parameters\MaintainServerList

For optimisation purposes, it is possible to configure a computer to become a Browser, or to prevent a computer from becoming a Browser. The MaintainServerList parameter can have the following values: Parameter Value No This computer will NEVER participate as a Browser server. Yes This computer will become a Browser server. Upon start -up, this computer will

attempt to contact the Master Browser to get a current browse list. If the Master Browser cannot be found, the computer will force one to be elected. This computer will either be elected as the Master Browser or become a Backup Browser. Yes is the default value for Windows NT Server domain controller computers.

Auto This computer may or may not become a Browser server, depending on the number of

currently active Browsers, and is referred to as a Potential Browser. This computer will be notified by the Master Browser as to whether or not it should become a Backup Browser. Auto is the default value for Windows NT Workstation and Windows NT Server (non-domain controller) computers.

10.11. Configuring a Preferred Master Browser A Windows NT Workstation or Windows NT Server can be configured as a Preferred Master Browser. When the Browser service is started on a computer configured as a Preferred Master Browser, the Browser service will force a Browser election to occur. Preferred Master Browsers are given an advantage in elections, such that if all other things are equal, a Preferred Master Browser will always win an election and become the Master Browser. To configure a computer as a Preferred Master Browser, set the following Registry parameter value to True or Yes: \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\Browser\Parameters\IsDomainMaster

Unless the computer has been already been configured as the Preferred Master Browser, this value will be False or No. This is true even if the computer is currently the Master Browser.

10.12. Browser Operations As the Master Browser and Backup Browsers are established, each has its own role to play in the operation of the browsing environment. The Browsers need to communicate with each other and provide service to client computers.

10.13. Browser Announcements When a computer that is running the Server service comes on-line, it must inform the Master Browser that it is available. It does this by announcing itself on the network.

10.14. All Servers Each computer announces itself to the Master Browser periodically by broadcasting on the network. Initially each computer announces itself every minute. As the computer stays running, the announcement time will be extended to once every 12 minutes. If the Master Browser has not heard from the computer for three announcement periods, the Master Browser will remove the computer from the browse list.

10.15. Backup Browsers In addition to announcing themselves, Backup Browsers call the Master Browser every 15 minutes to obtain an updated network resource (browse) list, as well as a list of workgroups and domains. The Backup Browser caches these lists and will return the browse list to any clients who send out a browse request to the Backup Browser. If the Backup Browser cannot find the Master Browser, it forces an election.

10.16. Master Browsers In addition, Master Browsers periodically announce themselves to the Backup Browsers with a broadcast. When Backup Browsers receive this announcement, they refresh their Master Browser name with the new information.

10.17. Master Browser Master Browsers are responsible for overseeing the entire browsing system and are responsible for receiving announcements from Windows NT 3.1, Windows NT Advanced Server 3.1, Windows for Workgroups, Windows NT Workstation 3.5, Windows NT Server 3.5, and LAN Manager systems. Master Browsers also return lists of Backup Browsers to Windows NT 3.1, Windows NT Advanced Server 3.1, Windows NT Workstation 3.5, Windows NT Server 3.5, and Windows for Workgroups clients for their local subnet. As was discussed earlier in this section, when a system starts and its MaintainServerList parameter is Auto, the Master Browser is responsible for telling the system whether or not to become a Backup Browser. If the Master Browser has just won an election and its browse list is empty, it can force all systems to register with it. The Master Browser does this by broadcasting a "RequestAnnouncement" packet. All systems that receive this packet must answer randomly within 30 seconds. This 30 second range for responses prevents the Master Browser from becoming overloaded and losing replies, and also prevents the network from being flooded with responses. If a Master Browser receives an announcement from another computer that claims to be the Master Browser, the Master Browser will demote itself from Master Browser and force an election. This ensures that there is never more than one Master Browser in each workgroup or domain.

10.18. Determining the Number of Browsers In a domain there will be three Backup Browsers at most. This is regardless of the number of computers in the domain. If you have a large domain, you may want to either break it up, or increase the system performance for the Backup Browsers in the domain.

10.19. How Client Computers Access the Browse List The Master Browser maintains a list of network resources and makes this list available to Backup Browsers on the network. A client computer goes to a Backup Browser to get the current list. A client computer needs to see the browse list whenever a "net view" command is run at the Command Prompt, or when the File Manager Connect Network Drive dialog box is displayed. If this is the first time that the client has tried to access the browse list, it needs to find out which computers are the Backup Browsers for its workgroup or domain. The client does this by issuing a "QueryBrowserServers" broadcast. The QueryBrowserServers request is received and processed by the

Master Browser for the client computer's workgroup or domain. The Master Browser returns a list of Backup Browsers that a re active within the workgroup or domain being queried.

10.20. Browsing Failures If a computer fails or simply goes off-line, it will be removed from the browse list in a predetermined time frame. If the computer played a role in the browse environment, further action takes place depending on what role it played.

10.21. Non-Browser Computers If a Non-Browser computer fails to announce itself to the Master Browser, it will eventually be removed from the list. For example, if the computer is powered off without being shutdown or if the Server service fails, it will not announce itself. In this case, it is removed from the network resource list. After three missed announcement periods (between 1 and 12 minutes each) the Master Browser removes the computer from the browse list. Therefore, it may take up to 51 minutes before all of the Browsers know of a systems failure, up to 36 minutes for the Master Browser to detect the failure, and 15 minutes for all of the Backup Browsers to retrieve the updated list from the Master Browser.

10.22. Backup Browsers If a Backup Browser fails, it will be removed from the Master Browser browse list in the same amount of time as a Non-Browser. This is because they announce themselves in the same manner. If a client attempts to retrieve a browse list from the missing Backup Browser, the client will select another Backup Browser from its list of three Backup Browsers. If all of the clients' known Backup Browsers fail, the client will attempt to get a new list of Backup Browsers from the Master Browser. If the client is unable to contact the Master Browser, the client will force an election.

10.23. Master Browser When a Master Browser fails, a Backup Browser will detect the failure within 15 minutes. When this happens, a Backup Browser will force an election to select a new Master Browser.

10.24. Server Shut Down When the computer is shut down normally it will make an announcement that will cause the Master Browser to remove it from the list. If a Backup Browser is shutting down, it will send an announcement to the Master Browser that does NOT specify the Browser service in the list of running services. If a Master Browser is shutting down, it will send a "ForceElection" broadcast so that a new Master Browser can be chosen.

10.25. Browsing Across Multiple Workgroups and/or Domains Not only do Master Browsers need to communicate within a workgroup or domain, but they need to communicate between workgroups and domains. This allows users to be able to retrieve lists of other workgroups and domains. Windows NT adds a new level of functionality to the "net view" and File Manager connect requests that allows clients to retrieve a list of available workgroups and domains from the Master Browser. Upon becoming a Master Browser, each Master Browser will broadcast a "DomainAnnouncement" to each domain every minute for the first five minutes of its life as Master Browser. After the first five minutes, the Master Browser will make "DomainAnnouncement" broadcasts once every 15 minutes. If a workgroup or domain has not announced itself for a period equalling three times the announcement period, the workgroup or domain will be removed from the list of workgroups and domains. Therefore, it is possible that a workgroup or domain will appear in the browse list for up to 45 minutes after the workgroup or domain has ceased operations. It is the responsibility of the Master Browser in each workgroup or domain to receive "DomainAnnouncement" packets from other workgroups and domains. The Master Browser uses these announcements to build a list of available workgroups and domains. This list is also given to the

Backup Browsers every 15 minutes so that they can return a list of network resources available in their workgroup or domain as well as being able to return a list of other workgroups and domains. The "DomainAnnouncement" packet contains the name of the domain, the name of the Master Browser for that domain, and whether the Master Browser is running Windows NT Workstation or Windows NT Server. In addition, if the Master Browser is running Windows NT Server, the "DomainAnnouncement" will also specify if the system is the domain's PDC.

11. Implementing WINS on a Windows NT Server Windows Internet Name Service (WINS) maps NetBIOS names to IP Addresses. WINS is simply a dynamic repository for NetBIOS names, mapping a 16-character NetBIOS name to an IP address. WINS is not used to locate resources, such as printers, servers and so on. Instead, this is handled by the separate database server known as the Browse Master. After a client has located a resource’s NetBIOS name by browsing, it may use several mechanisms, including WINS, to convert the NetBIOS name to an IP address.

11.1. Introduction and Overview of WINS The primary consideration of a successful Microsoft Windows NT domain implementation is that your users need to be able to view the domains they have access to. There are several ways to configure their environment for this, but the most efficient is the Windows Internet Naming System (WINS). WINS allows users both local and remote login capabilities that far surpass any other configuration. However, if WINS is improperly configured on the client, the local servers, or the enterprise servers, it can be more of a headache than a help. This document will outline what a successful WINS implementation includes, and how to implement one. It will also give four scenarios of what can become a successful implementation.

11.2. WINS Implementation For users across an enterprise to be able to view and access the servers they use, they need to be able to bro wse those servers. Static implementations of browsing lists are hard to administer and difficult for mobile users to use. WINS is recommended as a dynamic alternative. A robust WINS implementation will permit users to log in to their local network (or a remote network, where DHCP will give their workstation an IP address) and access the resources they need. The WINS backbone passes the information about all servers (and workstations, if necessary) throughout the system. WINS hubs can then be set up to relay information across the enterprise. Then the local WINS servers will receive this information and propagate it to the users' workstations.

11.3. Four Scenarios This paper covers four possible WINS implementation scenarios. You may need to modify these scenarios to better meet your companies needs. The four possibilities are: 1. Dual-Hub WINS Environment -- where all WINS information is replicated everywhere and all

users can browse any connected domain's servers and workstations 2. Hub/Local WINS Environment -- where a user will have the local WINS server as his Primary

and the HUB as his Secondary WINS server 3. Hub/Dual Local WINS Environment -- where a user has two local WINS servers, one for

Primary and the other for Secondary. 4. Hub/Spoke WINS Environment -- where a user has two spoke WINS servers, one for Primary

and the other for Secondary.

11.3.1. Dual-Hub WINS Environment

Figure 1 Hub WINS Servers -- In the Dual-Hub environment, both WINS servers are full replication partners with each other. This allows all enterprise WINS information to be replicated across the environment. All Other Resources -- All other resources will point to one hub server as their Primary and the other as their Secondary WINS Server. This will fully populate the two WINS servers with the enterprise WINS information. This arrangement allows user access to the resources they need when either WINS server is inaccessible. It keeps duplicate machine names from being allowed on the network, and immediately flags installations that have duplicate names. This implementation will allow conflicting machine names to be changed at the earliest possible time. A drawback with this implementation is that with large networks, the WINS database can be huge. Administration of this database is difficult, since both servers own the entire database.

11.3.2. Hub/Local WINS Environment

Figure 2 Hub WINS Servers -- In the Hub/Local environment, the Hub WINS servers are full replication partners with only themselves. They will provide the necessary backbone information for the enterprise. You should keep the number of the Hub WINS servers to a minimum. Local WINS Servers -- The Local Hub Servers act as the workstations Primary WINS Servers. These servers will replicate from, but not back to, the Hub Servers. This will allows a localisation of WINS information. The local WINS information built on these servers will be accessible to the local users and not needlessly transferred to the enterprise. Enterprise-Wide Resources -- Enterprise-wide resources point to one hub server as their Primary WINS Server and another as their Secondary. This allows these resources to be viewed across the enterprise. User Workstations -- To minimise the impact of multiple users' workstations being browsed across the enterprise, these will point to the Local WINS server as their Primary WINS Server and the Hub as their Secondary WINS Server. This allows users to access local resources and enterprise resources, but keeps information about these machines local to the enterprise. Local Resources -- Local NT Domain resources are treated as local workstations in the Hub/Local environment. They point to the Local WINS Server as Primary WINS Server and the Hub Server as their Secondary WINS Server. This arrangement allows users to access the servers they need for their daily business. It also keeps information isolated to Local WINS Server environment, while limiting the WINS information that is populated across the WAN. The only drawback to this implementation is that the Local WINS server might go down, making the user workstations visible to the enterprise. This could make any duplicate workstation names visible to each other, making them both unreachable. A method to circumvent this from occurring is to set up an enterp rise naming convention which keeps distinct names for all system resources.

11.3.3. Hub/Dual Local WINS Environment

Figure 3 Hub WINS Servers -- Like the Hub/Local environment, the Hub WINS servers are full replication partners with only themselves, keeping enterprise WINS information to a minimum. Local WINS Servers -- Though these again are the same as they are in the Hub/Local environment, there are twice as many per local network. This allows them to be used as both Primary and Secondary WINS Servers for local resources and workstations. Enterprise-Wide Resources -- Enterprise-wide resources are exactly the same as they would be in the Hub/Local environment. Their WINS information is necessary across the enterprise, so they use Hub servers as Primary and Secondary WINS Servers. User Workstations -- The use of Local WINS Servers for both Primary and Secondary WINS Servers allows users to remain local to their environment even if one of their WINS Servers fails. Local Resources -- The Local NT Domain Server points to the Local WINS servers as Primary and Secondary WINS Servers, just as the user workstations are configured. While this configuration removes no functionality from the user perspective, this WINS installation is more robust than the Hub/Local installation, and less bandwidth intensive than the Dual-Hub environment. All local traffic remains isolated even if one of the Local WINS Servers go down, and only enterprise WINS information gets replicated across the enterprise. There are two drawbacks to this installation. The first is that it requires that more than one machine be configured as a WINS server. For enterprises that have minimum resources, it may be an issue. These enterprises may have to use another office's Local WINS Server as a second Local WINS Server to accomplish this configuration. The second drawback to this is that since local names are kept insulated from the enterprise environment, duplicate machine names can be used. When these machines try to access the same enterprise resources, only the first access will succeed. Therefore, this environment only works when there is no chance that two machines of the same name will need the same enterprise resource.

11.3.4. Hub/Dual "Spoke" WINS Environment

Figure 4 Hub WINS Servers -- In the Hub/Spoke environment, the Hub WINS servers are full replication partners. Though they collect all other WINS databases, the Hub servers own no portion of the database themselves except for the enterprise resources. Spoke WINS Servers -- Though these look the same as in the Hub/Dual Local environment, the Spoke WINS servers are full replication partners. They are the actual database owners. Enterprise-Wide Resources -- Enterprise-wide resources are exactly the same as they would be in the two Hub/Lo cal environments. Their WINS information is necessary across the enterprise, so they use Hub servers as Primary and Secondary WINS Servers. User Workstations and Local Resources -- The workstations and local resources point to the Spoke WINS servers for both primary and secondary WINS services. The object of this is to segment the WINS database into logical parts. This way, if part of the database seems corrupt, a database owner can dump that portion without affecting the entire database. In an organisation with a fully implemented naming convention, the Hub/Spoke environment gives the flexibility of having smaller databases, yet still having enterprise access to necessary resources. If a roving user needs access to a home office server while visiting overseas, this WINS implementation is able to support these requests. This implementation has the same hardware drawback as the Hub/Dual Spoke environment, in that additional hardware is necessary to support the spoke servers. However, the problem of duplicate machine names disappears.

11.4. Comments The primary goal of a successful WINS implementation is simplicity. Obviously, the dual-hub environment supplies this. Secondary to simplicity is manageability of the WINS database. When the enterprise outgrows the initial dual-hub environment that almost every enterprise begins with one of the other WINS must be considered. If outlying offices are implementing their own WINS servers, one of the local environments is recommended to keep unwanted (and possibly corrupt) data from entering the enterprise database. If the enterprise is just too large, then the hub-spoke might be considered. If the WINS implementation fits the above guidelines, it should serve well. If a corrupt database appears (for instance, old machines being reintroduced after they've been removed), look for the signs of a poor implementation. Signs of a poorly implemented WINS environment are loops in the implementation, and very long push/pull chains. In either of these implementations, there is the possibility of old data corrupting the database. When a server is deleted on one end of the chain or in the loop, replication of old data back to the database can corrupt it. If a poor implementation is found, an option is to rebuild WINS into one of the described models. The sooner this is done, the better. If hubs are brought up and the current WINS database is dumped on a Friday afternoon, then setting up replication to the hubs will populate the WINS database with clean data by Monday morning. However, the safest plan is to implement a strong WINS architecture from the start.

11.5. WINS in {COMPANY} The WINS model chosen is the Hub/Dual Local WINS Environment for the master domain. This model is the best for the environment since it utilises a simple and central approach. The model of the network should be as follows :

LMPACKAGING

AVONBANK_A001 AKRONROAD_A001

Master Domain - LM_PACKAGING

Resource Domain - AVONBANK Resource Domain - AKRONROAD

AKRONROAD_C002

MISSISSAUG_B001

AKRONROAD_B001

AVONBANK_C002AVONBANK_C001

AVONBANK_B001

AKRONROAD_C001

Resource Domain - MISSISSAUG

MISSISSAUG_A001

In the Master/Resource Domain Model, we have a number of PDC’s and BDC’s located across the network. The diagram is an example of how the logical network should be configured. The M aster Domain PDC ({COMPANY}ACKAGING) replicates the WINS Information between all BDC’s on the domain. This means that the BDC’s are allowed to update the information concerning local network NetBIOS names, and the information is carried back to the PDC. The information is then PUSHED to PDC’s and BDC’s on Resource domains. Information concerning items would therefore be updated only on the Master Domains’ BDC’s - which, of course, are local. User workstations treat the local PDC of the Resource Domain as the Primary WINS Server - and the BDC of the resource domain OR the BDC of the Master Domain as the Secondary WINS Server. The diagram shows this with the dotted lines from the workstations directed towards the Secondary WINS Servers. The Grey Arrows represent a PUSH only, and the larger arrows represent a PUSH/PULL process.

12. Documentation of NT User Environment This part of the document deals with how NT should be configured on the Servers and in the Domains. This chapter explains how the domains should be set up and how the User ID’s should be administered. The {COMPANY} NT environment purely authenticates local login ID’s at present - and caters for specific applications such as Collabrashare etc. All other services are catered for by Novell. At present, Novell Netware servers cater for Applications, Data and Print Services. This may change in the future - but at present, we wish only to have NT to manage the users. This initial idea simplifies how the NT Server Domain should be configured.

12.1. The Domain Model In order to create a Windows NT networking environment it is important to understand and select the correct Windows NT Domain Model. A domain in a Windows NT environment is a logical collection of computers sharing a common user accounts database and security policy. A domain also provides logon validation to ensure that domain user accounts and security policies are enforced within the domain. Each domain has a unique name. Windows NT Workstation is designed to participate in either a workgroup or a domain. As part of a workgroup, Windows NT Workstation interacts within a common group of computers on a peer-to-peer level. In this environment, resources and user accounts are managed at each computer. A workgroup works well for small groups in which a small number of users needs access to resources on other computers. Both Windows NT Server and Windows NT Workstation are designed to participate in a domain. Like a workgroup, a domain is a logical grouping of computers and users. Unlike a workgroup, where each computer has its own user account database, a domain is managed by servers and has one user accounts database that is shared by all the servers. The Windows NT Server network operating system is designed to administer domain account privileges, security, and network resources centrally; for example, a large company may have 1,000 computers in a network. A group of users on this network needs exclusive rights to share files and applications. A Windows NT Server domain provides them with a secured environment in which they can share the files and applications, and log on from any Windows NT Workstation that is part of that domain.

12.1.1. Background The standard local area network operating system at {COMPANY} is currently Novell NetWare v3.1x. The standard workstation configuration is DOS and Microsoft Windows and this is used on both desktop and laptop machines. There is currently little Windows NT being used in the organisation. {COMPANY} have recently decided on a product to provide groupware/bulletin board functionality to their user base. {COMPANY} have chosen the client server version of this product, called Collabra Share, and it requires NT Server as the server platform. {COMPANY} are also looking to upgrade their current Microsoft Mail based messaging environment with Microsoft Exchange when it becomes available. This also requires Windows NT Server as the server platform.

12.1.2. Objectives The objective of this document is to provide {COMPANY} with a guide to the domain model best suited for their organisation. It is not meant to be an explanation of Windows NT or NT networking.

12.1.3. The windows NT domain model After a study considering the business, its structure, and how this maps to the design of a Windows NT domain model, it was decided that the Master Domain Model best fits the organisation and the future of its IT management.

12.1.4. The Master Domain model The master domain model is a two tier multi-domain configuration. It has a single master or accounts domain at the first level and multiple resource domains at the second level. This gives centralised administration of user account information with the ability to allow local administration of resources. All users logon to the master domain and are then allocated resources from their own resource domain. The diagram to the right is the Microsoft model to depict the master domain model. It shows the accounts represented on the master domain with the resources depicted in a set of resource domains. The arrows show the one-way trust relationship between the domains. All user and global group administration is performed on the Primary Domain Controller in the master domain. This means all users and groups for the whole organisation world-wide are created in, and administered from, a single domain. The resources used by the users are created and managed on the resource domains. Resources include things such as local groups, data shares, and printers. For the users to gain access to these resources on the resource domains a set of trust relationships must be set up. These relationships are one way and are set so that the resource domains all trust the master domain. The reasons behind choosing this domain model over a larger, single domain is due to the number of resources allowed in a single domain. By splitting the resources to a more localised “trusted” domain, the resource limit is not reached as quickly.

12.1.5. Trust Relationships Trust relationships allow users in one domain to access resources in another domain. Trust relationships add more dimensions to the domain model, and extend the domain model’s capability to be

Resource domain

Resource domain

Resource domain

Master domain

more powerful, yet require less administration. Trust relationships can only be established between NT Server domains. Trust relationships divide network objects into two categories : user accounts and resources. User accounts include users and user groups, while resources include objects such as file and print servers, workstations and data sets. Trusts allow users access to resources that exist in a foreign domain. By default, users in one domain do not have access to resources in another domain. When a user requires access to resources in a foreign domain, trust relationships can provide access to resources in that foreign domain. This enables access to the foreign domain without adding a duplicate user account in the foreign domain, even though the user does not exist in the same domain as the resource. Trust relationships simplify system administration. Under Netware 3.x, each server required separate user accounts, and users needed to log onto each server separately. Trust relationships in NT alleviate this problem so the user can have a single logon, and the administrator can manage one user instead of two. In many ways, a trust relationship can combine several domains into one managed unit. Once set up, up to 10,000 users can be managed through a single domain, which in turn can have access to several times as many resources.

12.1.6. Domain Rules In the following chapters that discuss trust relationships, the following rules must be applied to the basic design of resources, servers and domains : Each resource is physically connected to, and therefore can only exist in, a single server Each server can contain several resources Each domain contains one or more NT Servers Several domains can exist on the network

12.1.7. Trusting versus Trusted Domains A major distinction that one must be aware of is the difference between trusted and trusting domains. In a very basic domain structure similar to our Tiered model, the user domain is trusted and the resource domain is trusting. This simply means that the resource domain trusts the user domain and its ability to control access to the resource domain’s resources. Thus, the user domain is said to be trusted, and the resource domain is said to be trusting. The resource domain trusts that the user domain will control user permissions to its resources.

12.1.8. Setting up Trust Relationships Two steps are needed to create a trust relationship. First, one domain must permit a second domain to trust it. Then, the second domain can be configured to trust the first domain. Until the trust relationship has been established in the trusted domain, the administrator of one domain is not permitted to make changes to the other domain. Therefore, these two steps often need to be performed by separate administrators and must be accomplished in the proper sequence. To establish a trust relationship, follow the steps highlighted below. Installation


249. Create identical user names and password on both domains with domain administrative rights 250. Log into the Resource Domain 251. Make sure that the title bar shows User Manager in the Resource Domain. From the user

manager for domains, choose select domain from the User Menu. Select the Master Domain. The title bar should now show User Manager in the User Domain

252. From the Policy menu, choose Trust Relationship, then choose Add 253. Enter the password for the User Domain. The Resource Domain should now be listed under

Permitted to Trust This Domain. Close the Trust Relationship dialog box

254. From the User menu. choose Select Domain and type in the Resource Domains name. The title bar should now read User Manager in Resource Domain

255. From the Policy menu, choose Trust Relationship. Add the Master Domain name and use the same password that was used earlier

256. A dialog box should now appear notifying that the “Trust Relationship with the {MASTER} Domain successfully established”

Each domain has a PDC. The trusting PDC needs a secure channel to pass validation requests to the trusted PDC. This requires that certain accounts be set up ahead of time to be used to create and maintain the secure channel.

12.1.9. Establishing a route for passing validations The following procedure is used in a trusted domain relationship to establish the route for passing validations. Similar accounts and procedures are used in the trust relationship between a PDC and a BDC, and between a PDC and an NT Workstation in the domain. The trusted domain may be referred to as the Master Domain, and the trusting domain is referred to as the Resource Domain. The Master Domain will contain User Account information, which the Resource Domain trusts the Master Domain to validate user access to its resources. On each domain controller in the resource domain, the existence of the trust is represented by an LSA trusted domain object. It contains the name of the trusted domain and the domain security ID (SID). The LAS trusted domain object is replicated from the trusting domain PDC to each of the domain controllers in the Resource Domain.

12.1.10. {COMPANY} Resource Domains Resource domains should be set-up by business type or function rather than individual location and should be kept to a minimum where possible. As such the following list has been drawn up by {COMPANY} as a start point for defining domains. The business groups or “clusters” within {COMPANY} will each be a resource domain.

The above list has the sites where the Primary Domain Controllers should be implemented highlighted. These sites have been selected due to access to IS Staff or because the s ite implementation has occurred first Those with an * next to them have a recommendation to try and shorten the Post Office Name for NT Servers. It is recommended to keep the PO name to 9 characters so that the total Resource Names will be less than 14 Characters. It is also highly recommended not to use the underscore character (“_”) in any of the site names or resource domain names due to incompatibility with NetBIOS naming conventions.

Business Name or Cluster Site name

Headquarters AVONBANK BOULOGNE MISSISSAUG* NEUHAUSEN SALESEURO Tobacco BRISTOL HANSEDRUCK* BRABANT BAK ATLANTA LACHINE North American Flexibles AKRONROAD ARROWROAD BELLWOOD ARLINGTON SHELBYVIL North American Labels MONTREAL LEAMINGTON* VANCOUVER NEWHYDEPRK* BALTIMORE SPARKS North American Cartons LONDON RADISSON MARGO RICHMOND North American Plastics THERMAPLTE* RELIANCE WINNIPEG EU Food MIDSOMER SALTERBECK* YORKFLEX YORKPPRESS* SUPERIOR MORINUSINE* MORINSIEG TOURCOING SELEPRINT SENLIS STAR EU Pharma SINGEN PHARMAFLEX* CHARMETTS CERLIVE NEHER EU Cosmetic BOXALFR* BOXALNL* BOXALCH* EU Containers PICOPACFR PICOPACUK CANDC DECCON PICOPACNL EU Cartons ROTOPACK HAMMANS CORDES PAZO T HYNES {BRISTOL} EU Plastics FIBRENYLE PLASTICS THERMAPLAS* CELLOGLASS*

12.1.11. The {COMPANY} Resource Domain Map

The diagram above is a Logical representation of the domains in {COMPANY}. This logical representation takes into account the domain clusters - or Resource Domains, as well as the master domain in relation to the physical network. The Diagram to the right is the AVONBANK site and clearly shows the resource domain (HQ) and the devices that are contained within. It would be advantageous to create a network “map” of each site in a similar fashion - making sure that the sites update the map on a regular basis. At a glance, a user can see exactly how a device sits in a network.

AV

ON

BA

NK

BO

ULO

GN

EM

ISS

ISS

AU

GN

EUH

AUSE

NSA

LESE

UR

O

BRIST

OL

HANS

EDRU

CKBR

ABAN

TBA

K

ATLAN

TA

LACHINE

AKRONROAD

ARROWROAD

BELLWOOD

ARLINGTON

SHELBYVIL

MONTREAL

LEAMINGTONVANCOUVERNEWHYDEPRKBALTIMORE

SPARKS

LONDONRADISSONMARGO

RICHMONDTHER

MAPLTE

RE

LIAN

CE

WIN

NIP

EGM

IDS

OM

ER

SA

LTE

RB

EC

K

YO

RK

FLE

X

YO

RK

PP

RE

SS

SU

PE

RIO

R

MO

RIN

US

INE

MO

RIN

SIE

G

TOU

RC

OIN

G

SELE

PRIN

T

SENL

IS

STAR

SINGEN

PHAR

MAFLEX

CHARMETT

S

CERL

IVENE

HER

BOXALFR

BOXALNL

BOXALCH

PICOPACFRPICOPACUK

CANDC

DECCON

PICOPACNL

ROTOPACK

HAMMANS

CORDESPAZOTHYNESBRISTOL

FIB

RE

NY

LE

PLA

STIC

S

THER

MAPLAS

CELLO

GLASS

FrameRelay

Other Network Services SiteAVONBANK

Resource DomainHQ

Master DomainLM_PACKAGING

Gateways Frame RelayNetwork

CISCO ROUTER137.62.150.126

LMPACKAGING137.62.150.11

AVONBANK-A001137.62.150.12

AVONBANK-A002194.201.29.49

AVONBANK-A003137.62.150.31

AVONBANK-S001137.62.150.20

AVONBANK-B001

AVONBANK-W001

AVONBANK-W002

AVONBANK-W003

AVONBANK-W004

AVONBANK-W005

AVONBANK-W006

ISLASER

QMSQUEUE

AVONBANK_01

AVONBANK_03

AVONBANK_04

LMG_UK_AB_PROD_1

NETWAREWORKSTATIONS

Internet

12.1.12. Primary and Backup Domain Controllers A Windows NT domain requires a Primary Domain Controller (PDC). The PDC keeps a master copy of the security accounts database (SAM) and sends copies of this information to all the Backup Domain Controllers (BDCs) in the domain. This functionality allows both the Primary Domain Controller and the BDCs in the domain to validate user logons. This is a security model that can be used in LAN or WAN environments to provide user level security. The PDC for the master domain at {COMPANY} will be sited at Avonbank in Bristol. This means that every user/group account and its associated security information will be stored in a master database on a server at this site. This presents a number of obvious questions about access to this database from all the other sites in the group world -wide. To allow users to logon to a local domain controller a BDC of the master domain will be installed in every location. Should the WAN connection from any site go down all existing users at the site will still be able to logon to the domain and access their resources. Each resource domain will also require a PDC and a number of BDCs. {COMPANY} will probably require a resource domain BDC on each site. If this server is configured correctly it can function as a server for other applications such as Collabra share or Exchange. With a master domain user population of up to about 5,000 users the PDC and BDCs should be a minimum specification of Intel 486/66 with 32Mb of memory and 300Mb hard disk. The PDC for each resource domain should also be of similar specification. The BDCs for each resource domain will have to be designed for each individual site as these servers may also serve other applications and/or data.

12.1.13. Domain Network Traffic Implementing a master domain model with multiple resource domains spanning multiple locations requires consideration to be given to domain, server and workstation communications. The following Windows NT features may cause significant traffic between domain servers on different sites. These can all be optimised within the NT Registry and this should be done for each specific site and domain server.

12.1.14. Domain Browsing The Windows NT Domain master Browser (always the PDC in a domain) exchanges computer browse lists with the master Browsers which are usually the backup domain controllers. The Computer Browser Service builds a list of the domains and servers that are available on the network.

12.1.15. WINS Replication WINS (Windows Internet Naming Service) is used to provide resolution between Computer/NetBIOS names and TCP/IP addresses. The use of WINS will be required as {COMPANY} dictate the use of TCP/IP on the client as the transport protocol rather than NetBEUI or IPX/SPX.

12.1.16. Directory replication NT provides a directory replication service to allow logon scripts to be replicated to BDCs.

12.1.17. User accounts database (SAM) replication As discussed in 2.3 the PDC holds the master copy of the SAM database. Each BDC has a replicated copy of this database with additions and amendments being sent from the PDC to the BDCs.

12.1.18. Naming conventions The following components need to be considered for the naming conventions: Domain Names Server Names Workstation Names Resource Names (data and peripheral) Global Groups Local Groups

12.1.19. Domain Name The domain name has a limit of 15 characters and should in the case of {COMPANY} represent the business cluster names as listed in section 2.2. For example, North American Flexibles might be represented by US-Flexibles. The domain name for the Master Domain is LM_PACKAGING.

12.1.20. Server Name The server name is also limited to 15 characters. This should comprise information about its location, type and a number. :- 1. The first set of ten characters should represent the site name and will be the MS Mail Post

Office name already allocated to the site. 2. A hyphen “ -”. NOT an underscore “_” since these are not transferable between TCP/IP. 3. A single letter will then describe the server type 4. A three digit number will then follow. For example : BOULOGNE-A001 This code represents a server at Boulogne. The A shows that is a BDC of the

master domain. MIDSOMER-B001 This code also represents a server at Midsomer Norton and the B shows that

it is a PDC of the resource domain. STAR-C001 This code also represents a server at Star and the C shows that it is a BDC of

the resource domain. MORINUSINE-S001 Finally the S shows that this is an application server at Morin Factory. On smaller sites the server type S will probably not appear as the resource BDC will probably provide application and data resources. As the machine type is depicted using the alphabet {COMPANY} can define up to 25 (see Workstation name) different server types. It is recommended that the machine types be selected for the type of service that the server will be required to operate under : Master Domain PDC - High Specification Machine Master Domain BDC - Low Specification Machine Resource Domain PDC - Medium Specification Machine Resource Domain BDC - Low Specification Machine Application Server - High Specification Machine

This example only takes into account NT Services. If applications such as Collabrashare or SQL needs to be run, for example, on a Resource Domain BDC - then it is imperative that the machine be investigated for a higher specification. A High Specification Machine could be a Compaq Proliant with a fast Pentium Processor, a Backup Device, Contingent Drives and a fast network card. A Medium Specification Machine could be a Compaq Prosignia with a fast Pentium Processor, a backup device and a fast network card. A Low Specification Machine would normally be a machine similar to a top-end workstation.

If data is to be stored on any machine, then Drive Contingency should be taken into account (See NT Server Section)

12.1.21. Workstation Name The workstation name also has a limitation of 15 characters. The same convention as the servers and use the letter W to define workstation. This would mean workstations at Avonbank to be named : AVONBANK-W001 This allows for each site to have 999 workstations. If this maximum where ever reached the final three digit component of the convention could be modified to start A01, A02 etc. Alternatively, the final three characters could be used for a location based indicator on larger sites.

12.1.22. Resource Name The name for data resources is limited to 12 characters. These need to be discussed on an individual basis although there may be some future benefit if resource names are identical (where possible) throughout all the domains.

12.1.23. Local Group Local Groups can include user and global group accounts from any trusted domain and are used to manage resource access. They should therefore be made up of the site code followed by the resource name. Local Groups have a limitation of 20 characters. An example of a local group would be MISSISAUG-MAILDATA.

12.1.24. Global Groups Global Groups can only contain user accounts from the local account database and are therefore all created in the master domain. Global Groups also have a limitation of 20 characters. The naming convention for the global groups requires further discussion.

12.1.25. Network administration The master domain model discussed in this document allows central administration of all account information. As an addition to this an NT Workstation can logon to any domain and access domain servers from anywhere on the inter-network as long as RPC is supported. In the event the WAN connection to a site goes down the domain model discussed in this document allows users to carry regardless. This is achieved by placing a BDC from the master domain on every site which allows local user authentication. If the WAN connection stays down for any length of time the administrator may require access to the site. To enable this, it is proposed that the Remote Access Service (RAS) be run at every site. This enables a RAS client to login to a domain from a remote machine. RAS supports asynchronous and ISDN communications.

12.1.26. Summary In summary this chapter provides {COMPANY} with information regarding the Microsoft Windows NT Domain model that should be implemented to support the growing number of NT applications. The model is a master domain model and has been designed to allow the installation of Collabra Share. It also takes into consideration the future rollout of Microsoft Exchange and the possibility of a migration from NetWare to Windows NT Server and the primary network operating system. Based on Business Clusters, certain sites register their Network Devices into a “Resource Domain”. Users always log onto the Master Domain and as such the user ID’s are always configured and maintained centrally for security.

12.2. Overview of User and Group Accounts A user account defines a user to Windows NT. This includes the name and password required for the user to log on, the groups in which the user account has membership, and any user rights for using the assigned computer. When a user logs onto a workstation and attempts to perform a particular action on that computer, Windows NT checks information in the user's account to determine whether the user is authorised to perform that action.

12.2.1. Multiple User Accounts for Security An individual may have more than one account, each account providing and allowing different capabilities within the Windows NT Workstation security system. For example, an administrator can have both an administrative account that provides the access rights necessary to manage the system, and a user account for routine use.

12.2.2. Creating User Accounts Additional user accounts can be added to allow other users to log on locally or access local resources from over the network. This is done either by creating new user accounts, or by making copies of existing user accounts. Creating user accounts involves adding user information, adding the user to groups, and establishing the user environment profile. Before creating new user accounts, it is a good idea to establish a standard naming convention. A standard naming convention speeds up the lookup process in User Manager when maintaining and troubleshooting the sys tem, or if duplicate names occur.

12.2.3. Copying User Accounts When creating multiple user accounts with similar account properties, it is recommended that a template be created for each type of user. For example, create a template with all the appropriate options and group memberships established for users in the accounting department. Then, when an account is needed for a new user in the accounting department, you can simply copy the template.

12.2.4. New User Items Copied User accounts can be copied, but not all of the items in the User Properties dialog box are copied to the new user account. The items copied directly from an existing user account to a new user account are as follows: The description. Group account memberships. Profile settings, such as home directory. "User cannot change password" is copied from source account. "Password never expires" is copied from source account.

12.2.5. New User Items Settings after Copying After copying an existing user account to create a new user, the following items are cleared: The Username and Full Name "User must change password at next logon" "Account disabled" Any rights and permissions that have been granted to a user account are not copied. The only way that user rights are copied, is if the user rights have been assigned to a group, since group memberships are copied.

12.2.6. Renaming User Accounts It is possible to rename any user account, including the default accounts. When a user account is renamed, it retains all of its other properties. The only thing that changes is the account name.

12.2.7. Deleting and Disabling User Accounts Although you can delete user accounts at any time, it is recommended that you do so only if a user will never again need to log on or access that Windows NT Workstation. Deleting user accounts also removes security identifiers. Security identifiers (SIDs) are unique numbers that identify users who are logged on to the Windows NT security system. A security ID can identify an individual user or a group of users.

12.2.8. Deleting User Accounts If a user account is deleted and a new account is created with the same name, it will have a different SID, and as such will be unable to access anything the previous account was able to access without reassigning the appropriate permissions and privileges. The new account must have the appropriate access permissions, user rights, and group memberships established for it to behave in the same way as the deleted account.

12.2.9. Setting the User Environment Profile The user environment profile provides a location for storage of personal files and provides consistent network resources every time a user logs on. This provides a user with their own unique environment on desktops shared by multiple users. The User Environment Profile dialog box allows you to configure the user's logon script name and location of the user's home directory.

12.2.10. Logon Script Name When a user logs on to Windows NT, the user's profile can be configured so that a logon script runs automatically to configure the working environment for the user. A logon script is normally a batch file (.BAT or .CMD extension) that issues MS-DOS or OS/2® operating system commands, or calls executable files, though an executable file can also be used for the logon script. When using executable files, remember to use the correct version of the executable if the user may be logging on at computers with different CPU types (e.g., x86, MIPS, Alpha). The %PROCESSOR% environment variable can be used to select the right executable in a logon script. Other environment variables that can be used in logon scripts include %HOMEDRIVE%, %HOMEPATH%, %HOMESHARE%, %OS%, %USERDOMAIN%, and %USERNAME%.

12.2.11. Home Directory A home directory provides the user with a consistent location to store all personal program and data files. In g eneral, administrators should configure home directories so they are not accessible to anyone but the individual user. It is possible to determine where Home directories are stored - and are usually held on a File Server. A home directory is used as the default directory when the command prompt is started. In addition, the home directory is also the default directory for saving a file in applications that do not supply a default working directory.

12.2.12. Assigning Group Membership A group is defined as an account containing other accounts (members). Groups are basically "aliases" for a set of users, and can be assigned permissions and user rights just like a user account. As a result, the permissions and rights granted to the group are applied to its members automatically. This makes groups a convenient way to grant common capabilities to a collection of user accounts.

The limit to the number of groups to which a user can be a member is 1,000.

12.2.13. Group Accounts A group is an account that contains user accounts. The accounts contained within a group are members of that group. Groups are used to give users permissions to perform system tasks, such as backing up and restoring files or changing the system time, and to grant access to resources, such as files, directories, and printers. Group accounts are useful because they simplify administration by organising user accounts into a single administrative unit. Group accounts provide a convenient method of controlling access for several users who will be using Windows NT to perform similar tasks. By placing multiple users in a group, you can assign the same abilities and/or restrictions to all of the users at the same time by assigning the rights and/or permissions to the group. Without groups, user rights and access permissions would have to be assigned to the individual users accounts. User accounts can still be modified individually, even if they are members of one or more groups. Windows NT Workstation allows the creation of local groups. Windows NT Sever allows the creation of both local and global groups.

12.2.13.1. Local Groups This type of group can include any user accounts created in the local accounts database. Additionally, if the Windows NT Workstation has joined a Windows NT Server domain, a local group can also contain any global accounts from the Windows NT Server domain. Local groups created on a Windows NT Workstation are only available on that workstation. They cannot be accessed on other Windows NT-based computers. It is not advisable to maintain local groups, and instead, it is recommended for any user ID’s to be part of a Global Group.

12.2.13.2. Global Groups Global groups contain accounts outside of the local computer. They are assigned user rights and permissions to resources on the local computer where the global group resides, or from any Windows NT Workstation that has joined the domain. Global groups provide a way to create groups of users from the domain. If your Windows NT Workstation is a member of a domain, then it is possible to grant permissions to any global groups that have been created in the domain.

12.2.13.3. Default Group Accounts There are several default group accounts built into the Windows NT Workstation operating system. The built-in groups are Guests, Users, Power Users, Administrators, Replicator, and Backup Operators. By default, all user accounts created on a Windows NT Workstation are made members of a group called Users. There is also a special group account named "Everyone" The Everyone group includes every user account created on the local computer and as such, does not appear in the listing of group accounts and does not permit the adding of users. It can be used to assign user rights and access permissions to resources, and would permit every user (including Guest) the privileges assigned to the Everyone group.

12.2.13.3.1. Guests

The Guest group offers limited access to resources on the system. The Guest user account is automatically added as a member of the Guests group account.

Since anyone on a network can connect to a computer's shared resources through the Guests group, permissions must be assigned on shared resources to control how users can access those resources. To grant a specific user the same access to the computer as someone who logs on as a Guest, add that user account to the Guests group .

12.2.13.3.2. Users

The Users group account provides the user with the necessary rights to operate the computer as an end user, such as running applications and managing files. By default, every user account created is added to the Users group.

12.2.13.3.3. Power Users

The Power Users group account gives members the ability to perform certain system administrative functions, without giving the user complete control over the computer.

12.2.13.3.4. Administrators

A user logged on as a member of the Administrators group account has complete control over the entire Windows NT computer.

12.2.13.3.5. Replicator

This group account is used when configuring the directory Replicator service. The directory Replicator service is used to automatically copy files, such as user logon scripts, between Windows NT-based computers.

12.2.13.3.6. Backup Operators

The Backup Operators group account allows the user to backup and restore files on the computer. Any user can backup and restore files for which they have the appropriate file and directory permissions without being a member of the Backup Operators group. The Backup Operators group overrides any permissions on files and directories that would normally prohibit a user from accessing those files, and allows users who are members of the group to backup any and all files on a drive, regardless of the file and directory permissions. Permissions to all files are only granted while the user is using Windows NT Backup to backup or restore files and directories.

12.2.13.4. Deleting Local Groups Account Deleting a local group account removes only that local group. It does not delete any user accounts that were members of the deleted local group account. Groups that have been created with User Manager can be deleted, while the built -in groups provided with Windows NT Workstation, such as Administrators and Guests, cannot be deleted.

12.3. Managing Security Policies Security policies provide an administrator an additional level of computer and network control. However, an administrator needs to carefully consider what security policies need to be configured in an environment, and realise what affect the configured policy will have on the security of the local computer. Windows NT provides the following security policies: Account Controls the way passwords are assigned and maintained by users. It also controls

the account lockout feature of Windows NT. User Rights Controls the explicit rights that can be assigned to the group and user accounts of the

workstation. Audit Controls the types of events that will be recorded in the audit logs.

12.3.1. The Account Policy The Account Policy sets the minimum and maximum ages, minimum length, and uniqueness of passwords, and configures the account lockout feature. Changes to this policy affect each user at the next logon. The Account Policy is accessed from the Policies menu of User Manager.

12.3.2. The User Rights Policy The User Rights Policy manages the rights granted to group and user accounts. User Rights authorise a user to perform certain actions on the computer. User Rights apply to the computer as a whole and are different from permissions, which apply to specific resources, such as files and printers. In general, you will not need to change the User Rights policy for the default groups, because the User Rights of these groups should support the needs of typical users within each group. There are two levels of User Rights that can be assigned: User Rights and Advanced User Rights. The most commonly modified rights are User Rights.

12.4. User Levels There are several user levels based on the applications that the user runs, the type of access the user has in the Network Environment and the type of hardware that the user owns. These are as follows : User Level 1 Desktop Workstation users who may have to roam. Ve ry restricted access to

NT Services and workstation settings. Shared User Profile. User Level 2 Portable Workstation users who often roam. No access restrictions to

workstation settings - their profile is located locally User Level 3 Standalone Workstation User - no access to Network and not allowed to

roam. Access to change workstation settings - profile is located locally User Level 4 Desktop Workstation user who may roam and may change workstation

settings. Usually management level who wishes to have their own User Profile. Restricted number of this user level depending on the traffic produced on the network

User Level 5 Desktop Workstation Administrator Access - No access to any NT Services

or Workstation Settings - shares user profile with User Level 1 - single user ID

User Level 6 Computer Account Administrator - Installation user used only for

Installation of Workstations in Domain. User always roams and has access to workstation settings and user profile. Profile is stored on the Domain

User Level 7 Domain Administrator The reasons for having a strict limit on the number of user levels means that we can a limit the number of types of users on the domain - therefore making administration easier Administration of a group of users means that the users are standardised across the network

as much as possible. b reduce the amount of traffic on the domain by users moving between workstations and having

to download individual profiles. This is done by making user groups that use a common user profile

With every user on the domain having access to their own profiles, the network would have to

update servers across the WAN with the users profile each time they moved. The average users profile is approximately 200k - this means that across a 64k link, the user could take 30 seconds to log in each time they move to a new domain. Of course, as soon as they update their profile as well, in can take just as long to send an image back to the server.

By having a single profile and login script for a group of users that is never changed by the

users themselves, and by replicating the profile and script between the servers on the WAN whenever they are changed means that traffic is kept to a barest minimum - however, the trade-off is the fact that the users cannot update their own profiles.

c administer user groups efficiently As already discussed, whole groups of users can have installations installed or removed

simply by changing the common user profile and login script. Users can still be “personalised”

by having a private directory area for their own, personal use - but everyone will have a standard directory mapping structure and every user ID will be the same

d Stops confusion over users roaming the network By having this standard mapping structure - we no longer have the problem of users becoming

confused whenever they move to a different machine because that machine maps different drive letters to different areas. Drive mappings are standardised - so applications and data are always located where the user expects them to be.

e. What can be restricted, and who is restricted ? There are 2 types of profiles - local and server-based. Local profiles are stored and updated locally at the workstation. Server-based profiles follow users wherever they log on. The server-based profiles can be mandatory (i.e. not changeable by the user), or the administrator can enable the user to update the desktop at will. A Mandatory profile means that during the session, the user can change their settings (colours, backgrounds etc. etc.) yet, when they quit the session - all of the changes will revert back to their previous settings. The following is a table of what can be restricted and how :

Option How to Change Option Change Colours permanently By Using a Mandatory Profile, Users cannot do this Change Backdrops permanently By Using a Mandatory Profile, Users cannot do this Change Icon Properties in Program Manager By Using a Mandatory Profile, Users cannot do this Move Icons in Program Manager Prevent the user from doing this by using UPEDIT.EXE to

edit profile Create Program Groups in Program Manager Prevent the user from doing this by using UPEDIT.EXE to

edit profile Prevent File Run in Program Manager Prevent the user from doing this by using UPEDIT.EXE to

edit profile Disable Save Settings in Program Manager Prevent the user from doing this by using UPEDIT.EXE to

edit profile Prevent user from changing Printer Settings Prevent the user from doing this by using UPEDIT.EXE to

edit profile Can see Main Program Manager Group Deleting the object from profile prevents the user from

accessing this option Can run File Manager Deleting the object from profile prevents the user from

accessing this option Can Permanently Connect Network Drives By Using a Mandatory Profile, Users cannot do this

permanently Can see Programs in File Manager By changing the File View settings in Filemanager and

making this part of the Mandatory Profile - this restricts access to certain file types

Can see Administrative Tools in Program Manager

Deleting the object from profile prevents the user from accessing this option

Can change User Settings By using a Personal Profile, access is given to the user to change their environment settings

Can share Workstation Devices peer-to-peer UPEDIT can prevent users from sharing their own devices Prevent the user from changing the user password

User Manager has an option to prevent users changing their own passwords

Prevent Standard Windows Applications from being run

Using a mandatory profile and deleting certain program groups and items prevents access to certain Windows Apps, although those apps may be present locally

Users can still operate certain things when they have access to File Manager, such as connecting network drives (temporarily whilst in the session).

e. Matching the User Levels to the restrictions The user levels that have been proposed have certain access rights and can and cannot change certain parts of their environment. The table below matches the proposed user levels to the previous list of restrictions.

Option User Level 1 2 3 4 5 6 7

Can change Colours permanently ? ? ? ? ? Can change Backdrops permanently ? ? ? ? ? Can change Icon Properties in Program Manager ? ? ? Can move Icons in Program Manager ? ? ? Can create Program Groups in Program Manager ? ? ? ? Can see “File Run” in Program Manager ? ? ? ? Can see “Save Settings” in Program Manager ? ? ? ? Can change Printer Settings & connect printers ? ? ? ? Can see Main Progra m Manager Group ? ? ? ? ? ? ? Can run File Manager ? ? ? ? ? ? ? Can Permanently Connect Network Drives ? ? ? ? Can see Programs in File Manager ? ? ? ? Can see Administrative Tools in Program Manager ? ? Can change User Settings ? Can share Workstation Devices peer-to-peer ? ? Can change the password ? ? ? ? ? ? Can run Standard Windows Applications ? ? ? ? ? ? ? Can create users in Domain ? ? Can create Computer Accounts in Resource Domain ? ? Can create Resources in Master Domain ? ? Can change own profiles ? ? ? Can change other profiles ? Can Install Software for User Profiles ? ? Can Run Standard OFFICE Applications ? ? ? ? ? ? ? Can Roam ? ? ? ? ? Can change Workstation Network Settings ? ? ? Can change Server Settings ?

12.5. User Profile Configuration NT Users should be able to roam the domain, logging into any terminal that is connected to that domain. Since {COMPANY} are running two environments within the WAN - i.e. Netware and NT, then this environment can propose some advantages over a single NOS environment. The standard user accounts have no problem with replication between domain controllers. This allows anyone to log in from any workstation and using the local Domain Controller to authenticate login. The problems start to occur when a user tries one of the following : 1. Running a Server Based Application 2. Printing 3. Saving Data Since there are no current standards to the way that the current network maps drives - this can produce more inherent problems. Although the User Account may be configured to run a certain application - and changes to the user account is carried across between the machines - then we should have no problems with the way that an application requires initiation settings. The proposal is as follows :

In the above diagram, if a local user to NT_SERVER01 logs in to NT_WORKSTATION01, his local account is retrieved and authenticated from NT_SERVER01. The applications are stored on NW_SERVER01 and his NT Workstation configuration automatically connects the paths to the Netware Server. When the user then roams and logs in to NT_WORKSTATION02, the user account will still be available to him from NT_SERVER01 but is retrieved and authenticated from NT_SERVER02. The workstation will now automatically connect him to the local Netware Server - NW_SERVER02 and will map the application path to this server. Providing that the drive mappings are identical between NT_WORKSTATION01 and NT_WORKSTATION02 (and of course, the application directory structure and versions on NW_SERVER01 and NW_SERVER02 are identical), then the user will be able to run their application from that local host ! Since all configuration files are held within the user account registry, this allows the user to customise their own application and carry that between workstations. The problem comes with how the workstation attaches to the local application server. At present, if you log in to an NT Workstation which has local attachments to the NW Server, it will attempt to log in as

NW_SERVER01

NT_SERVER01

NT_WORKSTATION01 NW_SERVER02

NT_SERVER02

NT_WORKSTATION02

WAN Link

DOMAIN_01

the NT User name. This is not a good idea, since it would mean that every Novell Server should have an entry for every NT User - taking up space in the Nware Bindery and impacting performance. Instead, it is recommended that the user logs in as a “GUEST” or as an “Apps” account to the application servers as standard. This account would have access to certain applications, such as MS Office, FDC etc. It is recommended to have set up a user account on the application server as APPS with the password of APPSUSER - this will be a read only account that gives read-only access only to certain directories. It is also suggested that the connectivity of the drives should be done in a Windows NT LOGIN SCRIPT. Drive mappings are not currently standardised - which makes it difficult to administrate. The closest to “standard” is a primary user-logon, which has the following mappings : F: \\{Netware Application Server}\SYS:\ I: \\{Netware Application Server}\DATABASES:\ J: \\{Netware Data Server}\DOCUMENTS:STDLET \GENERAL\ M: \\{Netware Data Server}\HOME:{USER ID}\ O: \\{Netware Application Server}\DATA:APPS\ P: \\{Netware Data Server}\DOCUMENTS:LETTERS\{USER ID Initials}\ X: \\{Netware Application Server}\SYS:PUBLIC\ Y: \\{Netware Application Server}\DATA:SOFTWARE\ Z: \\{Netware Application Server}\SYS:\ A recommendation to standardise on the above format would be similar to the following : F: - maps to a local netware logon drive I: - Maps to the Production Databases Drive J: - Maps to the Data Directory for Documents M: - Maps to Users Home Directory O: - Maps to Application Directory P: - Maps to Data Directory for Letters X: - SYS:PUBLIC Y - Application Software Z: - SYS: (same as F:) Since we have decided to allow users to “Roam” then their workstations and user ID’s need to be able to explain which mappings to map locally, and which mappings to map to remote servers. The following gives an explanation to this : F: - Local, Workstation knows where to map drive I: - Local, Workstation knows where to map drive J: - Remote, User ID knows where to map drive M: - Remote, User ID knows where to map drive O: - Local, Workstation knows where to map drive P: - Remote, User ID knows where to map drive X: - Local, Workstation knows where to map drive Y: - Local, Workstation knows where to map drive Z: - Local, Workstation knows where to map drive As can be seen, the Login Script will only permanently map 4 drives, whereas the workstation environment will map the rest of the drives.

To make sure that the login -script understands which drives that the workstation should log into, then an environment variable should be included on the workstation. As an example - a variable called NETWORK could be set up. This would contain the LOCAL Netware Fileserver name. As an example - a users login script to attach to the network would look similar to the following : In a local environment - the NETWORK Variable would be set to the {Netware Application Server}. This Environment Variable is set in C:\AUTOEXEC.BAT. The Netware Data Server will be hard-coded into the login-script for the user ID. We want to log into this network server as the standard username without the need to enter a password : @ECHO OFF CLS ECHO ** Welcome to the LM_PACKAGING NT Domain ** NET USE F: \\%network%\SYS appsuser /user:apps NET USE I: \\%network%\DATABASES appsuser /user:apps NET USE O: \\%network%\DATA \APPS appsuser /user:apps NET USE X: \\%network%\SYS\PUBLIC appsuser /user:apps NET USE Y: \\%network%\DATA \SOFTWARE appsuser /user:apps NET USE Z: \\%network%\SYS\PUBLIC appsuser /user:apps NET USE P: \\{Netware Data Server}\DOCUMENTS\LETTERS NET USE J: \\{Netware Data Server}\DOCUMENTS\STDLET\GENERAL NET TIME /DOMAIN:LM_PACKAGING /SET /Y NET USE M: \\AVONBANK_01\HOME\TESTING The final drive connected - drive M is connected to the Users Home Directory Drive using the Users Home Directory Variable which is located in the Domain User Manager. As can be seen, {Netware Application Server} will be connected using a User ID that is generic, and does not ask for a password. In effect, user APPS would be a “guest” user with no Write access to any area on %network%. Other netware servers and drive letters are connected using the user ID’s Login Script. It is also recommended to utilise the same method for NT servers as well. This means that even if the user roams, they will always log into the local Applications Fileserver (hopefully a direct copy of all other Applications Fileservers) - and always log into their own Data Directory.

12.6. Login Scripts & Configuration In the proposed Network Environment, Login Scripts are extremely important. However, the way we have configured the login scripts, we have standardised the netwo rk drive mappings and therefore cut down on the number of login scripts needed. At present, each user ID set up on a Netware File Server has their own Login Script, and, together with the System Login Script, they map drives differently between the users. The way that the new NT Login Scripts work means that a single script can be used for large groups of users. This also means that if a new application requires a certain drive mapped or a new server becomes available for certain departments, it is easier for the login script to be adapted for the new requirements. However, since we require that the users be able to roam across the WAN, then the local BDC’s that authenticate user logins need to be configured so that they copy the login scripts from a central resource. It is proposed that the login scripts are centrally controlled in the PDC’s Export\scripts directory. The Replicator Service should then copy any files that have changed between the BDC’s Import \scripts directories. This directory should then be configured as the Login Script Directory. Replication is easy to set up. The PDC is the only Server that Exports Scripts, and will export scripts to any BDC in its list. The list of servers on the PDC must be updated, otherwise users may be able to login to servers without the login script running. An installation procedure has been set up to make sure that a BDC is configured correctly so that is replicates this data. Installation


257. Log onto the Domain as a Domain Administrator - preferably on the BDC that you wish to set up for Directory Replication

258. Make sure that the C:\WINNT35\SYSTEM32\REPL\EXPORT\SCRIPTS directory and the C:\WINNT35\SYSTEM32\REPL\IMPORT\SCRIPTS directory exists on the server - use filemanager or a Command Prompt to verify this

259. Make sure that the Server has an entry in the WINS Database and is correctly configured in the WINS Manager located on the PDC - if not, the NetBIOS resolution will not correctly work, and the replication service may fail

260. Make sure that the Domain is configured so that the User Manager correctly identifies the Replication User user ID

261. Start up Server Manager - highlight the server that you are on currently - if the server does not appear, then the domain has not been synchronised and the System Administrator needs to be informed

262. Click on “COMPUTER” “SERVICES” to bring up the services box for the Server 263. Highlight “Directory Replicator” service. This service should be “STOPped” if it is currently

“STARTed”. 264. Click on “START -UP....” button 265. “Start-up Type” should be set to “Automatic” 266. “Login as User” should be set to the Replication User. Make sure that the correct password

for this user ID is entered - this can be obtained from the System Administrator 267. Click on OK 268. Click on “START” to start the service. If the service does not start, please contact the

System Administrator 269. Click on “CLOSE” to close the services dialog box 270. From the Server Manager - highlight the PDC ({COMPANY} ACKAGING) and click on

“COMPUTER” “PROPERTIES” 271. Click on the “Replication” button 272. Under the “Export Directories” column, click on “Add” 273. Locate the BDC you wish to replicate to, and double click on it 274. Click on “OK” to close the “Directory Replication on {PDC}” dialog box 275. Click on “OK” to return to the Server Manager 276. Highlight the BDC Server that you are configuring, and click on “COMPUTER”

“PROPERTIES” 277. Click on the “Replication” button 278. Under the Import column, make sure that the Import Directories is highlighted, and that the

path is set to C:\WINNT35\SYSTEM32\REPL\IMPORT 279. Make sure that the From List shows the PDC - if not, add it from the “ADD” Button 280. Make sure that the Logon Script Path is set to

C:\WINNT35\SYSTEM32\REPL\IMPORT\scripts 281. Click on “OK” “OK” - exit the Server Manager 282. The Directory Replication Service should now be working. Check the

C:\WINNT35\SYSTEM32\REPL\IMPORT\Scripts directory to confirm that the files are being updated. On a slow link, this might take some time. Once the files have been updated, they will be used by any User Profiles that expect them there

12.7. Network Printing with NT

12.7.1. Overview of Printing with NT

12.7.1.1. Windows NT Printing Terminology Windows NT uses its own printing terminology to describe the printing process.

12.7.1.2. Printing Device versus Printer Under Microsoft Windows NT, a printing device refers to the actual hardware device that produces printed output. A printer refers to the software interface between the application and printing device. Each printer appears as a separate window that is managed using the Windows NT Print Manager application. Multiple printers can be routed to one printing device. For example, if you have a printing device capable of using both PostScript® and HP PCL modes, you might want to use Print Manager to create a printer for each mode. Each printer would use a different printer driver. Printers can be assigned priorities, or be configured to print during certain hours. For example, longer or lower priority jobs could be sent to a printer that prints only at night.

12.7.1.3. Printer Versus Print Queue In Windows NT, print jobs are sent to a printer, where they are then spooled before being sent to the printing device. In many network environments, the term print queue is used instead of printer. For example: Windows NT users submit print jobs to a printer, but OS/2 and NetWare users submit print jobs to a print queue.

12.7.1.4. Physical Versus Logical Printer Port A physical port is a hardware connection, such as LPT1: or COM2:, between the local computer and a printing device. A logical port is a network connection to a remote print server or printing device, referred to as \\server\printer. Windows NT allows you to create a printer to use a logical or a physical port as the print destination.

12.7.1.5. Local and Remote Printers and Printing Devices Local printing devices are attached directly to a Windows NT Workstation or Windows NT Server computer. Remote printing devices are accessed across the network. Network-interface printing devices are printing devices with built -in network cards, and are connected directly to the network.

12.7.1.6. Printer Pools In a printer pool, multiple printing devices are associated with a single printer. The devices within a printer pool must be identical or must all emulate the same type of printing device. In other words, they must all be able to use the same printer driver. Windows NT imposes no limits on the number of printing devices in a printer pool. Printer pools enable administrators to add printing devices without modifying user environments. Since printer pools are created by adding new devices to existing printers, user configurations will not need to be changed.

12.7.1.7. Using Print Manager Print Manager is the Windows NT administrative tool that allows administrators to perform all network printer administration tasks including creating, securing, connecting to, and configuring printers. Print Manager also allows users to interact with local and remote printers. Print Manager is used to: Create printers (install printer drivers). Control printer characteristics, such as fonts and paper size. Set permissions for printer access. Set up auditing of printer use. Administer printers from a remote location. Redirect printer output. Connect to remote printers. Check local and remote printer status. Print Manager can be started from the Print Manager icon in the Main group or from the Control Panel Printers icon.

12.7.1.8. Creating a Printer The Create Printer dialog box is used to install and configure printer drivers on Windows NT-based computers. This works for either a local printing device (a printing device that is physically attached to the computer) or a network printer. If the print server is Windows NT based, then it may be easier to use the Connect to Printer command to avoid installing a local print driver.

12.7.1.9. Connecting to a Printer The second way to access a printer is to connect to a printer. To connect to a shared network printer on another Windows NT-based computer, use the Connect to Printer command. If you are printing to a printer on a Windows NT print server, the client computer does not need to have the appropriate printer driver installed locally. Instead, the printer driver is copied across the network from the print server to the client computer. This allows the application that is printing to query the printer driver for the current printer settings, such as font information. This provides two main benefits: The administrator only needs to update the driver on the print server. Clients automatically get

the new driver when they connect to the printer. The client computer does not need to have the appropriate driver installed in order to use the

printing device. This can be very useful with portable computers, or computers that may use several different printing devices.

The Connect to Printer command is not intended for use in connecting to a shared printer on a Windows for Workgroups-based computer or other network printer server. If the command is used for that purpose, a message will appear informing the user that the computer being connected to does not have a printer driver and then give you the opportunity to create a printer.

12.7.1.10. Administering Remote Printers Print Manager allows you to administer network print servers remotely. You can change the properties of existing printers, as well as install new printers or remove printers. To administer printers you must have Administrator or Full Control permission on the printer at the print server.

12.7.1.11. Implementing Printer Pools A printer pool is a grouping of multiple printing devices connected to a single printer. A printer pool allows users to print to a single printer and let the print spooler determine which printing device is available. When a printer is created, you should select the port in the Print To list that has the most efficient printing device attached to it. This will be the first printing device considered by the spooler. To add more printing devices to the pool, choose the Details button in the Create Printer dialog box and select the additional ports you want. The selected ports can be of a mixed variety, such as serial, parallel, and so on. Routing is based on the order in which the ports are chosen, so add the fastest ports first. All printing devices in a printer pool must be able to use the same printer driver. This list box can also be used to remove a persistent network connection to a print server. All printing devices in the printer pool share the same printer name and act as a single device. Pausing the printer will pause the entire printer pool, and changing any properties will affect all printing devices in the printer pool.

12.7.2. Printing in {COMPANY} Because of the way Windows NT uses the Hardware Registry, we can make sure that the Machine always decides exactly where the print jobs should be redirected to, rather than allowing the User ID’s to change where the printer should be connected. This is important, since NT stores the Printer Driver with the Machine. The User Profile Editor has an option to disallow users from connecting and disconnecting printers - meaning that the Workstation should be configured upon installation. The recommendation is that at least 2 printers should be connectable by the workstation for contingency purposes. The installation steps for the printer driver and connecting to the printer is as follows : Installation


283. Log into the Domain from the Workstation as the Administrator 284. Start Control Panel 285. Double click on Printers 286. Click on “Printer” “Create Printer” 287. Type in the Printer Name 288. Select the Correct Printer Driver 289. Click on “OK” 290. Double click on “CSNW” in Control Panel 291. Turn “Print Banner” off 292. Click “OK” 293. The printer should be set up and can be immediately used. The printer is hardware specific,

i.e. the machine registry will always hold information on the printer. If the user “roams” to another machine, they have to be made aware that the printer may change.

13. Documentation of RAS Remote Access Services allow users to connect to NT Servers using a modem, and control that server as if it were connected locally on a LAN. Obviously, there are major benefits concerning RAS, and it allows any user to dial in from a remote location and utilise the network fully. Obviously there are drawbacks to a modem connection onto the network. Primarily, the first is Security. Using Dialback and only allowing certain IP Addresses access to the server will overcome this problem. Secondly, copying files across Modem links is slow - and obviously Microsoft Mail will download all mail that the user needs as if it were connected locally. As such, it is still recommended to run Remote Mail.

13.1. Overview of RAS RAS connects users over phone lines through the Remote Access Service to a remote network. Once a user has made a connection, the phone lines become transparent and the user can access all network resources as if they were sitting at a computer in an office that was directly attached to the network. RAS makes a modem act like a network card, projecting your remote computer onto a LAN.

13.1.1. Supported Dial-in Servers Windows NT RAS clients can connect to LAN Manager, Windows for Workgroups, Windows NT 3.1, and Windows NT Server 3.5 RAS servers. In addition RAS clients can also connect to non-Microsoft dial-in servers, such as UNIX-based dial-in servers (via the SLIP and PPP standards)

13.1.2. Supported Dial-in Clients Windows NT RAS servers can be connected to by LAN Manager, Windows for Workgroups, Windows NT Workstation, and Windows NT Server 3.5 RAS clients. In addition non-Microsoft clients can also connect to Microsoft servers, such as UNIX-based dial-in clients (via the PPP standard).

13.1.3. Supported Network Interfaces Any network application that uses any of the following interfaces will work over RAS: Windows Sockets -A bi-directional pipe for incoming and outgoing data between networked

computers. The Windows Sockets API is a networking API used by programmers creating IPX or TCP/IP sockets applications.

Network basic input/output system (NetBIOS)-A software basic input/output system used to

connect to network resources. Mailslots-A message delivery system used for announcing and locating network services and

resources. Named pipes-The Interprocess communication mechanism that allows one process to

communicate with another local or remote process. Remote Procedure Calls (RPCs)-A message-passing facility that allows a distributed

applic ation to call services available on various computers in a network. Used during remote administration of computers.

The RemoteAccess Service

LAN/WAN

Windows NT network (Win32) and LAN Manager APIs-Application programming interfaces available for applications to call functions of Windows NT or LAN Manager operating systems.

13.1.4. Windows NT RAS Connection Limitations Windows NT RAS supports up to 256 simultaneous inbound connections in the Windows NT Server network operating system, and one inbound connection in Windows NT Workstation. A mult iport serial device, such as a Digiboard® adapter, can provide multiple serial ports on one RAS server. The drivers for Digiboard adapters ship with Windows NT Workstation and Windows NT Server 3.5. When accessing NetBIOS resources, the limit to the numb er of simultaneous connections is 250. This is a limitation of the number of NetBIOS names that can be registered by a single system. When using Windows Sockets over TCP/IP or IPX, there are no software limitations to the number of simultaneous connections that can be made to the RAS Server. The maximum number of simultaneous connections that has been tested by Microsoft is 256.

13.1.5. RAS Software Compression RAS software compression is now supported in Windows NT 3.5. This software compression is based on the Microsoft DRVSPACE compression algorithm (from the MS-DOS operating system 6.22) with an average 2:1 compression ratio. Using software compression can improve connection speeds as much as eight times faster than a connection without compression.

13.1.6. Scalability The RAS server is multithreaded and can take advantage of multiprocessors. This allows threads of the Remote Access Service to run on multiple processors in a computer at the same time, improving RAS performance.

13.1.7. WAN Support RAS supports the following methods for establishing a connection between the RAS client and the RAS server.

13.1.7.1. Standard phone lines (Public Switched Telephone Networks) Windows NT RAS uses standard modem connections over Public Switched Telephone Networks (PSTN). An X.25 network transmits data with a packet-switching protocol. This protocol relies on an elaborate world-wide network of packet-forwarding nodes that participate in delivering an X.25 packet to the correct address. All remote workstations will be able to use an X.25 network by dialling an X.25 Packet Assembler/Disassembler (PAD). Windows NT Server 3.5 Remote Access Services have direct access via X.25 adapters, and Windows NT Workstation computers have direct X.25 connectivity in addition to asynchronous access to X.25 PADs.

13.1.7.2. Integrated Services Digital Network (ISDN) ISDN offers much faster communication speed than a standard telephone communicating at speeds of 64 to 128 kilobits per second. It is perfectly possible to configure RAS to utilise ISDN.

13.1.8. RAS Security Windows NT Remote Access Service implements a number of security measures to ensure that the remote user is a valid remote access user on the network. In some ways, going through RAS is more secure than sitting right at your network.

13.1.9. Integrated Domain Security The RAS server uses the same user account database as the Windows NT 3.5 Server. This provides for easier administration, since users will log on with the same user account that they use at the office. This ensures that users will have the same privileges and permissions they normally have. In order to connect, a user must have a valid Windows NT user account as well as the RAS dialin permission. Users must be authenticated by RAS before they are even allowed to attempt to log on to Windows NT.

13.1.10. Encrypted Authentication and Log on All authentication and logon information is encrypted when transmitted over the phone line.

13.1.11. Auditing With auditing enabled, RAS will generate audit information on all remote connections, including activities such as authentication, log ons, and so on.

13.1.12. Intermediary Security Hosts It is possible to add another level of security to a RAS configuration by connecting an intermediary security host between the RAS Client(s) and the RAS Server(s). When an intermediary security host is used, the user will have to type a password or code to get past the security device before a connection will be established with the RAS Server.

13.1.13. Call Back Security The RAS server can be configured to provide call backs as a means for increasing security. This allows another level of security by having the RAS server call the remote user to verify connection to the local network.

13.2. Installation of RAS on a Server RAS is easy to set up and configure. Primarily, the server should have a modem linked to it - preferably a 28.8 modem. The RAS will transmit packets as if it were a gateway, a remote PC running the RAS Client connects to an RAS Server and the modem link will transfer IP, IPX and even NetBEUI packets upon request. This means that the remote PC should see the entire network - and access all servers available to it as if the network were local. Before setting up the service - we need to check a couple of configuration items. From the Control Panel - double click on PORTS and make sure that the serial port is set to the highest speed that the port can access. For some UART16550’s - this may only be 57600 NOT 115200 as people imagine ! If you set it too high, then collisions will occur. This has to be set prior to the installation of RAS in its present form, since it is a pain reconfiguring the port settings. Next, double click on NETWORKS from the control panel, and make sure that the software installed on the machine includes IPX (for access to Novell Networks), TCP/IP as well as the NetBEUI Protocol. This must be made available for access to NT Domains and services. Prior to installation, you will need the original NT Server CD or Diskettes to hand as well as Service Pack 4 accessible to the server. You will need to have at least 2 IP Addresses available for access to each server. Of course, IP is not necessary if you only want to control services on a server or map a drive to a server within the same network. If, however, you wish to operate a server on the WAN - then IP needs to be installed. From the Control Panel, double click on Network and then Add Software. Pick Remote Access Service as a new piece of software to be added. The program will request for the CD/Disk to be inserted. The RAS Set-up program now copies the necessary files to your hard disk. The Add Port dialog appears. You will need to select the communications port to use from this list. Once the port is selected, RAS attempts to detect the modem - I normally choose the modem from the list although the sense can show whether the modem can actually be seen (US Robotics Sportster will not automatically be detected). You will also have to select one of three possible Port Usage Settings - Dial Out only, Receive Calls Only or Dial Out and Receive Calls. Recommended option is for the Dial Out and Receive Call option. Enable Hardware Flow Control MUST be checked for RAS to operate correctly. When the port is correctly configured, click on Continue.

The Remote Access Set-up dialog appears. Click the Network button to bring up the Network Configuration dialog - which allows you to decide whether RAS will allow access to the entire network (recommended) only to the local computer. When you are satisfied with the set-up, click on the OK button. Protocols selected on both dial-out and server settings should be NetBEUI, TCP/IP AND IPX. Allow Any authentication encryption including clear text. Once you have selected the appropriate protocols and authentication, click OK. For each selected Server Protocol, RAS Set-up will display a Server Configuration dialog - the most complex of which is the one for TCP/IP. The settings are displayed below :

The NetBEUI settings are the easiest to set up. It is recommended to presently allow the clients to access the Entire Network remotely. This allows us to be able to map a drive to any network drive as if it were a local client.

IPX Settings allow us to also see the Novell Network remotely - accessing services such as the Mail Admin programs, Documents and even Applications such as Microsoft Office across remotely ! Allowing IPX Clients to access the entire network is the correct option, as well as allocation of network numbers automatically. Assign the same network number to all IPX clients. These should be default options. The last network configuration, and often the most complex, is the IP Configuration. Allow the remote

clients to access the entire network and use a static address pool. The IP Addresses that we previously collected should be entered here. These IP Addresses MUST be allocated correctly and MUST be unique on the network. Click on the option at the bottom to allow remote clients to request a predetermined IP Address. This allows clients to utilise their workstations’ usual IP Address. In the diagram to the right, we can see that this server is connected to the Internet, and as such requires that the IP Addresses connected MUST be configured for this service.

Once you are satisfied with the protocol configuration, click the OK button to return to the Remote Access Set-up dialog. Click Continue to complete the set-up. Set-up will now create a Remote Access Service common group in Program Manager. You will use the icons in this group to run RAS after it has been installed. Set-up will then inform you that RAS has been installed and suggests that you configure it using the RAS Administration program. Click OK to complete the set-up. A binding analysis will be performed and you will be prompted to restart the computer. The bindings are now incorrectly set up. Once the computer has restarted, go back into Network Settings in Control Panel and click on the BINDINGS Option.

Click on Show Bindings For and move to NetBIOS Interface. The settings should have the WINS Clients above the NWLink NetBIOS with the NetBEUI protocols at the end. Make sure that the WAN Wrappers are underneath the bindings for the network card.

Move down to the Server Settings. Again, the bindings should be WINS followed by NWLink followed by NetBEUI. WAN Wrappers should appear after Network Card settings. The final settings should be for the

Workstation. Again, WINS appears before NWLink which appears before NetBEUI. Finally when the bindings have been placed in their correct order, then click on the OK button and the server will reconfigure the bindings. The machine

will ask you to restart. Do so. If there are any problems with the start-up of RAS - then the start-up will explain what the problem is, and any problems will appear in the System Log. To make sure that RAS is running upon start -up - go into Control Panel/Services - and check to see if RAS is running.

Finally, the last part of administration of the set-up is done using the RAS Administration Client. Found under the RAS Group in the Program Manager, double click on the icon and the Remote Access Administration program will start up. Hopefully, if all goes well, the machine should come up with a screen explaining that RAS is running and has 1 port configured. Services should be stopped and start ed here using the Start and Stop Remote Access Service options. Under the Users

button, we can set up users who wish to have access to the RAS Server. I recommend restricting this as much as possible since there are obviously security problems that could arise from RAS if not managed correctly. When a client connects, then Ports In Use should increase and the user can be Viewed.

13.3. Installation Guide of RAS on NT Client To connect to a server, the Remote Access program must be run. On the initial running, the application will ask you to set up a RAS Server in its address book. The RAS program is probably a little more tricky to set up than the Server application.

Enter the Entry Name of the fileserver that you wish to connect to. The Phone Number should also be added as well as a description of the server. If there are multiple servers - then enter a name that will easily be recognisable, e.g. the NT Fileserver Name or Service Name. Click on the Advanced Button.

If you do not wish to have the User ID and password that you log into your local Workstation with authenticated, then remove this option. If the remote server does not recognise the workstation User ID and/or Password, then it will offer an opportunity to put in a different Username or Password. Click on the Modem button at the bottom of the page

The Initial Speed should be set up to the highest port and modem speed your machine can handle. Enable the Modem Compression to achieve better throughput. The speed of a 28.8 modem connected to a UART16550AF Serial Port with 16K Buffers will offer a Maximum throughput of 115,200 bps with compression. Select the Network Button to configure the network settings. RAS uses the PPP (Point to Point Protocol) - and to fully connect to an NT Server, all protocols should be selected. Note that although NetBEUI is not actually a routable protocol, if IP is installed then NetBEUI will route over IP. Click on the TCP/IP Settings button to change the configuration of TCP/IP.

In our previous example of the NT Server attached to the Internet, the correct IP Address should be filled in for this workstation. Note that the IP Address could be either an IP Address predetermined for the machine and is identical to the one set up in the TCP/IP Settings in the Control Panel - or can be a new one. When the workstation connects, the previously bound IP Address is dropped for the new one - and then is bound back in once disconnected from RAS. As usual, DNS and WINS Controllers should be inserted. Make sure that the Use Default Gateway on Remote Network is correctly used.

Click on the Security Button and make sure that the options mirror that on the server. The Terminal or Script options are primarily for Internet and UNIX Operations for connection.

Once connected, the RAS should display a dialog box explaining which protocols connected, which did not and why. If a user is connected to the network already and tries to log in through RAS, then only the IP will connect since NetBEUI and IPX will be available on the network still. Immediately on connection, RAS will display an icon of a telephone off the hook next to the service connected, and Remote Access Monitor will automatically run. Additional troubleshooting can be viewed under the Status Button for the service.

14. TimeServ - Time Service for Windows NT 3.5 Time and Windows NT is never an accurate science. NT only pulls its time from the System Clock whenever it feels it is necessary - this means that when the machine is rebooted, then the time is pulled from the System Clock, and if the “skew” is more than 1 minute - then it also changes the time. This means that often a Windows NT box can often be more than 30 seconds inaccurate. This inaccuracy is a problem that is a direct result of the way that NT accesses hardware through the HAL. Because the HAL prevent access to ALL hardware directly, NT will often lose time. {COMPANY} has a standard where all workstations and servers should be accurate to within 1 second wherever possible. This means that a way needs to be found to reset clocks across the wide area network and to keep time synchronised wherever possible. This chapter describes the TimeServ program included in the Windows NT 3.5 Resource Kit. This is a service with two main goals. The first goal is to be able to set the system time of Windows NT accurately from a variety of sources. The second goal is to help synchronise the time easily between multiple machines on a Local Area Network. To set the time accurately, TimeServ can access the following sources:

14.1. Direct Dial Sources National Institute of Standards and Technology ACTS US Naval Observatory National Research Council Canada INMS BBC Radio Time Standard Dial-in Time Service Computime from Telecom Australia TUG/PTB/Sweden National Time and Frequency Laboratory/IEN

14.2. Internet TCP/IP Sources US Naval Observatory National Institute of Standards and Technology Simple NTP Heath "Most Accurate Clock" GC -1000 or GC-1001 (WWV(H)) Spectracom NETCLOCK/2(R) (WWVB) Trimble GPS receiver Rockwell GPS receiver Motorola GPS receiver Bancomm bc620AT or bc627AT (GPS-based) To synchronise the time easily, TimeServ can access the time from other Windows NT machines or many other machines running networking software from Microsoft. A machine can synchronise from a "primary" source (one server or a list of specific servers), or a "secondary" source. A secondary source is defined as a machine within a domain/workgroup which sets the "timesource" bit, and there is a feature in TimeServ which allows easily setting this bit on a Windows NT machine.

14.3. Installation instructions TimeServ requires Windows NT 3.5 or later to operate. An error message would be expected if trying to run under Windows NT 3.1. Installation


294. COPY TIMESERV.EXE and TIMESERV.DLL to %SystemRoot%\system32. 295. COPY TIMESERV.INI to %SystemRoot% 296. EDIT TIMESERV.INI to the values given in the section “Timeserv and {COMPANY}” based

on the type of Timeserver. 297. Log on with administrator privileges, if not done already 298. Run TIMESERV -AUTOMATIC or TIMESERV -MANUAL, depending on how you want the

service to start 299. Start the service either in the command prompt with NET START TIMESERV or in Control

Panel/Services 300. Check the Event log for any errors and for accuracy

14.4. Starting TimeServ After performing the installation procedure (with -automatic), a reboot would start TimeServ. TimeServ runs as a service, so you do not need to be logged on. If the installation procedure specified -manual, you must start TimeServ by using the Control Panel, then Services, selecting Time Service, and then pressing the Start button. You can also use this interface to change the start-up type, or stop the service. If you decide to edit TIMESERV.INI later, you must stop the service and run TIMESERV -UPDATE from a command line since the actual parameters are stored in the registry.

14.5. Checking Status When TimeServ is running, it places any errors, warnings, or other information into the Application log in the Event Viewer. Therefore you should start Event Viewer and select Application log to review the operational status. If there are no events in the log, TimeServ s hould be running fine. If desired, an option is available to write an event in the log for successful sets (Log=yes in timeserv.ini). Although the event description should be self-explanatory, more information appears later in this document. Of course you should also perform a sanity check on the operation and system time. If you are setting the time by modem, watch for the modem to operate. Check the time after around a minute, looking for any change. It should be accurate, and this would be easy to detect if the time was not accurate before. Also check the date. If the time/date are off by an hour or more, you probably have your time zone set incorrectly in the control panel and this needs to be corrected if you expect TimeServ to function properly.

14.6. Details Since TimeServ has multiple modes of operation, it is important to edit timeserv.ini to properly describe the necessary settings. This section of the documentation will give the background necessary. Although you might want to read each detail, you can typically skip modes not related to your desired mode of operation. After TimeServ runs and you check the status as described above, please realise that TimeServ continues to run and will periodically reset the time (with the process sleeping but boosting priority during the time set). Default network resets occur two or three times daily, but include a randomiser which adds up to ten additional minutes. If you wish to change from the defaults and set the time every twelve hours starting immedia tely, simply edit timeserv.ini to change Period from 0 to 2.

14.7. Service Types

14.7.1. NIST ACTS A service from the National Institute of Standards and Technology operated from Boulder, Colorado. A modem answers at 300 or 1200bps and supplies UTC in ASCII. Measurements can be made of line delay so that the "On Time Marker" arrives within 10ms (typically it is more accurate, and will be +/-2ms relative time when using the same modem). The call is typically long distance and less than 30 seconds. The above specification is for 1200bps, but we use 300bps hoping for +/-1ms absolute.

14.7.2. USNO A service of the U.S. Naval Observatory. It only operates at 1200bps, and requires a modem with Remote Digital Loopback (RDL) features using &T6 and related AT commands. The location is Washington, D.C. (it would make sense to try USNO if that is a local call for you).

14.7.3. INTERNET An alternative way to access USNO and NIST; it uses TCP/IP. It first tries to use USNO which includes delay measurement, but switches to NIST if that does not work (NIST doesn't include a proper delay measurement). Since the Internet is a WAN, it is not uncommon to see quarter- or half-second error. See also NTP, another Internet type.

14.7.4. NTP The Network Time Protocol, using IP usually over the Internet. TimeServ only uses a Simple adaptation of NTP, so should not to be confused with the accuracy and reliability of the full NTP. An NTP server must be specified (there is no default). (NTPServer=BroadcastClient and MulticastClient are reserved.)

14.7.5. NRC A service of the National Research Council Canada INMS. It only operates at 300bps, and supports propagation delay measurement. The location is Ottawa (it would make sense to try NRC if that is a local call for you). (There is a similar service in Toronto, but it uses local time rather than UTC so won't work correctly.)

14.7.6. BBC The BBC Radio Time Standard Dial-in Time Service over PSDN. It only operates at 300bps, and supports propagation delay measurement. The call is a Premium Rate service (British Telecom Callstream). The telephone number specified should be for the UTC Leith Clock System Controller (not the UK TOD number) - otherwise a one hour error will occur in Summer. The source for the Controller includes MSF (Nat.Phys.Lab.) and GPS receivers.

14.7.7. Computime Telecom Australia's dial-up time service over PSTN. It only operates at 1200bps, and does not support propagation delay measurement. We add 45ms to the time received as an attempt to adjust. Important: you must choose a PSTN number which matches your State, because local time and date are used (rather than UTC) - this means that the time set will be many hours off if you call from a country such as the USA.

14.7.8. EUROPE A name given to the common format used by services such as Sweden's National Time and Frequency Laboratory, Austria's TUG, Germany's PTB (Physikalisch-Technische Bundesanstalt), and Italy's IEN (Istituto Elettrotecnico Nazionale). They operate at 1200bps, and propagation delay measurement is not done for Italy. The locations are Sweden, Austria, Germany, and Torino (it would make sense to try EUROPE if that is a local call for you). Note that Italy's number is user-paid -service.

14.7.9. Heath GC-1000 Most Accurate Clock A WWV(H) radio receiver clock which supplies time in ASCII to tenths of seconds. The clock should be set to local time, 9600, with propagation delay set either 12 or 24-hr mode, and AUTO mode. The Hi Spec LED should come on from time to time (tenths of seconds should not be dim). It should be hooked to the PC by a "null-modem" cable. The program is coded for accuracy of +/-24ms (observed, though the spec of the clock/radio is +/-10ms), and prefers that the clock does not have "one second delay" enabled (if enabled, it takes a few seconds longer to set the time). If necessary for some reason, the clock can be set to NORMAL (rather than AUTO) mode, although results are slightly less accurate. GC -1001 is the Most Accurate Clock II, which has various time features (but not date). It should be hooked up as documented in the manual, can be set to either local or UTC, and should have received the time before starting TimeServ.

14.7.10. Spectracom Corp.'s (East Rochester, NY) NETCLOCK/2 A WWVB radio receiver clock which supplies time code in ASCII format with +/-3ms accuracy. The clock should have propagation delay (and receiver delay) set during initial setup, and the cable connection can be made either to the serial comm port, a TimeTap(tm), or the remote output RS-232 special pins. The recommended settings are 9600 baud and data format 2 if you have a choice, which allows highest accuracy and does not have any time zone/DST/year issues (note that format 2 is only available from the serial comm port). However, formats 0 and 1 are also supported, and other baud rates (such as 4800 or 1200) are supported (automatically). If using format 0 or 1 and local time (rather than UTC), you must have the proper settings for time zone and Auto DST (i.e., they must match the equivalent settings in Windows NT). Format 0 also requires that the year be set properly on the computer (manually). If using format 1 and UTC, you must set Windows NT to GMT (and match the Auto DST settings). Although not tested, the older model 8170 clock might be compatible.

14.7.11. Trimble A GPS receiver protocol from Trimble Navigation (TSIP over RS-232). It exists on receivers like the Acutime and MobileGPS. Note that the time might not be set immediately - it might take GPS around 15 minutes to acquire the information (during which time the COM port will remain used).

14.7.12. Rockwell A GPS receiver protocol from Rockwell International (messages over RS-232). It exists on modules like the NavCard. Note that the time might not be set immediately - it might take GPS around 15 minutes to acquire the information (during which time the COM port will remain used). (We don’t perform a manual cold start.)

14.7.13. Motorola A GPS receiver protocol from Motorola (binary format over RS-232). It exists on receivers like the 8-channel Oncore with timing options. The receiver must not be in NMEA o r LORAN format, and will be forced to position fix mode, application type static (to speed up acquisition), no GMT offset, UTC, polled position output, and T-RAIM enabled. Note that the time might not be set on the first pass (if the receiver isn't yet accurate to the microsecond).

14.7.14. bc620AT An ISA card from Bancomm Division of Datum Inc.(San Jose, CA) which has a timer with resolution to microseconds. Typically it is hooked up to GPS (Acutime) for accuracy within microseconds ( such as in the bc627AT package), or some time code source such as IRIG. The card has sixteen i/o ports at a default base address of 300h, so a device driver is necessary to achieve the i/o. Due to that requirement, this feature might be disabled in your copy of the program.

14.8. Primary and Secondary Modes The PRIMARY and SECONDARY modes of operation are meant for synchronization of time over the network. The strict definition of PRIMARY is that it obtains the time from any server specified in a PrimarySource list using the "NetRemoteTOD" feature of Microsoft LAN API, and SECONDARY obtains the time from any "TimeSource" in the current domain/workgroup (or specified SecondaryDomain). TimeSource is a server feature which can be set by TimeServ (simply edit timeserv.ini so that timesource=yes and run TimeServ -update). The synchronization is most accurate when accessing other machines running Windows NT, but also works with other machines such as Windows for Workgroups 3.11. It is also desirable to set the time from a LAN rather than WAN, although we attempt to adjust for different timezones and delays. The intent is to set up a multi-tiered distribution for accurate, synchronized time. The top level machine would run TimeServ in some mode other than PRIMARY/SECONDARY, such as obtain ing the time via modem. This becomes the new master of time. That server is placed on a LAN and its name should be specified in some other timeserv.ini as the PrimarySource (the default name in that file is \\timesource). A server in each domain could then run with type=primary and timesource=yes in their timeserv.ini. Finally, any clients at the bottom of the tier could run with type=secondary, or use the NET TIME command. If you wish to synchronize a client which cannot run TimeServ, check your clie nt documentation - there is often a command available such as NET TIME \\servername /set /y (where servername is the name of your server). Both primary and secondary support multiple servers - primary through a list in timeserv.ini and secondary through as many machines in a domain which have timesource specified. When working with the primary list, TimeServ can start with the first entry or a random entry (configured by the RandomPrimary entry in timeserv.ini), and sticks with that server until it is no longer available (or TimeServ is restarted). TimeServ is not an actual server and therefore type=primary does not specify that you are some primary time server. Rather, type=primary means that the time is obtained from a named server, which is typically higher up on a tiered distribution system. Many of all of the time-by-modem services reserve the right to discontinue or charge for their service at any time, and telephone companies reserve the right to change rates. Also the following accuracy information is intended to be correct, but the suitability of TimeServ for your specific purposes should be tested and determined by you.

14.9. Accuracy Information for Windows NT A default entry in timeserv.ini is TASync=no. This is one of the main reasons that Time Serv is not supported for Windows NT 3.1. It specifies that the TimeAdjustment flag in the system should be fixed and skew compensation allowed. By default, Windows NT regularly syncs the time to the CMOS RTC (on 3.51 or later it only does this when time is off by at least one minute). By specifying this option on the first time set after each boot, the clock will run using only the 8254-based timer which has greater precision and can result in greater stability. In this mode, skew compensation is possible (for error in the rate of the system timer). Of course, if CMOS sync is not disabled, the long term clock will take on the characteristics of the CMOS RTC with poor precision. Assuming that CMOS sync is disabled and using the popular i486 or Pentium CPU type, setting your time daily should result in a clock with maximum +/-.45 second error (twice daily +/-.22s, four times daily +/- .10s, etc). These figures are for TimeServ obtaining the time from a non-network source. Detailed skew compensation is not normally attempted when using a network source because of inconsistent delays over the network. In such cases if you notice time drifting more with TimeServ than you had experienced before, you might want to set TASync=yes. Warning: For skew compensation to work properly, you should never set the time manually while TimeServ is running. If you must set the time manually, either stop the Time Service first (and restart it after, if desired), or set TASync=yes.

14.10. Common Problems If you receive an error 17 when trying to run TimeServ and cannot see the descriptive text in the Event Viewer Application log, you probably forgot to run TimeServ -automatic or TimeServ -manual (which is a necessary installation step to create certain registry entries). If you get the same error number but see the descriptive text, you might have placed your edited timeserv.ini somewhere other than the required %SystemRoot%. Another reason to get that particular error (if you are trying Type=Secondary) is that you are not running any machines in the domain with Timesource=yes (TimeServ does not default to getting the time from a domain controller, although the NET TIME command might). If you use WinNT32 to update your installation of Windows NT, you may receive an error popup t hat the Time Service did not start. Press OK, and this error should not occur after the update is finished.

14.11. Registry Settings TimeServ keeps its settings in the registry under SYSTEM\CurrentControlSet\Services\TimeServ\Parameters. Key Name: SYSTEM\CurrentControlSet\Services \TimeServ\Parameters Value Name: TASync Value Type: REG_DWORD ;2=No, but uses "sticky" Adj value in registry and also implies "3" (since meant for gross errors). 3=No, but allows skew compensation for PRIMARY/SECONDARY/INTERNET/NTP types. Value Name: Type Value Type: REG_DWORD ;7=bc620AT Value Name: PPSPort Value Type: REG_ASCIIZ ;\\.\COM1 means use 1PPS signal on RS-232 (RI) to set the minor time. bc620A T means set minor time from bc620AT. Value Name: Mode Value Type: REG_DWORD ;2=Analysis means gather stats (only sets time on first pass). Analysis mode will set the time immediately, then wait to periodically compare the time again. The skew, drift, and stability can be displayed. Key Name: SYSTEM \CurrentControlSet\Services \TimeServ\Parameters\bc620AT Value Name: OpMode Value Type: REG_DWORD ;0=Time Code Decode, 2=1PPS, 3=RTC, 4=GPS Value Name: TimeCode Value Type: REG_SZ ;BM=IRIG B Modulated, BD=IRIG B DC level shift, etc

14.12. Timeserv in {COMPANY} {COMPANY} have a standard of 1 second accuracy for all devices on the WAN. Because of the way that Windows NT keeps time, an accurate method of timekeeping must be kept . As such, a “Tiered” model is viewed as the best solution. The timesource for the entire WAN is brought across from the Internet through the 2 servers at NIST ACTS and USNO. [TimeServ] Type=INTERNET Period=24 timesource=yes Log=yes RandomPrimary=yes TAsync=yes

This picks the time up from the internet on an hourly basis. Based on this, we measured an accuracy of <0.5 seconds for AVONBANK-A002 as the time source. The next level down is the Master Domain Controller - a server that all network servers in the master domain can view. Because of the amount of processor activity on a busy PDC, it was decided to utilise the following TIMESERV.INI [TimeServ] Type=PRIMARY PrimarySource=\\AVONBANK-A002 Period=48 timesource=yes Log=yes TAsync=yes

Under the PDC, the Master Domain BDC’s and the Resource Domain PDC’s should set their time from the Master PDC. This should be set at hourly intervals - and checked for accuracy. If the accuracy is not within 0.5 seconds - then a more frequent period should be maintained. [TimeServ] Type=PRIMARY PrimarySource=\\{COMPANY}ACKAGING Period=24 timesource=yes Log=yes TAsync=yes

There may be problems with WAN timings based on slower WAN links. Workstations and Application Servers should then set their clocks based on the LAN - ie, automatically trying to find the closest and fastest timesource. [TimeServ] Type=SECONDARY PrimarySource=\\AVONBANK-A001;\\AVONBANK-A003 Period=8 timesource=no Log=no ;SecondaryDomain={COMPANY}ACKAGING

InternetAVONBANK-A002

LMPACKAGING

TIMESOURCE

PRIMARYTIME SOURCE

PRIMARYTIME SERVERS

SECONDARYTIME DEVICES

RandomPrimary=yes TAsync=yes

it is imperitive to rem out the SecondaryDomain setting (or to delete it altogether) otherwise errors will

appear in the log. AVONBANK-W002 kept it’s time within 0.5 second.

11.04.96

15. Standard Installation guide for ARIANE project by {COMPANY}.

15.1. Collabra Share standard installation guide Installation


301. Set up a Server using the Installation Instructions based on that server. Make sure that all correct shares have been created and that the server is running the most up to date revisions of Service Pack etc etc

302. Check version of the Collabra Software. At this date the version must be: Collabra Share Server 2.01 Collabra Replication Agent 2.0 Collabra Share Client/Server 2.1

303. Login in as an administrator (NT-POSTOFFICENAME) to the Windows NT Server. 304. Insert the disk labeled "Collabra Share Server Disk 1 of 2" in drive A or drive B. 305. From the File menu in either Program Manager or File Manager, choose Run. 306. In the Run dialog box, type A:setup (or B:Setup). 307. Click OK 308. Into the Location for Server field enter the full path of the directory

C:\COLLABRA\FMSERVER. 309. Click OK to begin the installation. 310. When Setup finishes copying the Server program files into this directory a dialog appears

saying "Collabra Share Server setup successfully completed." 311. Click OK to dismiss this dialog 312. With User Manager for Domains (USRMGR.EXE) create a new user account to act as the

service account for the Collabra Share Server service. Choose the User/New menu item to create the following user: (see user: Collabra Share NE)

Username: Collabra Share + (first two letters of POSTOFFICENAME) Full Name: Collabra Share Service Account Description: Collabra Share Server at POSTOFFICENAME Password: collabra Select "User cannot change Password " and "Password never expire " This account needs to have full control over the directory (C:\COLLABRA) and files where you installed the Collabra Share Server program files. To set this, in File Manger select the directory you indicated as "Location for Server" above and choose the Security/Permissions menu item. Now either ensure that this new user account is a member of a group that has its Type of Access et to Full Control for the directory (C:\COLLABRA) and subdirectory's, or explicitly add this new user account and set it to have Type of Access as Full Control for this directory and subdirectory. Using the Windows NT User Manger tool, verify that Everyone is set to have the "Access this computer from the network" right. To check this, choose the Policy/User Rights menu item in User Manager. The User Rights Policy dialog appears. In the grant To List select Everyone and change the Right to "Access this computer from the network" if it is not already set that way. Click OK to close the dialog.

313. Check the Remote Procedure Call (RPC) Service. Make sure the RPC's is started and automatic. From the Windows NT Control Panel, open Service icon. Locate the Remote Procedure Call (RPC) Service.

Check to make sure that it is listed with a Status of Started and its Startup is Automatic. If not, select RPC Service selected and click Startup.

In the Service dialog appears, change Startup Type to Automatic. In the Log On As section of the dialog, System Account should be selected.

Click OK. 314. In the Service dialog, with RPC Service selected, click Start. The Status should change to

Started to indicate the RPC Service is running. 315. Start the Collabra Share Server As an NT Service. 316. From the Windows NT Control Panel, open the Service icon. 317. Select Collabra Share Server 2.01 318. Click Startup 319. In the Service dialog that appears, change Startup Type to Automatic. 320. In the Log On As section of the dialog select This Account, and enter the new user account

Collabra Share Collabra Share + (first two letters of POSTOFFICENAME). Set the password. 321. Click Ok. 322. A message should appear confirming that the user account has automatically been granted

the Log On As A Service right. (Note, you only get this message the first time you start up the service.)

323. Click Ok. 324. In the Services dialog with the Collabra Sahre Server 2.0 service selected, click Start.

The Status should change to Started to indicate the Collabra Share Server is successfully installed.

15.2. Installing the Collabra Share Client/Server Edition Installation


325. Copy actual package file to C:\COLLABRA. {COMPANY} Avonbank is the HUB. The HUB produces an package file (*.PKG; e.g. Neher.pkg, Bristol.pkg). This package file is necessary for the Client/Server Edition installation, special for the Policy Based Replication. If you do not have an *.PKG file, please contact IT Avonbank (Steven Donkin).

326. Check the permissions on C:\COLLABRA\.... Everyone and Collabra Share Service Account must have full controll to that directory and subdirectory

327. Make Share drives and network directory's. On File manager highlight the directory C:\COLLABRA.

328. Select Share As in File Manager by the option DISK. Click OK

329. On File manager highlight the directory D:\apps Select Share As in File Manager by the option DISK. Click OK

330. Create network drives by going into File Manager under DISK "connect network drive" 331. Select Shared drive "COLLABRA" from this NT server (Backup Domain Controller) to drive

"R". 332. Select Shared drive "apps" from this NT server (Backup Domain Controller) to drive "S".

Click Continue. 333. Put disk 1 from Client/Server Editions 2.1 in drive a: and run setup.exe 334. Select Server drive, select R:\COLLABRA\... (listing appears in window network drives ) 335. Select connect in window "First Installation or Connected to open Installation" 336. Write down actual package file D:\COLLABRA\*.PKG (e.g. second.PKG) in window

"Registry Package". 337. Click Continue 338. Select Button "Network Executables" and write down in "Location for Network Executables"

"S:\COLLABRA\BIN". 339. Select Button "Forum" and write down in "Forums Location on the Server"

"R:\FORUMS". 340. Select Button "Registry" and write down in "...Registry Location ..."

"R:\REGISTRY". 341. Select Install Sample Forums 342. Click Continue 343. Click YES on Message "Create directory which does not exist" 344. Specify the Site Name. Click Pulldown button and see whether your Site name appears or not.

This depends on actual state from HUB package-file. If this Site Name not appear write down one of the following names. LM Morin LM Trentesaux LM Neher LM UK Flexible Midsomer Norton LM Bristol LM Boulogne LM Singen LM Neuhausen

345. Click Continue. 346. Window "Confirm Settings" appears. Check these settings. 347. Click Continue. 348. Window "Collabra Share Network Install " appears with the Message "Do you wish to install

yourself the Client/Server Edition ?" Click No 349. Copy C:\apps\collabra\bin \*.* to Novell Netware Server. Ask IS person for an directory for

the Collabra Client installation program. The group NTGATEWAY must have full access to this directory. (e.g. at Neher: \\neher\vol2\daten\collabra \client2_1\). When the files are copied to the NW Server the NT Server do not need full control to this directory anymore

350. Check the connection to the POSTOFFICE. If not connected, connect with the filemanager the NW POSTOFFICE to M:. (e.g. \\neher\vol1\daten\Maildata).

351. start MSmail UA (mail icon on NT server) and specify m: to connect to an existing postoffice 352. Login as colladm and specify the location for the message file at the postoffice. You can do

that as following: Select ‘Mail’, ‘Option’ from the Menue, click on ‘Server’ and select Postoffice under Storage. To the same Thing for collrep.

353. 354. 355. 356.

15.3. Installing the Collabra Share Replicator Agent Installation


357. Note : HUB mailadress is MS:{COMPANY}ACK/AVONBANK/collrep 358. Put t he disk 1 from Replication Agent in drive A:. Start setup.exe. 359. Window "Update System Files" appears. 360. Click Continue 361. Window "Install Location" appears. Write down at "Location for Agent "

C:\APPS\COLLABRA\AGENTMGR. 362. Window "Installing Icons to ..." appears. Click OK. 363. Window "Restart windows and Dos appears. Click "Do not Reboot". 364. Click OK 365. Start AgentMgr. Click on that icon in "Collabra Share " Program group. 366. Click YES to "... replicate tasks automatically ..." 367. Important: If Replicator mail adress already defined in the HUB (Avonbank) the window For

"Mailbox Information " does not appear, otherwise you have to fill in the information. Most of Mail information will be given by IS person excapt the "Full mail adress". This must be as "Collabra Replicator PO-Name". (e.g. Neher: Mailbox Name: Replica2 Full Mail Address: MS:NEHER/NEHER/collrep Mailbox Password: password Mail System Type: Microsoft Mail.

368. Use the FileManager to disconnect the Network drive "S" and "R". 369. Use the FileManager to Stop Sharing of "COLLABRA" and "apps". 370. Log off and restart 371. login as NT-POSTOFFICENAME 372. copy a:\autolog.exe c:\windows\system32 373. start autolog.exe 374. type password in 375. Click OK 376. From the Windows NT Control Panel, open the Desktop. 377. Specify in "Screen Saver" frame in Name: "Logon Screen Saver". In delay "1 Minutes" and

select "Password protected". 378. Click OK. 379. Put Collabra Share Agent program into the startup window. 380. 381. 382.

15.4. Installing the Collabra Share Backup The Backup could not be d one automatically at the moment. Problem: During the Backup, it could be that Collabra Share will access the registry too. This causes registry errors. 5. create two batch files which has nearly the following contents. 1.) d:\apps\collabra \backup\monday.bat: xcopy D:\COLLABRA\REGISTRY\*.* \\neher\vol2\daten\collabra\backup\monday 2.) d:\apps\collabra\backup\thursday.bat: xcopy D:\COLLABRA\REGISTRY\*.* \\neher\vol2\daten\collabra\backup\thursday You have to replace the destination directory (\\neher\vol2\daten\..). In that example it was specific

for Neher, but you have to choose an directory on the NW Server which will be integrated in the Novell Netware Backup System (concept).

Again: E.g. Neher.

There we have full access to directory \\neher\vol2\daten\collabra. We have then created the following directories: \\neher\vol2\daten\collabra\Backup\Monday \\neher\vol2\daten\collabra\Backup\Thursday \\neher\vol2\daten\collabra\client21 (our collabra client installation program). At least create an window for this backup Batch files called Collabra Registry Backup. After that define two icons for each Backup - Batch file.

15.5. Replication Test 1. test of replication of new users. 2. test of replication of an brand new Forum created at HUB, e.g welcome forum.

the replication of the brand new forum should work like this: 1) a user requests a 'remote' forum 2) request received at hub site by a forum moderator for the other site's replication agent to

become a member. 3) moderator grants access to replicator 4) forum replication starts 5) user goes into forum (if not already added to forum by moderator) and requests access. 6) a moderator then grants access to that user

16. User Guide to NT Workstation

17. Appendix 1 - Glossary of terms used within this documentation