Copyright: Upgrade Guide for Microsoft LAN Manager for OS/2
Citation: Upgrade Guide for Microsoft LAN Manager for OS/2


Introduction
Introduction	1 of 3

Introduction

The Microsoft® Windows NT™ Server 3.5 Upgrade for LAN Manager includes the Windows NT 3.5 Server operating system and a set of utilities that convert a server running LAN Manager for OS/2® into a Windows NT Server computer.

Upgrading to Windows NT Server has important implications for the administration and security of your network. Planning the organization of your network before upgrading is very important, particularly if your network serves a large organization. While the Upgrade Manager helps you through the process, there are critical upgrade decisions that can only be made by you, based on your knowledge of your site's needs.

Prior to running or installing the upgrade utilities, read this manual and the Windows NT Server Installation Guide carefully. In addition, read the README.TXT file included on the upgrade utility disk or in the UPGRADE directory of the Windows NT Server CD-ROM disc for late-breaking information.

Important

All references to LAN Manager imply version 2.1a or later. All references to OS/2 refer to versions 1.21, 1.3, or 1.31.


Using this Guide
Introduction	2 of 3

Using this Guide

The Windows NT Server Upgrade Guide is intended for network administrators and operators. This manual assumes that you have basic knowledge of the OS/2 operating system, microcomputers, local-area networks (LANs), and Microsoft LAN Manager. You should also be familiar with the operation of Windows NT Server as detailed in the Windows NT Server System Guide.


Conventions
Introduction	3 of 3

Conventions

The following conventions, text formats, and symbols are used throughout this manual.

Convention	Meaning

Bold 	Indicates the actual commands, words, or characters that you type in a dialog box or at the command prompt.

Italic 	Indicates a placeholder for information or parameters that you must provide. For example, if the procedure asks you to type filename, type the actual name of a file. Italic also indicates new terms and the titles of other books in the Microsoft Windows NT package.

ALL CAPITALS	Indicates a directory, filename, or acronym. You can use lowercase letters when you type directory names or filenames in a dialog box or at the command prompt unless otherwise indicated for a specific application or utility.

Monospace	Represents examples of screen text or entries that you might type at the command prompt or in initialization files.

Indicates a procedure.

Indicates a procedure with only one step.

 	Indicates a list of related information, not procedural steps.

\WINNT 	Refers to the Windows NT system tree. All references to files in the Windows NT operating system assume that you installed Windows NT in the WINNT directory.

{braces}	Enclose required items in syntax statements. For example, {yes | no} indicates that you must specify yes or no when using the command. Type only the information within the braces, not the braces themselves.

[brackets]	Encloses optional items in syntax statements. For example, [password] indicates that you can choose to type a password with the command. Type only the information within the brackets, not the brackets themselves.

| (vertical bar)	Stands for "or" and separates items within braces or brackets. For example, {/hold | /release | /delete} indicates that you must type /hold or /release or /delete.

... (ellipsis)	Indicates that you can repeat the previous item(s) in syntax statements. For example, /route:devicename[,...] indicates that you can specify more than one device, putting commas between the device names.


About the Upgrade
Chapter 1	1 of 6

About the Upgrade

The Windows NT Server 3.5 Upgrade for LAN Manager is a set of utilities used to transfer information from a server running Microsoft LAN Manager for OS/2 to a server running Windows NT Server. These conversion utilities preserve user account information, file security settings, and server configuration information. This enables you to gradually integrate Windows NT Server into your existing LAN Manager network, preserving your existing time investment in server configuration, and saving time in the upgrade process.

The upgrade is for servers running LAN Manager version 2.1a and later; you can update to computers running Windows NT Server for x86, MIPS®, or Alpha AXP™ platforms.

Conversion is performed by transferring server files and configuration information from the server running LAN Manager for OS/2 to another computer, called a clone, running Windows NT Server. A conversion can also be performed "in place" on the existing server running LAN Manager, provided that the hardware configuration will support Windows NT Server.

To simplify the job of upgrading, the upgrade includes a pair of user interface programs that automate a large part of the upgrade process. One Upgrade Manager program runs utilities on LAN Manager; the other runs utilities on Windows NT Server. These programs run the upgrade utilities in a specific order, removing any need to memorize steps or commands. In addition, the programs are configurable; you can customize them to fit your typical server configuration.


What is and isn’t Supported
About the Upgrade 	2 of 6

What is and isn't Supported

Besides automating the transfer of user accounts and security settings, the upgrade:

Preserves as much as possible of the existing server configuration settings, including shared directories, service parameters, and logon script paths.

Enables upgrading to a single network logon or other trusted domain model.

Provides for recovery if the upgrade process is interrupted.

In addition, the following tables detail how various versions and features are dealt with by the upgrade.

Supported		Comments
LAN Manager for OS/2		Versions 2.1a and above
Sytos Plus®		Versions 1.11 and 1.34
File Replication		Settings are transferred only if account "REP" exists
Not supported		Comments
LAN Manager for UNIX®		Not supported
Network protocols		Not converted by upgrade; reconfigure in Windows NT Server
Printer settings, queues		Not converted by upgrade; reconfigure in Windows NT Server
Upgrade to a Server  that is not a PDC or BDC		Not supported
Remoteboot service settings transfer		Not converted by upgrade; use the Windows NT Remoteboot service upgrade
Account lockout		Not converted by upgrade; reconfigure in Windows NT Server


Overview of the Upgrade Process
About the Upgrade 	3 of 6

Overview of the Upgrade Process

For each domain, you must start your upgrade with the LAN Manager primary domain controller. If you are upgrading in place, this computer will become the domain controller in a new Windows NT Server domain. This domain can operate as a mixed domain as you gradually convert backup and member servers.

There are four parts to the upgrade process:

1.	Running the Upgrade Manager on a server running LAN Manager to capture configuration and security information. This stage allows you to back up system and data files to a tape drive, a network connection, or a clone computer.

2.	Installing Windows NT Server on the original server, or on a clone computer that is to replace the original server.

3.	Running the Upgrade Manager on the new computer running Windows NT Server to restore configuration and security settings.

4.	Performing post-upgrade tasks to verify the upgrade and ensure that your new computer running Windows NT Server and domain are fully functional.

The order of the upgrade stages will vary depending on whether you are upgrading to another computer or in place. If you are upgrading to a clone, your first step will be to install Windows NT Server on that computer, as shown in the following illustration.

An in place upgrade follows this order:

Restoring Files on a Clone Computer

If you are upgrading to a clone computer, you have several options for moving files to the second computer:

After installing Windows NT Server on the clone, use the hcopy utility to copy files directly to the clone. This is the recommended method.

Copy files to a network connection on a third server, and restore them from there onto your new computer running Windows NT Server.

Back up LAN Manager files using Sytos Plus (versions 1.11 or 1.34) and then restore them using Windows NT Server backup.

For more information, see "Preparing Backup Options" in Chapter 3, "Preparing to Upgrade."


Upgrade Manager Programs
About the Upgrade 	4 of 6

Upgrade Manager Programs

There are two Upgrade Manager programs that you'll use:

To begin the upgrade process, you'll run LMUPMGR.EXE on the server running LAN Manager for OS/2.

After you've installed Windows NT Server, you'll run WNTUPMGR.EXE on the computer running Windows NT Server.

These two programs present a graphical shell for the utilities that comprise the Upgrade Manager. On a server running LAN Manager, lmupmgr runs utilities that capture domain-level security and configuration information. Wntupmgr executes utilities that restore the captured configuration and security information on the new computer running Windows NT Server. This security information includes a list of user accounts and groups, as well as permissions associated with files and directories.

In addition to running the upgrade utilities, the lmupmgr and wntupmgr programs include the following features:

Log files that advise you about configuration issues that could prevent a successful upgrade

Help text

A choice of running one utility at a time or of running all or a subset of the utilities without interruption

For best results, use the Upgrade Manager programs to perform all upgrades. For more information on customizing these programs, see Chapter 4, "Upgrading a LAN Manager Server."


Upgrade Utilities
About the Upgrade 	5 of 6

Upgrade Utilities

The following table contains a description of each upgrade utility. Note that you can run utilities from the Upgrade Manager programs (the recommended method), from the command prompt, or as part of a batch file.

Utility	Purpose		Executed By
backacc¹	Backs up the LAN Manager user accounts database and network log file, and creates two files (NETACC.BKP and ACLBAKdrive.ACL) that contain user account information and the access control list information associated with all files and directories.		LAN Manager (lmupmgr)
backat	Reads scheduled commands stored in the SCHED.LOG file and writes them to a batch file as a series of commands. Running this batch file under Windows NT writes the schedule into the Registry.		LAN Manager (lmupmgr)
backenv	Captures the LAN Manager server environment by scanning server configuration files and detecting hardware configurations. The backenv utility generates a data file for use by the restenv utility, as well as a report, ADVISORY.TXT, to help complete the upgrade.		LAN Manager (lmupmgr)
acllist	Verifies that file information transfers correctly. The acllist utility records file permissions (access control lists or ACLs under Windows NT) and other characteristics in a text file, which the aclcomp utility checks for discrepancies.		LAN Manager (lmupmgr)
hcopy²	Copies files on the server running LAN Manager to the clone computer running Windows NT Server.		Windows NT Server (wntupmgr)
convert²	Converts FAT, HPFS, or HPFS386 volumes into NTFS volumes while preserving data.		Windows NT Server (wntupmgr)
restenv	Uses the data file created by backenv to restore configuration information under Windows NT Server.		Windows NT Server (wntupmgr)
userconv	Enables mapping of LAN Manager user accounts to existing Windows NT Server accounts in a local or a trusted domain.		Windows NT Server (wntupmgr)
portuas²	Merges a LAN Manager user accounts database (including remote access accounts) with an existing Windows NT security database.		Windows NT Server (wntupmgr)
aclconv²	Uses the ACL information file created by backacc and creates equivalent file and directory permissions on newly created or converted NTFS volumes.		Windows NT Server (wntupmgr)
sfmconv	Services for Macintosh® enables print and file sharing with Apple® Macintosh workstations. sfmconv ports Macintosh file volumes to Windows NT.		Windows NT Server (wntupmgr)
aclcomp	Compares the text output of acllist with file settings on Windows NT Server and flags all discrepancies.		Windows NT Server (wntupmgr)
¹	Use only the version of backacc included with the upgrade. Previous versions of backacc included with LAN Manager should not be used.

²	The utilities convert, portuas, xcopy, and aclconv are part of Windows NT Server. They are not installed by the upgrade.

Note

If your server is running LAN Manager version 2.0c, replace \LANMAN\NETPROG\BACKACC.EXE with the backacc utility provided with the upgrade. The latest version of backacc assures the integrity of user accounts and permissions. Note that the upgrade is supported only on LAN Manager version 2.1a or above.

The following diagram shows how utilities match Upgrade Manager options. Utilities that share information are connected. The restenv utility, for example, uses an output file generated by backenv to restore settings under Windows NT Server.

It isn't necessary to run all the utilities to upgrade your server. Several of the utilities are optional, depending on your LAN Manager configuration and on whether you want to verify the upgrade. For example, run the userconv utility only if you intend to map LAN Manager user accounts to existing Windows NT Server accounts in a local or trusted domain. (Run userconv in place of portuas.)

To check utility command usage, from the appropriate command prompt, type the name of the utility followed by /?. For example, hcopy /?. See Chapter 8, "Upgrade Utilities Reference," for complete usage information.


Settings Preserved by the Upgrade
About the Upgrade 	6 of 6

Settings Preserved by the Upgrade

The upgrade reads LAN Manager and OS/2 configuration files and restores equivalent settings under Windows NT Server.

The Upgrade preserves the following LAN Manager information:

User accounts

File and group permissions

Logon scripts

Shared directories

Connections to shared resources

Protocol settings that apply globally (such as NetBEUI settings)

Country codes

Scheduled commands

Time source server designation (if applicable)

In addition, the upgrade restores settings for the following services:

Workstation

Server

Netlogon

Replicator

Uninterruptible Power Supply (UPS)

Remote Access Service (RAS)

Simple Network Management Protocol (SNMP)

Note

Under LAN Manager, files and directories on FAT and HPFS partitions can be secured. Under Windows NT, only files and directories on NTFS partitions can have security. The upgrade tools maintain LAN Manager security that existed on FAT and HPFS partitions if the partitions are converted to NTFS. If you retain your FAT and HPFS partitions under Windows NT, security can only be applied to network shares.

The upgrade ignores LAN Manager settings that are not relevant under Windows NT. For example, because Windows NT allocates memory dynamically, it is not necessary to transfer most LAN Manager memory parameters. Similarly, LAN Manager share passwords are not ported because they do not exist under Windows NT. For a complete list of LAN Manager network parameters and their Windows NT equivalents, see Appendix B, "LAN Manager and Windows NT: Comparison of Network Parameters."

The upgrade does not transfer the following information:

Account lockout

Although Windows NT Server 3.5 now includes account lockout, the settings are not transferred by the upgrade.

Audit settings

There is no direct correspondence between LAN Manager and Windows NT auditing parameters. After upgrading, you must manually reapply file and directory auditing.

Fault tolerance settings

Fault tolerance settings are not upgraded because of the feature set differences between Windows NT Server and LAN Manager. Windows NT Server offers a large number of disk configuration options, including the options of adding disk drives.

Named pipe permissions

On Windows NT, named pipe ACLs are set by applications rather than through the user interface. Every time you restart your Windows NT computer, permissions on named pipes are lost until an application resets them. For this reason, the upgrade does not preserve access settings for named pipes.

Printer settings and printer queues

Because of differences in supported printer drivers, printers must be installed manually on the computer running Windows NT Server. To help you with this, all printer names and print queue settings are recorded in an advisory file.

Protocol settings that are specific to network adapter cards

Protocols such as TCP/IP, IPX, AppleTalk®, and DLC settings are network card specific. Although these settings are not ported, the upgrade checks post-upgrade protocol settings and notifies you if they differ from original PROTOCOL.INI values.

Remoteboot service settings

RPL settings are not transferred by the upgrade. Use the upgrade utility rplconv included with Windows NT Server.


Windows NT and LAN Manager Compatibility
Chapter 2	1 of 5

Windows NT and LAN Manager Compatibility

Windows NT Server maintains compatibility with servers running LAN Manager while expanding and enhancing the LAN Manager feature set. For example, Windows NT Server builds on the LAN Manager domain model but simplifies domain administration - instead of four types of servers, there are now three; instead of requiring an account for each domain, users can have a single network-wide logon. Similarly, Windows NT Server security features will be very familiar to LAN Manager users because they build on those of LAN Manager.

Because servers running Windows NT Server and LAN Manager can coexist and share resources in the same domain or network, you can upgrade as your schedule permits. However, before starting the upgrade process, you need to understand some basic differences between LAN Manager and Windows NT Server and the implications of operating in a mixed environment.

This chapter describes how servers running Windows NT Server and LAN Manager communicate, or interoperate, within a Windows NT domain, and how each type of domain coexists on the same network. For more information on administering Windows NT Server see Appendix A, "Differences in Administering LAN Manager and Windows NT Server" and the Windows NT Server System Guide.

Note

All references to LAN Manager servers in this manual imply servers running LAN Manager for OS/2.


Differences in Domain Administration
Windows NT and LAN Manager Compatibility	2 of 5

Differences in Domain Administration

Both LAN Manager and Windows NT Server use domains to centralize a user account database and as an authentication mechanism. Under both systems, a domain is a group of servers that share a common database of user and group accounts. However, under Windows NT Server, the user account database is called the security database. It includes user accounts, group accounts, computer accounts, and security policies.

In addition, Windows NT Server redefines the roles of servers and groups, and the relationship between domains on a network. These new relationships are important to understand prior to upgrading.

Servers and Clients

A Windows NT Server domain includes one Windows NT Server computer acting as the primary domain controller. Additional Windows NT Server computers in the domain function as backup domain controllers, and each of them can authenticate logon requests. Optionally, a Windows NT Server domain can also include servers running LAN Manager, Windows NT Workstation computers, and workstations such as those running Windows for Workgroups and MS-DOS®.

Workstations do not need updated software to make the transition from a LAN Manager to a Windows NT Server domain. However, to pass a domain name with their logon request, MS-DOS LAN Manager clients must be running LAN Manager version 2.1a or above. (OS/2 LAN Manager clients should run LAN Manager 2.2a from the Microsoft Network Client box.) This ensures that the correct domain validates the logon request. When clients run software prior to LAN Manager 2.1, the domain name is not passed, and is instead broadcast throughout the enterprise until a server recognizes the logon name. Not only does performance suffer, but the user may have accounts in several domains, and may not be validated by the correct server.

For security and administrative reasons, all network computers should belong to a Windows NT Server domain. However, computers running Windows NT Workstation can choose to join a workgroup instead of a domain. Windows NT Workstation computers that participate in a domain use the user accounts and groups from that domain; computers that join workgroups use only local accounts and groups on that computer.

Groups

Windows NT supports two types of groups: global and local. A global group can contain only users from the domain in which it was created but can appear in permission lists in any domain that trusts that domain.

A domain's local groups can contain users and global groups from that domain, as well as users and global groups from trusted domains. However, a local group can only be assigned permissions and rights in its home domain.

Because LAN Manager does not support local groups, local groups cannot be assigned permissions on servers running LAN Manager.

Trust Relationships

Windows NT Server supports trust relationships: links between domains that enable pass-through authentication. Trust relationships permit user accounts and global groups to be used in domains other than the domain where these accounts are located.

LAN Manager servers can operate in Windows NT Server domains and can recognize accounts from those domains. However, because servers running LAN Manager cannot participate in trust relationships, they are unable to recognize user accounts from trusted domains. As a result, you can assign permissions to users from trusted domains on the Windows NT Server computers in a domain, but not on the servers running LAN Manager in that same domain. For more information, see Chapter 6, "Upgrading to a Trusted Domain Model."


Interoperating in a Mixed Domain
Windows NT and LAN Manager Compatibility	3 of 5

Interoperating in a Mixed Domain

LAN Manager domains and Windows NT Server domains, with or without LAN Manager servers, can coexist and share resources on the same network. In a mixed network, the primary domain controller is always a computer running Windows NT Server; servers running LAN Manager are backup domain controllers or member servers. In a Windows NT Server domain that contains servers and clients running LAN Manager, user account modifications occur at the domain controller and are subsequently replicated to other servers in the domain.

There are a number of benefits to operating mixed domains. You can upgrade servers and clients running LAN Manager on a schedule that accommodates your needs. In addition, because LAN Manager clients can log on to computers running Windows NT Server, you can upgrade the servers running LAN Manager before upgrading the clients. Finally, you can retain servers running LAN Manager that cannot be upgraded for hardware compatibility reasons, or to keep LAN Manager features that are not included in Windows NT.

You do not have to add software to servers and clients running LAN Manager to operate in a mixed domain. However, there are some important rules to follow. One or more of the following steps may be necessary to give network users full access to various domains and servers:

Creating local accounts for users outside a mixed domain who must access LAN Manager servers in that domain

Creating local accounts for users from Windows NT Server domains without trust relationships or other LAN Manager domains who must access resources in a Windows NT domain

Placing Windows NT Server local accounts in the appropriate global groups

Configuring LAN Manager remote access servers to work with Windows NT Workstation computers

Maintaining LAN Manager servers that provide access to features and software that are not supported in Windows NT Server

For step-by-step instructions on completing these procedures, see Chapter 5, "Completing the Upgrade."

Important

To fully participate in a Windows NT Server domain, LAN Manager servers should be running the most recent version of LAN Manager.

The Role of Servers

In a domain with servers running both Windows NT and LAN Manager, the primary domain controller must be a computer running Windows NT Server. LAN Manager servers cannot function as primary domain controllers in Windows NT domains. If a LAN Manager PDC exists in a Windows NT Server domain, the users for the LAN Manager PDC will not be able to log on, and the resulting network conflicts could bring down the network.

To prevent confusion resulting from mixed domains, existing servers are polled to ensure that the role of a new server is consistent with the configuration of the domain. A new server will not start if it conflicts with the current configuration of the domain.

Mixed domains can contain backup domain controller, member, and stand-alone LAN Manager servers, which act just as they do in a LAN Manager domain. Avoid relying solely on LAN Manager servers for backups in a Windows NT Server domain, because they cannot be promoted to primary domain controller, and because they cannot authenticate logon requests from Windows NT Workstation computers.

Important

Do not attempt to promote a LAN Manager backup domain controller to replace a Windows NT Server primary domain controller, even if all functioning servers are running LAN Manager. All changes made under LAN Manager, including password changes, will be lost when you reinstate the Windows NT Server PDC.

User Account Administration

In a domain with servers running both Windows NT Server and LAN Manager, the primary domain controller must be running Windows NT Server. Administrative modifications to the user accounts database occur on the primary domain controller and are subsequently replicated to other servers in the domain.

Windows NT Server computers can administer servers and workstations running Windows NT as well as LAN Manager servers. LAN Manager clients can administer only servers and clients running LAN Manager. Within a mixed domain, always use Windows NT Server tools to manage domains.

Administrative Account Passwords

Passwords for administrative accounts may only be changed on a Windows NT Server computer. If an administrator changes her password on a server running LAN Manager, she loses the ability to administer user accounts. Users, however, can change their passwords at any computer in the domain.

Case-Sensitive Passwords

LAN Manager servers cannot take advantage of Windows NT Server features that LAN Manager doesn't support, such as case-sensitive passwords.

Locked out accounts

Because Windows NT Server 3.5 now supports locked out accounts, you may use this feature on LAN Manager servers in a mixed domain. The Account Locked Out setting specifies the maximum number of failed logon attempts users are allowed before their accounts are disabled. The upgrade does not transfer locked out settings, so you will need to reconfigure them after the upgrade.

Trust Relationships

LAN Manager servers do not support trust relationships. As a result, you cannot assign permissions on servers running LAN Manager to users and global groups from trusted domains, and users and global groups will not be able to connect to servers running LAN Manager without local user accounts.

Logon Validation

In a domain containing both Windows NT and LAN Manager servers and workstations, LAN Manager clients can be authenticated by servers running both Windows NT and LAN Manager. However, because Windows NT Server needs more information than is available from LAN Manager servers, Windows NT users can only be authenticated by Windows NT Server computers.

LAN Manager servers cannot validate logon attempts by computers running Windows NT Workstation or Windows NT Server, but they do maintain a copy of the user accounts database and can validate logon attempts by LAN Manager servers and workstations as well as network connection requests from Windows NT and LAN Manager workstations.

Replication of Account Information

Replication ensures that all servers in a domain use a single version of the user accounts database. In Windows NT Server domains, replication occurs from the primary domain controller to each server in the domain. A Windows NT Server primary domain controller can replicate to servers running both Windows NT and LAN Manager.

For more information on user account replication, see Appendix A, "Differences in Administering LAN Manager and Windows NT Server."

File and Directory Replication

Windows NT Server computers can replicate files and directories to LAN Manager servers and vice versa.

For information about setting up file and directory replication, see the Windows NT Server System Guide.

Local Groups

LAN Manager servers do not recognize local groups, so local groups in a Windows NT Server domain are not replicated to down-level servers and cannot be assigned permissions on LAN Manager servers.

Limits on the Number of Users, Groups, and Domains

Networks with mixed domains are subject to the following LAN Manager limits:

The effective number of groups in a mixed domain is 252. Exceeding this limit can cause replication problems. When used alone, Windows NT supports an unlimited number of groups.

LAN Manager supports up to 254 domains. If your network contains a mixed domain, it cannot exceed 254 domains. If domains consist entirely of Windows NT computers, a network may contain up to 4096 domains.

To avoid limits on the total number of users and groups, organize your network into a master domain that consists only of Windows NT Server computers and several mixed domains that trust the master domain. If you centralize all network user accounts and global groups in the master domain, you won't have to worry about LAN Manager limits. See the Windows NT Server Concepts and Planning Guide for more information on domain models.

The LAN Manager Net Admin tool cannot display more than 3120 users. The Windows NT network administration program cannot display more than 8000 users. To avoid viewing limitations in a mixed domain, use Windows NT Server tools to manage user accounts.

Note that 16,000 is the theoretical limit on the number of users in a LAN Manager domain. The theoretical limit on Windows NT Server is much higher. However, the practical limit on the number of users in a Windows NT domain is dependent on the hardware configuration (amount of memory, type of processor, and disk space) of the server. Please refer to the Windows NT Server Concepts and Planning Guide for information to assist you in determining the number of users.

Accessing LAN Manager Servers in Trusted Domains

Because LAN Manager does not support trust relationships, it cannot make use of the users and global groups defined in Windows NT Server domains.

You can solve this problem by creating a local account for each user from a trusted domain who needs to access a server running LAN Manager in a Windows NT domain. For example, if BlakeR from the Finance domain needs to access a LAN Manager server in the Windows NT Server domain Sales, the domain administrator must create a local account for him on a Windows NT Server in Sales.

Creating Local Accounts

Local accounts are created just like regular Windows NT user accounts, except that while creating the account, you use the User Manager for Domains tool to designate it as a local account. In any list of Windows NT users, a special icon designates local accounts to differentiate them from global accounts.

Local accounts can also be used to allow access to a Windows NT Server computer from an untrusted domain. You must create a local account in every Windows NT Server domain that a user needs access to.

Placing Local Accounts in Global Groups

After creating a local account, place it in global groups in your domain and assign those global groups the required permissions on the server running LAN Manager in your Windows NT domain. You must use global groups because LAN Manager servers do not recognize local groups. Avoid giving permissions directly to local accounts. They are difficult to maintain once you upgrade to Windows NT Server and, the local accounts are no longer required.

Accessing LAN Manager Domains

Users in Windows NT Server domains can access resources in LAN Manager domains by having an account in the LAN Manager domain.

Evaluation Domains

If you create a test domain for evaluating Windows NT Server, make sure the domain does not contain accounts for LAN Manager servers that exist in another domain. For example, if you upgrade accounts from a LAN Manager primary domain controller to a Windows NT Server in a new domain, leave the original domain intact and delete LAN Manager server accounts from the new Windows NT Server primary domain controller. Otherwise, the new primary domain controller will interfere with account replication between the original LAN Manager primary domain controller and the backup and member servers in its domain.

For instructions on deleting server accounts, see Chapter 5, "Completing the Upgrade."


Configuring Servers for Interoperability
Windows NT and LAN Manager Compatibility	4 of 5

Configuring Servers for Interoperability

This section describes server configuration steps that can improve performance in a mixed environment. For instructions on editing configuration parameters in the Windows NT Registry, see the Read Me icon in the Main program group of Windows NT Server.

Configuring Remote Access Servers

In a mixed domain, your Remote Access Service (RAS) server can be a server running LAN Manager or Windows NT Server.

For LAN Manager RAS servers to service Windows NT Workstation computers, you must configure LANMAN.INI and PROTOCOL.INI files as follows:

In LANMAN.INI:
[remoteaccess] maxnames=8		;Needed for extra NetBIOS names on Windows NT workstation computers
remotelisten=all		;Needed to enable peer capabilities of Windows NT workstation computers through RAS server
In PROTOCOL.INI:
[ubxps_xif] numnames=112 VCs=254		;Or the equivalent for your network adapter card.
[netbeui_xif] sessions=254 ncbs=255 names=82
If your Windows NT RAS server is a member of a large domain, it participates in domain replication and the overhead that accompanies it. To minimize memory required by a Windows NT RAS server, you can set it up as just a server, not a backup domain controller, or set up the server in its own domain and have it trust a larger domain containing user accounts. This provides the benefit of a domain-wide user account database without the overhead of replication.

Configuring LAN Manager Ring 3 Servers

If a mixed domain contains LAN Manager Ring 3 servers, it may be necessary to configure these servers to avoid overloading them. Ring 3 servers service both FAT and HPFS 16-bit file systems, but do not service HPFS386 volumes.

The default configuration of LAN Manager Ring 3 servers allows a total of 50 open files from remote clients and 50 from each client workstation. Because the Windows NT redirector may keep files open in the cache after an application has closed the file, this means that the redirector may overload a misconfigured LAN Manager server.

To correct this problem, increase the value for the maxsessopens parameter for the server running LAN Manager. Or, increase the Windows NT Registry parameter DormantFileLimit. This parameter specifies the maximum number of files that should be left open on a share after the application closes the file. Its Registry location is HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\LanmanWorkstation\Parameters.

Overloading is not a problem with HPFS386 servers.

Configuring for Communication with IBM DOS LAN Requestor Clients

To improve performance between computers running IBM® DOS LAN Requestor (using the IBM DXMxxMOD.SYS drivers) and Windows NT computers, adjust the NBF Registry parameter MaximumIncomingFrames. This parameter is located in the Registryin HKEY_LOCAL_
MACHINE\SYSTEM\CurrentControlSet\Services\Nbf\Parameters. It can be used to control how many incoming frames NetBEUI receives before it sends an acknowledgment to a remote machine. Changing the key value from 2 (the default) to 1 causes NetBEUI to respond after every frame.

Configuring a Timesource Server

Both LAN Manager and Windows NT servers can function as timesource servers in a mixed domain. If you upgrade a LAN Manager server that is designated as the timesource, the restenv utility preserves this configuration by writing a value to the Registry.

Otherwise, to designate a Windows NT Server computer to be a timesource server, you must manually configure it as follows:

In the Registry location HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\LanmanServer\Parameters, choose Add Value from the Edit menu. Add the Value Name "TimeSource" and make the DataType "REG_DWORD" in the DWORD Editor dialog box. The data value must equal 1 to be a timesource server or 0 for non-time server. To check the configuration change, reboot and type net time at the command prompt.


Retaining LAN Manager Functionality
Windows NT and LAN Manager Compatibility	5 of 5

Retaining LAN Manager Functionality

Windows NT Server supports most LAN Manager features and services. However, in order to maintain full functionality, you need to retain selected servers running LAN Manager. When choosing LAN Manager servers to retain, consider the following:

If you have tape archives, you may need to keep a LAN Manager server for data restoration purposes. (Windows NT Backup can restore only tapes created using version 1.11 or 1.34 of Sytos Plus.)

If LAN Manager clients are running MS Router, maintain several LAN Manager TCP/IP hub and node servers to manage these clients

Make sure client/server applications running on a LAN Manager server are supported under Windows NT.

Make sure that you have a valid license to continue running the LAN Manager server.


Preparing to Upgrade
Chapter 3	1 of 13

Preparing to Upgrade

This chapter helps you make the decisions and preparations necessary to upgrade a server running LAN Manager to a Windows NT Server computer. Topics include:

Hardware and space requirements

Choosing between an in place or clone upgrade

Preparing server backup options

Scheduling the upgrade process

Disabling local security

For each LAN Manager domain you upgrade, upgrade the primary domain controller first. This becomes the primary domain controller of a new Windows NT Server domain. All other servers can function as they are. After this step, you can then upgrade any LAN Manager backup or member server in the domain. When you install Windows NT Server, you will be asked for a domain name, which is the name of the Windows NT Server domain.


Hardware and Space Requirements
Preparing to Upgrade 	2 of 13

Hardware and Space Requirements

The upgrade process requires that the destination computer meet Windows NT Server minimum requirements. Additionally, this computer must have enough space to hold upgrade files and, optionally, to convert partitions to the Windows NT file system (NTFS).

Windows NT Server Minimum Requirements

To run Windows NT Server, a computer must meet the following minimum requirements:

Category	Requirement

Hardware	32-bit x86-based microprocessor (Intel® 80386/33 or higher), or supported RISC-based microprocessor such as the MIPS R4000™ and Digital Alpha AXP System

VGA, or higher resolution, video display adapter

One or more hard disks, with 92 MB minimum free hard disk space on the partition that will contain the Windows NT Server system files (110 MB free disk space required for RISC systems)

For x86-based computers, a high-density floppy disk drive

For RISC-based computers, a SCSI® CD-ROM drive

One or more network adapter cards

Memory	16 MB RAM recommended minimum for x86 system; 16 MB minimum for RISC system

Optional components	Mouse or other pointing device

One or more SCSI CD-ROM drives (required for RISC-based computers)

Server hardware must also be compatible with components listed on the Windows NT Server Hardware Compatibility List (included with your upgrade).

Upgrade Space Requirements

The upgrade process requires that the destination computer have a partition with enough free space to hold the Windows NT Server system files (approximately 92 MB), as well as the upgrade executables and their output files. The upgrade utilities require approximately 2 MB; the size of output files depends on the number of files and assigned permissions. In general, allow at least 1 MB for utility output.

To retain HPFS386 file permissions, you must convert Windows NT Server partitions containing HPFS386 files to NTFS. For security reasons, the partition containing Windows NT system files should also be NTFS. We recommend that you convert this partition to NTFS during Windows NT Setup.

Important

Converting to NTFS requires that approximately 10 percent of your partition space be free.

You can format additional NTFS partitions using the Windows NT format command if those partitions do not contain data. To preserve data, use the convert utility provided with Windows NT Server.

For each server you are going to upgrade, gather the following information prior to installing Windows NT Server.

Drive letter of the partition that will contain Windows NT Server, the upgrade utilities, and your paging file:		______
Total partition size:		______ MB
Free space required for Windows NT Server (including 20 MB paging file):		92 MB
Free space required for upgrade utilities and output files:		3 MB
Free space for NTFS conversion, if converting to NTFS (10 percent of total partition space):		______ MB
Minimum total free space required:		______ MB


Windows NT Remoteboot Service
Preparing to Upgrade 	3 of 13

Windows NT Remoteboot Service

The LAN Manager Remoteboot service is not transferred as part of the LAN Manager upgrade. However, the Windows NT Remoteboot service product has an option to upgrade the LAN Manager Remoteboot service. If you plan to install Windows NT Remoteboot service and want to upgrade your LAN Manager Remoteboot service, follow these guidelines:

Complete the Windows NT Server version 3.5 Upgrade for LAN Manager before installing Windows NT Remoteboot service.

As part of the LAN Manager upgrade, make sure you retain or copy the LAN Manager Remoteboot directory (for example, <LANROOT>\LANMAN\RPL) to your Windows NT Server computer. The Remoteboot service upgrade uses the files in this directory to upgrade Remoteboot service.


Choosing a Clone or an In Place Upgrade
Preparing to Upgrade 	4 of 13

Choosing a Clone or an In Place Upgrade

Keeping hardware and space requirements in mind, you must decide whether to upgrade in place or upgrade to a second computer (a clone) to replace the first. If the computer hardware for your LAN Manager server is not compatible with Windows NT Server, you will need to upgrade to a clone.

Upgrading to a Clone

Using a clone computer is the preferred way to perform upgrades. It causes less disruption to network operations and leaves you with an excellent backup solution. This is also a good opportunity to upgrade hardware and recycle older computers to workstation status. Upgrading with a clone is often faster because you can install Windows NT Server prior to starting the upgrade.

Upgrading to a clone requires you to install Windows NT Server on a second (destination) computer and to copy data files from the server running LAN Manager to the Windows NT Server clone. The server running LAN Manager can remain online during the upgrade process and, if preferred, you can maintain two separate domains while you evaluate the upgrade.

Upgrading In Place

Upgrading in place requires no extra hardware, but does require enough free disk space to install Windows NT Server and convert partitions to NTFS (see "Upgrade Space Requirements," earlier in this chapter). If your server has adequate free space and meets Windows NT hardware requirements, you can upgrade without moving data files.

Important

Do not perform in place upgrades on hard disks that are heavily fragmented.

Repartitioning for an In Place Upgrade

If your server running LAN Manager does not have enough space to install in place, you may be able to create additional space by backing up data files, reformatting and repartitioning your hard drive, and then restoring files after installing Windows NT Server. This upgrade method is the most time-consuming. Before attempting it, make sure your backup solution is reliable and supports restoring data to Windows NT Server.

Use the Windows NT Setup program to repartition your disk and format the partition that will contain Windows NT Server. After completing Windows NT installation, use the format command to format additional partitions to NTFS.

Dual Booting with OS/2

If space permits, you may choose an in place upgrade that preserves a dual boot configuration with OS/2. However, once you convert a partition to NTFS, files on this partition are unavailable from OS/2 or MD-DOS.

To use the OS/2 Boot Manager, OS/2 must be installed on the c: drive, formatted as FAT. Windows NT Server must be installed on a separate NTFS volume. Note that if you convert drive c to NTFS during the upgrade, you will not be able to boot OS/2. For more information on switching between OS/2 and Windows NT Server, see Chapter 5, "Completing the Upgrade."


Preparing Backup Options
Preparing to Upgrade 	5 of 13

Preparing Backup Options

Prior to starting the upgrade, you'll need to back up the files on your server running LAN Manager. You need to do this in order to protect your data during the upgrade, and to restore data files to the Windows NT Server computer. For example, if you need to repartition your server running LAN Manager to make room for the upgrade, you'll need to back up data files and then restore them after repartitioning your disk. Or, if you are upgrading to a clone, you can back up files directly to that computer, provided you first create network connections to that computer.

Possible backup options include:

Sytos Plus backup (versions 1.11 and 1.34).

Copying files to another server using the hcopy utility. (Hcopy is a modified version of the xcopy command with the ability to copy hidden files and directories.)

The LAN Manager Upgrade Manager program prompts you to perform one of these two backup options. Back up immediately after running the utilities to ensure that there is no discrepancy between backup files and the information collected by the upgrade utilities.

Note that hcopy and Windows NT Backup skip files with the following names: CON, PRT, LPTx, COMx, where x is a number from 1 to 9. Files with these names conflict with reserved system names and thus cannot be copied.


Using Sytos Plus and Windows NT Backup
Preparing to Upgrade 	6 of 13

Preparing Backup Options

Using Sytos Plus and Windows NT Backup

Windows NT includes a version of backup to support data restoration from versions 1.11 and 1.34 of Sytos Plus.

To restore data from Sytos Plus tapes, Windows NT must support the SCSI controller and tape drive used to make the tape. Before deciding on a backup option, check the Windows NT Server Hardware Compatibility List to see if your tape drive is supported. Note that Windows NT cannot write to tapes using the Sytos Plus format.

For information on using Windows NT Backup, see the Windows NT Server System Guide. If you have trouble restoring files from a Sytos Plus tape, see Chapter 7, "Troubleshooting," in this manual.

Notes on Using Windows NT Backup

When restoring directory paths of 256 characters or more, Windows NT Backup will create a directory called TOO_LONG.BKP. The last directory named is restored into the subdirectory \TOO_LONG.BKP. For example, if you try to restore \ENGINEERING\NOTES\BACKUP\DAILY
\INCREMENTAL\...\SERV1\VOLUME2\FILES.LOG the application will restore this information to \TOO_DEEP.BKP\VOLUME2\FILES.LOG.

Services for Macintosh supports file and directory names that end in a period or a space. Windows NT Backup backs up and restores files and directories ending in a period or a space using a short MD-DOS - style name.


Backing Up to Another Server
Preparing to Upgrade 	7 of 13

Preparing Backup Options

Backing Up to Another Server

If you intend to back up to a network server or a clone, set up connections prior to running the Upgrade Manager program on your server running LAN Manager. Create one connection for each logical disk you want to back up. Connections must correspond to drive letters; universal naming convention (UNC) names are not supported.

If you are copying files to a clone, do not use drive letters that correspond to persistent connections on the original server running LAN Manager.

Important

When copying files to a clone, make sure to include the LAN Manager root directory. This ensures that logon scripts transfer to Windows NT Server.


Disabling Local Security
Preparing to Upgrade 	8 of 13

Disabling Local Security

Local security is built into Windows NT Server. Before upgrading, disable local security on any server running LAN Manager you intend to upgrade.

To disable local security on a server running LAN Manager

1.	Log on to an account with administrative privileges at the server.

2.	In the OS/2 Full Screen, type setup from the LANMAN directory.

3.	From the Configuration menu, choose Server Settings.

4.	Disable local security.


Account Synchronization
Preparing to Upgrade 	9 of 13

Account Synchronization

Make sure accounts are synchronized prior to upgrading. If user accounts are not synchronized, this can result in creation of a NETACC.BKP file that contains incorrect information. To prevent this, the LAN Manager Upgrade Manager automatically checks for synchronization, as follows:

For LAN Manager primary domain controllers, the LAN Manager Upgrade Manager checks to see that user accounts on backup domain controllers and member servers are synchronized with the primary domain controller. If accounts are not synchronized, the Upgrade Manager starts synchronization and then rechecks status once a minute for 10 minutes. If synchronization is not complete after 10 minutes, the Upgrade Manager offers the option of exiting or stopping the Net Logon service and continuing the upgrade.

If you run the LAN Manager Upgrade Manager on a member or backup domain controller and the primary domain controller is not already running Windows NT Server, the Upgrade Manager verifies that the local UAS is synchronized with the primary domain controller. If not, it initiates synchronization as described in the previous paragraph.

If you run the LAN Manager Upgrade Manager on a backup domain controller or member server and the primary domain controller is running Windows NT Server, synchronization is not checked.

The LAN Manager Upgrade Manager only checks for synchronization on servers that are running LAN Manager version 2.1a and above. Note that if the Net Logon service is stopped on one of the servers in the domain, the Upgrade Manager will report an error during its synchronization attempt and then continue with the upgrade (if Net Logon is not running on the specific machine being upgraded, error 2453 is shown).


Upgrading File Replication Settings
Preparing to Upgrade 	10 of 13

Upgrading File Replication Settings

If the file replication service is running, you'll need to get the latest update. Before starting the upgrade process, initiate a file replication synchronization.

To retain LAN Manager file replication settings under Windows NT Server, you must create a special service account called REP on the Windows NT Server primary domain controller prior to running the Windows NT Server Upgrade Manager on the server you are upgrading. If the computer running Windows NT Server is aware of this service account (the Upgrade Manager transfers this account if previously present on the domain controller being upgraded), the restenv utility restores file replication. Otherwise, file replication configuration is not preserved.

To create a service account, log on to an account with Administrative privileges. If this is the first server to be upgraded with file replication, perform steps 1 through 8 on the primary domain controller. On the remaining servers in the domain, complete steps 4 through 8.

To Create a Service Account for File Replication Upgrading

1.	Run the User Manager from the Administrative Tools group on the server designated as the primary domain controller.

2.	Create a new user account for replication called REP (in the LANMAN.INI file, change the logon parameter to "Logon =REP"). If a password is desired, change the "Password =<password>" parameter. Clear the "User Must Change Password At Next Logon" check box. Choose the Add button, then the Close button.

3.	Choose Exit. Then close User Manager.

4.	In Control Panel, select Services.

5.	Choose the Directory Replicator service and choose Startup. Change the Startup Type from Manual to Automatic.

6.	In the Log On As box, choose This Account. Then choose Add User. Select the Domain Service account created in step 2 above and choose Add and then OK.

7.	Type the password for the replication account and choose OK. (Note that this is the same password specified in Step 2.) If there is no password, leave this blank. Control Panel responds with a message such as "The account DOMAIN\REPL has been granted the Log On As A Service right and added to the Replicator local group."

8.	Choose OK to dismiss this message. Choose Close Services.

Restenv will automatically start Directory Replication Services.


Scheduling Your Upgrade
Preparing to Upgrade 	11 of 13

Scheduling Your Upgrade

An important consideration for upgrading is the amount of time the server running LAN Manager will be offline. Ideally, you should upgrade when there is the least activity on your network. Note that upgrading to a clone minimizes server downtime. The time it takes to upgrade depends on the amount of files and accounts you will be transferring, and your knowledge of Windows NT Server and Microsoft LAN Manager. Use the following guidelines to estimate the time for your upgrade.

Prepare to upgrade: review this manual, review NT requirements, and gather other needed information-your own estimate is most accurate.

Install Windows NT Server-1 to 4 hours. Note that if you are upgrading to a clone, you can install Windows NT Server before you take the server running LAN Manager offline.

Run the utilities for the actual upgrade-2 to 4 hours for standard installations; 8 hours or more for large installations.

Perform post-upgrade tasks: checking the conversion, performing various post-upgrade tasks-2 to 4 hours.

For best results, upgrade a server in one session, rather than over an extended period of time. This minimizes the possibility of changes to user accounts or file permissions during the upgrade. Such changes can cause problems after the upgrade. For example, if a password changes on a LAN Manager primary domain controller during the upgrade, the new password might not export to Windows NT Server. This can eventually cause a logon conflict between existing servers running LAN Manager and the new domain controller.


Upgrade Checklist
Preparing to Upgrade 	12 of 13

Upgrade Checklist

Before upgrading an existing server running LAN Manager, check that the following is true:

All existing drives, adapter cards, monitors, and backup media on the destination computer running Windows NT Server are listed on the Windows NT Server Hardware Compatibility List.

Your destination server meets the hardware and space requirements for upgrading to Windows NT Server and has enough additional space to accommodate all the files from the server running LAN Manager. Hard disks should not be heavily fragmented.

You have run the chkdsk utility on your server running LAN Manager. If errors exist, run chkdsk /f to fix them. If there are errors on the boot partition, boot from the OS/2 Installation A floppy disk, and run chkdsk /f from disk 1 of the OS/2 installation set. For HPFS, run chkdsk /f:3.

You have removed all unnecessary files from the server running LAN Manager. This shortens the amount of time needed for the upgrade. Do not remove any LAN Manager directories.

Make sure accounts are synchronized prior to upgrading. If user accounts are not synchronized, this can result in creation of a NETACC.BKP file that contains incorrect information.

The srvhidden parameter in LANMAN.INI is set to no. If svrhidden is yes, the LAN Manager Upgrade Manager cannot correctly verify the synchronization state of domain servers. If svrhidden is yes, change it to no and then stop and restart the server service.

You have disabled local security on your server running LAN Manager.

You have a reliable backup method for your server running LAN Manager. The Upgrade Manager gives you the choice of backing up files to another server or to a Sytos Plus compatible tape (version 1.11 or 1.34). If you plan to back up to a network connection, create connection(s) prior to running the Upgrade Manager on the LAN Manager server. Create one connection for each partition.

If you have installed a prerelease or earlier version of the upgrade product, delete it before installing this version. Move to the UPGRADE directory and delete all files. In addition, remove *.ACL files from the directory <LANROOT>\ACCOUNTS. This ensures that the Windows NT Server Upgrade Manager uses the correct *.ACL files to assign file permissions.

Network protocol conflicts do not exist between the LAN Manager and a Windows NT Server clone.

In order to give multiple LAN Manager import servers access to the export directory tree, you may have created the group REP on your LAN Manager export server. Accounts in this group have Read and Change Attribute permissions for the LAN Manger export directory tree. If such a group exists, make sure it is named REP, prior to upgrading. This ensures that the restenv utility ports all import server accounts along with appropriate permissions to the Windows NT Server group Replicator.

You are logged on to your LAN Manager server as an administrator.

If the file replication service is running, you'll need to get the latest update. Before starting the upgrade process, initiate a file replication synchronization.

You have removed cartridges from any CD-ROM drives connected to your server running LAN Manager. Leaving cartridges in place increases upgrade time and causes the utilities to generate error messages.


Installing the Upgrade Utilities
Preparing to Upgrade 	13 of 13

Installing the Upgrade Utilities

The upgrade disks include a Setup program to install the upgrade software. Setup copies the upgrade software into an UPGRADE directory that it creates on a user specified drive.

Important

Utility programs and output files must reside in the same directory.

Prior to installing the upgrade utilities, please read the README.TXT file on your upgrade disk.

To run the upgrade utilities, you must log on with administrative privileges on the servers running LAN Manager and Windows NT Server.

To install the upgrade utilities on a server running LAN Manager

1.	On the Windows NT Server 3.5 CD-ROM disk, change to the directory \UPGRADE.LM2.

2.	Change to the directory that corresponds to the platform that you are upgrading to \ALPHA, \MIPS, or \X86.

If you are upgrading to an x86 computer without a CD-ROM drive, insert the floppy disk labeled "Upgrade Utilities Disk for LAN Manager for x86 Systems," and change to that drive.

3.	Type setup <drive:> where drive is the destination for the upgrade files. Note that this can be an existing network connection.

Setup decompresses files on the disk and places them in the UPGRADE directory that setup creates on the specified drive.

Now you are ready to run the upgrade programs. Please see Chapter 4, "Upgrading a LAN Manager Server."


Upgrading a LAN Manager Server
Chapter 4	1 of 19

Upgrading a LAN Manager Server

This chapter contains step-by-step instructions for upgrading a LAN Manager server to Windows NT.

Flowcharts for a high-level overview of the steps involved

Installing Windows NT Server: special considerations you'll need to follow

Backing up LAN Manager settings and files

Restoring settings under Windows NT Server

Before following these procedures, review the upgrade flowcharts in this chapter to gain an overall understanding of the upgrade process.

For each domain, start your upgrade with the LAN Manager primary domain controller. If you are upgrading to a clone, this first clone becomes the Windows NT primary domain controller. If you are upgrading in place, the LAN Manager computer becomes the primary domain controller in a new Windows NT domain. This domain can operate as a mixed domain as you gradually convert backup and member servers.

Note

Running the Upgrade Manager under LAN Manager does not alter system configuration or files. However, running the Upgrade Manager under Windows NT Server changes file permissions, user account information, and system configuration. You cannot easily reverse the changes.


Upgrade Flowcharts
Upgrading a LAN Manager Server	2 of 19

Upgrade Flowcharts

The Upgrade process, while straightforward, requires several steps, based on the configuration of your network and the various Windows NT options or services you choose to install.


Upgrading to a Clone
Upgrading a LAN Manager Server	3 of 19

Upgrade Flowcharts

Upgrading to a Clone

This flowchart assumes that you are upgrading a LAN Manager primary domain controller to a clone computer. In this scenario, you can leave your original domain in place and create an evaluation domain.

Upgrading to a Clone


Flowchart: Upgrading In Place
Upgrading a LAN Manager Server	4 of 19

Upgrade Flowcharts

Flowchart: Upgrading In Place

In this scenario, you are upgrading a LAN Manager primary domain controller in place, and in the process creating a new Windows NT domain.

If you are upgrading backup and member servers, follow the same steps but do not restore user accounts.

Upgrading In Place

Upgrading in Place


Backing Up LAN Manager Settings and Files
Upgrading a LAN Manager Server	5 of 19

Backing Up LAN Manager Settings and Files

In the first part of the upgrade, you use the Upgrade Manager program to back up user accounts, permissions, program schedule information, environment settings, and data files on your LAN Manager server.

If you are backing up to another server or copying files to a clone, remember to create network connections to other servers prior to running the Upgrade Manager. When creating connections, specify drive letters; UNC names are not supported. It is recommended that you connect to root shares (C$, D$, and so on) and create one connection for each partition on your LAN Manager server.

Important

If you are copying LAN Manager files to a clone computer, make sure to copy the LAN Manager root directory and any subdirectories that may contain replication and logon script paths. The restenv utility uses these directories to restore logon script and replication paths. If these directories are not copied, you will have to restore files manually after the upgrade.

To run the Upgrade Manager or any of the individual utilities, you must log on with administrative privileges.

To back up LAN Manager settings and files

1.	To start the Upgrade Manager, type lmupmgr from the UPGRADE directory and then press ENTER.

2.	The Upgrade Manager asks if you want to pause the server and delete all sessions. This step prevents network users from changing user account and file information during the upgrade process. Unless you are upgrading for evaluation purposes only, it is highly recommended that you choose Yes to pause the server.

If you choose Yes, the Upgrade Manager also stops the MACFILE service, if present. This step flushes MACFILE buffers so that the upgrade records the correct MACFILE parameters. Upon exit, the Upgrade Manager offers to restart server and MACFILE services.

3.	From the Main menu, select Back Up User Accounts And Permissions and then Back Up Permissions On All Drives.

The Upgrade Manager runs the backacc utility to preserve LAN Manager permissions and user account information. Backacc should always be the first utility in the upgrade process.

Backacc copies the user accounts database to the file NETACC.BKP. By default, it copies permissions for files and directories to ACLBAKdrive.ACL, where drive is the partition you want to back up. Run backacc once for each partition you want to upgrade. Output files are written to the LANMAN\ACCOUNTS directory. (These files are then copied to the UPGRADE directory when you back up your environment settings.)

4.	From the Main menu, select Back Up Scheduled Commands and then Back Up Commands.

The Upgrade Manager runs the backat utility to read SCHED.LOG and write scheduled commands to a batch file called RESTAT.CMD. When run under Windows NT Server, RESTAT.CMD reinstates command and program schedules by writing information into the Registry.

5.	From the Main menu, select Back Up The LAN Manager Environment and then Back Up Environment.

The Upgrade Manager captures configuration settings on the LAN Manager server by running the backenv utility. Information collected by backenv is used by the restenv utility to recreate the environment settings under Windows NT Server.

When initiated by the Upgrade Manager, backenv reads the LAN Manager configuration files PROTOCOL.INI and LANMAN.INI and other information obtained through LAN Manager API calls, and then generates three output files:

An environment backup file (LMBAKENV.DAT) that is used to restore settings under Windows NT Server

A text file (ADVISORY.TXT) that contains recommendations for the Windows NT installation process, such as network card settings, required memory, and so on

A text file (OS2.UIF) that records hardware settings and is useful for troubleshooting

Backenv copies LAN Manager configuration files, including LANMAN.INI, LMUSER.INI, PROTOCOL.INI, and SETUP.INI, to the UPGRADE directory, in case you need to refer to them later. It also copies the output files from the backacc utility (NETACC.BKP and ACLBAKdrive.ACL) from \LANMAN\ACCOUNTS into the UPGRADE directory. These files are required input for the utilities that restore accounts on the server running Windows NT Server.

6.	To verify that the upgrade was performed successfully, from the Main menu, select Record File Security And Properties and then select Record Properties For All Drives.

Note that this step can take some time depending on the number of files on your drives and system processor speed.

The Upgrade Manager runs the acllist utility to record file permissions and properties. Acllist records information such as a file's time stamp, size, and security settings. Output from acllist is saved in a file called ACLLISTdrive.DAT, which is used later by the aclcomp utility to verify that file integrity and security settings are maintained through the upgrade. All inconsistencies are flagged in a report (ACLCOMP.LOG) created by aclcomp.

7.	From the Main menu, select Back Up Files and then select either Back Up Files With Sytos Plus (versions 1.11 or 1.34) or Back Up Files To Another Server.

Important

Make sure you back up your LAN Manager server as soon as possible after running the backacc and backenv utilities. This minimizes the chances of a discrepancy between configuration settings and the files you restore on the server running Windows NT Server.

If you are upgrading to a clone computer, you can copy files directly to that computer. If you are performing an in place upgrade, you can copy files to another LAN Manager server with adequate space.

When provided with an existing drive and path, such as H:\, the Upgrade Manager checks that drive for available space. If space is adequate, it copies files from a user-specified drive or directory on the LAN Manager server to the network connection represented by the drive letter.

Upgrade Manager gives you the choice of backing up single drives or directories. It also provides an option for you to set a new destination directory. For example, if you have specified H:\ as your destination drive, you could enter H:\PROGRAMS as the target directory. The PROGRAMS directory should already exist on the destination drive.

If you are backing up files on a clone server, you must maintain consistency between the drive letters on the LAN Manager server and the clone server running Windows NT Server in order to preserve your security settings. For example:

LAN Manager		Window NT Server	Comments
drive d:\		d:\	Security can be restored.
drive d:\		e:\	Security can be restored with aclconv command line options.
drive d:\		d:\subdir\	Security cannot be restored.
The Upgrade Manager copies files using the hcopy utility with the following options: /f to ensure that the destination partition supports extended attributes, /e to copy empty directories, /v to verify transfer, and /s to copy subdirectories.

Important

LAN Manager Services for Macintosh requires that files have extended attributes. If you are upgrading to Windows NT Services for Macintosh, make sure to preserve these attributes. Using the hcopy utility with the /f option to copy files from the LAN Manager server ensures that the destination volume supports extended attributes.

8.	From the Main menu, select Exit and then when prompted, select Back Up Upgrade Manager Files. If you are upgrading to a clone, copy files to that server.

9.	Select View or Print ADVISORY.TXT from the Exit Upgrade Manager menu.

The advisory file provides a record of your original LAN Manager configuration. It also contains advice on installing Windows NT Server.

10.	Choose Exit to exit the Upgrade Manager.

Licensing for a Clone Upgrade

After you complete a clone upgrade, your license for a LAN Manager server is effectively transferred to the computer now running Windows NT Server. You will need to disconnect your LAN Manager server from the network or change it to a workstation. See your licensing agreement for more details.


Installing Windows NT Server
Upgrading a LAN Manager Server	6 of 19

Installing Windows NT Server

In this part of the upgrade, you use the Windows NT Setup program to install Windows NT Server. Prior to running Setup, review the following flowchart for Windows NT Server installation.

Installation Flowchart

This flowchart walks you through Windows NT Setup, with particular attention to the installation of network software. When Setup displays the Network Settings dialog box, install the required software as shown in the flowchart.

Installing Windows NT Server

Installing Windows NT Server

Installing Windows NT Server

Planning Disk Partitions

Prior to running Setup, decide on partition configuration (if upgrading to a clone) and where you want to install the operating system.

Changing Partition Configuration

Windows NT Services for Macintosh requires that the same volume structure exist on the server running Windows NT Server as existed on the original LAN Manager server. For example, if the Macintosh volume SHIPPING exists on drive D of the LAN Manager server, it must also exist on drive D of the computer running Windows NT Server. If you are upgrading Services for Macintosh volumes, do not change the drive letters assigned to partitions as SFM will then not be able to be upgraded.

Note that while changing partitions is supported, it has consequences for upgrading file permissions. For example, if you copy files from LAN Manager drive D to Windows NT Server drive E, you must remember to specify a new destination drive letter when running the aclconv utility, as the Upgrade does not perform this step automatically.

If desired, after completing the installation of Windows NT Server, you can change drive letter designations using the Disk Administrator tool. If you decide to change partition drive letters, make sure letters assigned to Windows NT Server partitions do not match the drive letters assigned to shared directories or persistent connections. Otherwise, when you restore LAN Manager environment settings, shares and connections with conflicting designators will not be restored. For example, if the connection F: \\TESTSVR\PUBLIC exists under LAN Manager, the upgrade will not reinstate it if a drive F already exists under the server running Windows NT Server.

Repartitioning Using Windows NT Setup

If you do not have enough space to upgrade in place, you may be able to repartition your disk in order to create enough space. You can use Windows NT Setup to create and delete partitions, and to reformat them as NTFS or HPFS. After partitioning your disk, you can continue with Windows NT Setup or you can exit. For instructions on repartitioning your disk, see the Windows NT Server Installation Guide.

Choosing a Partition for Windows NT Server

You must install Windows NT Server on a partition with enough additional space to hold the upgrade utilities and output files (approximately 3 MB). For example, if LAN Manager and OS/2 are installed on a single C partition of approximately 30 MB, this partition is not large enough to accommodate Windows NT Server. (See "Upgrade Space Requirements," in Chapter 3, "Preparing to Upgrade.")

If you have OS/2 Boot Manager installed on your computer and want to continue using it, you need to install Windows NT Server on a partition different from that used by OS/2. However, after you convert partitions to NTFS, OS/2 will not recognize files on these partitions.

Running Windows NT Setup

Start Windows NT Setup according to instructions in the Windows NT Server Installation Guide. Use the following guidelines to make decisions during the installation process.

Choose Custom Setup

Choose Custom Setup to install Windows NT Server. This enables you to install more than one network adapter card as well as additional network software such as TCP/IP and Windows NT Services for Macintosh.

Choose a partition for Windows NT Server

Window NT Setup asks you to choose one of the following options:

Install Windows NT Server on an existing partition. Use this option if you are installing in place.

Create or delete disk partitions, and then select the partition that will contain the Windows NT Server system files. Use this option for clone upgrades or if you are repartitioning your disk.

Convert to NTFS

After you choose the partition on which to install Windows NT, Setup asks whether you want to convert that partition to the Windows NT file system (NTFS) or keep the existing file system.

To take full advantage of the security features of Windows NT, you must choose NTFS for the partition containing the operating system and for partitions that will contain secure files.

Important

When you install Windows NT Server on an NTFS partition, Windows NT Setup installs default security for all operating system files and directories. When you install Windows NT on a FAT partition and then convert it after installation to NTFS, default security is not applied.

Choose a computer name

If you are upgrading a server in place, retain its name under Windows NT.

If you are upgrading to another computer, give the second computer a unique temporary name (for example, CLONE1) until you are ready to change the name of the LAN Manager server. This permits you to copy files from the LAN Manager server to the Windows NT Server clone.

Install a printer

The upgrade utilities do not transfer printer information from your LAN Manager server to Windows NT Server. However, the advisory file created by the backenv utility (ADVISORY.TXT) documents all print queue configurations and printer names. Use this information if you install a printer during Windows NT Server installation, or to create additional printers after installation. (Windows NT Setup only installs one printer during Setup.)

Install network adapter cards and software

Custom Setup will detect one network adapter card and install it and then allow you to install additional cards. If you have more than one card, install it manually during Setup.

To communicate on the network, all domain controllers and servers must be running the same network protocol. Custom Setup automatically installs NetBEUI, and then provides you with the option of installing additional protocols and network software, including TCP/IP, Services for Macintosh, Remote Access Service, and SNMP. Install all required software during Setup. (See the installation flowchart in this chapter for guidance on configuring additional software.)

If you install TCP/IP on a clone computer, use a temporary TCP/IP address. This enables both servers to exist on the network temporarily so you can copy data files to the clone.

Choose a domain name

If you are upgrading a primary domain controller, make the new server a primary domain controller in a new Windows NT Server domain. Use the existing LAN Manager domain name.

If you are upgrading a backup or member LAN Manager server, make the computer a server in an existing Windows NT Server domain.

If you are upgrading a primary domain controller to another computer, make the clone a primary domain controller in a temporary domain (for example, CLONEDOMAIN). Later, when you take the LAN Manager primary domain controller server offline, you can change the domain name to match the LAN Manager domain name.

Important

Changing domain names is not generally recommended. This case is an exception because there is only one computer in the domain (the clone Windows NT Server).

If you are upgrading a backup or member LAN Manager server to a clone, make the computer a server in an existing Windows NT Server domain.

After installing Windows NT Server, press CTRL+ALT+DEL to log on. Log on to the domain using your Administrator account.

After you have installed Windows NT Server, do not install large screen fonts on the computer running Windows NT Server until after you have completed your upgrade. Upgrade Manager will not run correctly.

Notes for Clone Upgrades

If you have installed Windows NT Server on a clone computer and intend to copy files to that computer, you need to create a user account that matches the administrative account on your LAN Manager server. For example, if you log on to LAN Manager as ADMIN with the password FRISBEE, create an account with the same user name and password under Windows NT Server.

Use the User Manager for Domains tool to add this account. Make the account a member of the Administrators group.

Also consider formatting additional drives to NTFS at this time. Although you can convert drives later using the Upgrade Manager, formatting is faster than conversion and has no disk space requirements. To format drives to NTFS, run the format command from the command prompt. Type format /? at the command prompt for syntax.


Flowchart: Merging a LAN Manager Domain into a Windows NT Server Domain
Upgrading a LAN Manager Server	7 of 19

Flowchart: Merging a LAN Manager Domain into a Windows NT Server Domain

This flowchart illustrates the following scenario for merging domains.

There are two domains on your network: WINSALES and LANSALES. WINSALES is a Windows NT Server domain that contains previously upgraded accounts. LANSALES is a LAN Manager domain that you intend to merge into the WINSALES domain. The process starts with an upgrade of the LANSALES primary domain controller to a clone server in the WINSALES domain. In this case, use the Express upgrade option and designate the userconv utility to map LANSALES accounts to existing accounts and local groups in WINSALES. If LAN Manager user accounts exist that do not map, you can run portuas from the command line for each unmapped account.

This example assumes that you will keep the original LANSALES domain up and running until you are satisfied that the upgrade worked successfully. When you are ready for the final upgrade, you should repeat the upgrade procedures to ensure capture of all account and file changes, and then take the LANSALES domain immediately offline.

Merging Domains

Merging Domains (con't)


Running LAN Manager Upgrade Manager
Upgrading a LAN Manager Server	8 of 19

Running LAN Manager Upgrade Manager

To start the Upgrade Manager, you must be logged on with administrative privileges.

To start the Upgrade Manager

Change to the UPGRADE directory, and then from the command line type lmupmgr.

At startup, the Upgrade Manager automatically prepares the LAN Manager server for upgrading as follows:

It verifies that the user has administrative privileges, and if not, it stops.

It checks LAN Manager and OS/2 version numbers. If the Upgrade Manager detects a version other than LAN Manager 2.1a or above, and OS/2 1.21 or 1.3, it stops.

If the Upgrade Manager detects OS/2 version 1.3, it runs the LAN Manager cleanup utility to move inactive OS/2 LADDR-specific components from the root directory to the \OS2\SUPPORT directory. This step ensures that the backenv utility registers only those adapters actually installed on the server.

It checks for local security. If present, the Upgrade Manager directs the user to disable it.

It prompts the user to pause the server, disconnect all sessions, and stop the MACFILE service (if present). The first two steps prevent network users from changing user account and file information during the upgrade process. Stopping the MACFILE service flushes MACFILE buffers so that the upgrade records correct parameters.

These steps are taken as a precaution; they are not absolute requirements for the upgrade.


Selecting Utilities
Upgrading a LAN Manager Server	9 of 19

Running LAN Manager Upgrade Manager

Selecting Utilities

Press ENTER at the initial screen to bring up the Main menu.

The Upgrade Manager will run all or a subset of the utilities for you without interruption, if you select Run All Utilities. Or, you can step through one utility at a time, starting with Back Up User Accounts And Permissions.

Although you can skip certain utilities, always run the utilities in the order presented by the Upgrade Manager program because many utilities rely on the existence of files created in previous steps.

Note that the Upgrade Manager marks completed steps with a asterisk (*). If a step is partially complete - you have backed up a portion of your disk, for example - the Upgrade Manager places a "p" for partial next to the step.


Running All Utilities
Upgrading a LAN Manager Server	10 of 19

Running LAN Manager Upgrade Manager

Running All Utilities

If you select Run All Utilities, you can configure the Upgrade Manager to run all or a subset of its utilities without pausing.

To configure Upgrade Manager tools

1.	Select Run All Utilities.

2.	Select or deselect the utilities you want to run by highlighting the utility and pressing ENTER.

3.	When you finish, choose Run Selected Utilities and press Enter.

If you run all utilities without pausing, the Upgrade Manager performs the following steps:

Backs up user accounts and permissions on all partitions.

Backs up scheduled commands to the restat.cmd file.

Backs up LAN Manager environment settings.

Records file security and properties for all partitions.

Prompts you to start Sytos Plus backup if it detects version 1.11 or 1.34 of Sytos on your disk. If Sytos is not installed, it prompts you to back up to a network connection.

To skip an upgrade step, highlight that step and press ENTER.


Upgrade Status Information
Upgrading a LAN Manager Server	11 of 19

Running LAN Manager Upgrade Manager

Upgrade Status Information

The Upgrade Manager displays status information, including error messages as you proceed. It also generates a log file (LMUPMGR.LOG) each time the program runs. Old log files are preserved by renaming them with different numerical suffixes (.001, .002, sequentially through .025).

If a failure occurs during Upgrade Manager operation, refer to Chapter 7, "Troubleshooting."


Running Windows NT Server Upgrade Manager
Upgrading a LAN Manager Server	12 of 19

Running Windows NT Server Upgrade Manager

To use the Windows NT Server Upgrade Manager, you must be logged on to a user account that is a member of the Administrators local group or the Domain Admins global group.

To start the Upgrade Manager

Change to the UPGRADE directory, and then from the command line type wntupmgr.

The Windows NT Server Upgrade Manager dialog box appears. You can then choose between Express Upgrade and Custom Upgrade.

To start the Upgrade Manager and load a predefined upgrade configuration

Change to the UPGRADE directory, and then from the command line type wntupmgr filename.ext.

Upgrade Manager goes directly to the Custom Upgrade dialog box. The Upgrade Tool Schedule box lists the upgrade configuration as defined by the specified file.


Choosing Between Express and Custom Upgrade
Upgrading a LAN Manager Server	13 of 19

Running Windows NT Server Upgrade Manager

Choosing Between Express and Custom Upgrade

When performing an upgrade with Windows NT Server Upgrade Manager, you have the option of performing an Express upgrade or a Custom upgrade.

When performing an Express upgrade, the Upgrade Manager analyzes the results returned by the LAN Manager Upgrade Manager, determines the upgrade steps that should be performed, and then displays the appropriate tools, configured and arranged in the appropriate sequence.

When performing a Custom upgrade, you execute an upgrade that has been predefined in a configuration file. This might be the WNTUPMGR.INI file (the default configuration file), or another configuration file that you specify.

Important

We strongly recommend that you choose the Express upgrade option, as Custom assumes that you will do many tasks manually that would have been automatic under Express. Use Custom only if advised to do so by Microsoft Product Support or if you have special requirements. You should read and have a thorough understanding of everything in the Upgrade Guide.


Upgrade Tool Schedule
Upgrading a LAN Manager Server	14 of 19

Running Windows NT Server Upgrade Manager

Upgrade Tool Schedule

The Upgrade Tool Schedule displays the upgrade tools that will be run and lists them by the sequence in which they will be run. Colors indicate the status of each tool.

Gray text indicates a tool that has already run.

Blue text indicates a tool that is running; or a tool that, when the Start or Continue buttons are chosen, will be run first.

Black text indicates a tool that has not yet run.

When a question mark (?) appears as part of the text for a listed tool, that tool requires configuration before it is run. Usually, a drive letter must be specified in place of the variable (?).


Running Express Upgrade
Upgrading a LAN Manager Server	15 of 19

Running Windows NT Server Upgrade Manager

Running Express Upgrade

Express upgrade is the recommended method of upgrading. With Express Upgrade, the Upgrade Manager examines the output files in your Upgrade directory and determines what programs to run to complete the upgrade. For example, if it finds the file ACLBAKD.ACL and drive D is not an NTFS drive, it assumes you need to convert D to NTFS and then convert permissions for files on that drive.

The following table shows how conversion steps are scheduled for Express upgrade.

If Upgrade Manager finds		It schedules
ACLBAKdrive.ACL and drive is not NTFS		Convert drive partition to NTFS
LMBAKENV.DAT		Convert environment
NETACC.BKP		Restore user accounts
ACLBAKdrive.ACL		Restore permissions for drive
RESTAT.CMD		Restore commands
SFMCONV.RUN		Convert Macintosh volumes
ACLLISTdrive.DAT		Verify drive permissions
If you are satisfied with the Express Upgrade schedule, select Start. Otherwise, select Configure to modify the schedule. See "Configuring the Upgrade Schedule," later in this chapter for information on customizing upgrade steps. By default, Express upgrade pauses after each task is complete and waits for you to select Continue.

Note

For clone upgrades: if you have moved files to a different drive letter, you will need to edit the command line syntax of aclconv in order to correctly restore security. See Chapter 8, "Upgrade Utilities Reference."


Running Custom Upgrade
Upgrading a LAN Manager Server	16 of 19

Running Windows NT Server Upgrade Manager

Running Custom Upgrade

If you select Custom Upgrade, the Upgrade Manager reads the WNTUPMGR.INI file and displays upgrade steps in the Upgrade Tool Schedule window in the order found in the file. A question mark (?) in the text for an upgrade tool indicates that the tool requires configuration before it is run. In most cases, you must substitute a drive letter in place of the question mark.

Unlike an Express upgrade, a Custom upgrade does not attempt to configure upgrade steps for you. Prior to running a Custom upgrade, you must customize command lines and decide what utilities to add or remove, as described in the next section.

The following Custom upgrade steps require you to supply an appropriate drive letter or file name:

Convert partition to NTFS

Restore permissions for partition

Verify permissions for partition

After configuring a Custom upgrade, choose the Start button. By default, the Upgrade Manager is configured to pause after executing each utility. Choose the Continue button to run the next utility.


Configuring the Upgrade Schedule
Upgrading a LAN Manager Server	17 of 19

Running Windows NT Server Upgrade Manager

Configuring the Upgrade Schedule

If you are upgrading many identical servers, you can create a custom upgrade schedule and run it on each server. Create a custom schedule from an Express or Custom upgrade by selecting the Configure button and making configuration changes from within the Configure Tools window. Possible changes include:

Adding or removing utilities from the Upgrade Schedule box.

Changing the command line parameters for any of the utilities listed in the Upgrade Schedule box.

Configuring the Upgrade Manager to pause or reboot after a particular utility.

You can also create a Custom upgrade schedule by editing copies of the Upgrade Manager configuration files. For more information, see "Editing Configuration Files," later in this section.

The Configure Tools Window

The Configure Tools Window lists upgrade steps in two dialog boxes: the Available Utilities dialog box shows all possible steps; the Upgrade Schedule dialog box shows scheduled steps.

Optionally, you can modify the configuration of the upgrade schedule and the upgrade tools. This configuration can then be run immediately, saved for future use, or both.

To configure the upgrade tools

1.	Start Upgrade Manager, and then choose either the Express Upgrade button or the Custom Upgrade button.

2.	Choose the Configure button.

3.	To add an upgrade tool to the Upgrade Schedule, first select a tool from the list in the Upgrade Schedule (or, select the empty line below the lowest tool in the list).

The added tool will be inserted immediately above this selection.

4.	Select a tool from the list in the Available Utilities box, and choose the Insert button.

The tool from Available Utilities is added to the Upgrade Schedule.

5.	To remove an upgrade tool from the Upgrade Schedule, select a tool from the list in the Upgrade Schedule, and then choose the Remove button.

6.	To configure a scheduled upgrade tool, select a tool from the list in the Upgrade Schedule box, and then set the Upgrade Schedule Details options: edit the text in the Command Line box as necessary, and select or clear the Pause After Execution and Reboot After Execution options.

7.	Optionally, to save this configuration for future use, choose the Save As button and complete the Save As dialog box that appears.

8.	To complete the current upgrade using this configuration, choose the OK button, and then from the dialog box that reappears (as appropriate, the Express Upgrade or Custom Upgrade dialog box), choose the Start button.

Saving an Express or Custom Configuration

If you want to use a custom schedule for future upgrades, choose the Save As button from the Configure Tools windows and save the schedule using a unique filename (the file extension is unimportant). By default, the Upgrade Manager saves the files with an .INI suffix. To run a custom schedule, type wntupmgr <schedule name> from the command prompt.

Avoid overwriting the default Express and Custom upgrade files (WNTUPMGR.EXP and WNTUPMGR.INI, respectively).


Upgrade Status Information
Upgrading a LAN Manager Server	18 of 19

Running Windows NT Server Upgrade Manager

Upgrade Status Information

The Upgrade Manager displays status information, including error messages and start and stop times for each execution sequence. This information is also saved to a log file (WNTUPMGR.LOG). Old log files are preserved by renaming them using different numerical suffixes (.001, .002, and so on through .025).

In addition, the restenv, userconv, and aclcomp utilities generate their own log files, which contain status information. If you encounter an error, you might want to exit the Upgrade Manager, check various log files, correct the problem, and then restart the Upgrade Manager.

For help interpreting error messages in the log files, see Chapter 7, "Troubleshooting."


Restoring Settings on Windows NT Server
Upgrading a LAN Manager Server	19 of 19

Restoring Settings on Windows NT Server

In this part of the upgrade process, you restore user accounts, permissions, program schedule information, environment settings, and data files on your Windows NT Server. Prior to starting, make sure data files, including LAN Manager directories, are present on the server.

After starting the Windows NT Server Upgrade Manager, you have the option of choosing an Express or Custom upgrade. The Express option determines appropriate upgrade steps, while a Custom upgrade requires you to choose and configure upgrade steps. We recommend that you choose the Express upgrade, particularly if you are unfamiliar with the upgrade process.

The following procedures step through an Express upgrade. This procedure describes all possible steps; a typical upgrade requires a subset of these steps. (Recall that Express upgrade scans files in the UPGRADE directory to determine which upgrade steps are appropriate.)

To restore settings on Windows NT Server

1.	Select the command prompt icon from the Main menu. Start the Upgrade Manager by typing wntupmgr from the UPGRADE directory or the directory in which you have put upgrade executables and output files. (You must be logged on with administrative privileges.)

2.	Choose the Express Upgrade button.

Express upgrade creates the Upgrade Tool Schedule based on files in the UPGRADE directory.

Carefully examine the Upgrade Tool Schedule to make sure the upgrade steps are appropriate. In particular, check steps that specify drive letters. If there are steps you want to skip, select Configure and remove them from the Upgrade Schedule.

If during the upgrade you copied files to a new partition with a different drive identifier, you need to modify command line options for the following upgrade steps.

Upgrade step		Use the Configure Tools dialog box to
Convert drive: partition to NTFS		Specify the drive containing data files.
Convert permission for partition drive:		Specify the drive to which permissions are to be restored. (For example, if files are transferred from the C partition of the LAN Manager server to the D partition of the computer running Windows NT Server, the command line should read: aclconv /data:aclbakc.acl /newdrive:d: /log:aclbakd.log)
Verify drive: security		Specify the drive on which permissions are to be verified. (For example, if files are transferred from the C partition of the LAN Manager server to the D partition of the computer running Windows NT Server, the command line should read: aclcomp /a /dat: acllistc.dat /log:acllistd.log)
To modify a command option, select the Configure button and then highlight the appropriate command in the Upgrade Schedule dialog. Edit the Command line shown in the Upgrade Schedule Details dialog.

3.	From the Upgrade Tool Schedule, choose the Start button to Convert <drive> To NTFS.

If prompted to schedule the conversion the next time the system is rebooted, choose Yes. Note that converting multiple drives can require multiple reboots.

This option converts FAT and HPFS (including HPFS386) partitions to NTFS using the convert utility. Each partition that is to contain secure files must be formatted as NTFS.

4.	Choose the Continue button to execute Restore Environment.

This option restores environment parameters under Windows NT Server using the restenv utility.

Restenv reads the LMBAKENV.DAT file created by backenv and restores applicable settings under Windows NT Server. In the process, restenv generates a log file, RESTENV.LOG, that records upgrade changes. Restenv also indicates what settings it was unable to change and why.

5.	Choose the Continue button to execute Restore User Accounts.

This option uses the portuas utility to merge a LAN Manager user account database into an existing Windows NT Server security database by reading information directly from the LAN Manager NETACC.BKP file. Portuas also sets global group and user account information (such as passwords, minimum password age and length, logon script names, and so forth) to their LAN Manager values.

When a user or a group name in a LAN Manager domain matches a group name on the destination server or the domain name of the destination server, portuas prompts you to decide whether to change the conflicting name, leave it as is, or skip the name entirely. After you decide, the merge process continues with the remaining users or groups. If a LAN Manager user name matches an existing Windows NT user name, portuas replaces the Windows NT user account with the LAN Manager account.

6.	Choose the Continue button to execute Restore Permissions For Partition drive letter.

This option uses the aclconv utility to restore file and directory permissions under Windows NT Server.

Aclconv reads the file and directory permissions stored in ACLBAKdrive.ACL (created by the backacc utility) and then applies equivalent permissions (ACLs) to the files and directories on that drive. Because only NTFS supports the security features of Windows NT, aclconv can be run only on NTFS partitions.

Aclconv must be run once for each volume you are upgrading. During an Express upgrade, aclconv is run once for each input file (ACLBAKdrive.ACL) present in the UPGRADE directory. To run a Custom upgrade, you must specify input and log file names by selecting Configure and editing the following command line: aclconv /data:aclbakdrive.acl /log: aclbakdrive.log.

If drive identifiers have changed in the process of upgrading, you must specify a new drive by selecting Configure and entering a new destination drive in the command line (see step 2).

Aclconv permits merging files from two LAN Manager partitions onto one Windows NT volume. For more information, see "Aclconv" in Chapter 8, "Upgrade Utilities Reference."

7.	Choose the Continue button to execute Restore Scheduled Commands.

This option restores scheduled tasks (at commands) by running RESTAT.CMD, the command file created by running Back Up Scheduled Commands (backat) on the original LAN Manager server. If you created a command file with a different name, you need to select Configure and modify the command line accordingly.

8.	Choose the Continue button to execute Convert Macintosh Volumes.

The sfmconv utility transfers volumes to Windows NT Services for Macintosh, software that enables file and print sharing with Apple Macintosh workstations.

Sfmconv has the following requirements:

Files on the destination Windows NT Server retain extended attributes.

The Services for Macintosh volumes are the same on the LAN Manager and Windows NT Servers. Files on a C volume may not be copied to a D volume.

All volumes are NTFS. Before running sfmconv, run portuas and aclconv to upgrade the user account database and access permissions.

The file SVRAUTO.PRO exists. This file contains the location of sharepoints on the Windows NT Server.

The root directory for LAN Manager files (usually C:\LANMAN) is present on the Windows NT Server.

Sfmconv also writes out a file, sfmconv.dat, in the current directory. This file is for use by aclcomp; it indicates which files and directories are deleted, renamed, or changed in some way.

9.	Choose the Continue button to execute Verify drive letter Permissions.

This option runs the aclcomp utility, which reads the output of acllist (ACLLISTdrive.DAT) and flags any file information discrepancies.

The Express upgrade runs aclcomp once for each ACLLISTdrive.DAT file it detects in the UPGRADE directory.

If drive identifiers have changed in the process of upgrading, you must specify a new drive containing the files to be verified. See step 2 in this process for details.

For each directory and file, aclcomp reports on mismatches in the creation date and time, the last write data and time, the data checksum, file size, and file attributes. If file permissions are present, aclcomp reports on missing users and groups, and mismatches in their permissions for files and directories.

Notes for Clone Upgrades

If you have upgraded to a clone and the original LAN Manager server is offline, you now have the option of changing the clone domain and computer names to the original LAN Manager names.

To make changes to names

1.	Exit the Upgrade Manager and select the Network icon in Control Panel.

2.	From the Network Settings dialog box, choose the Domain Change button and type the name of the original LAN Manager domain.

3.	Choose the Computername Change button and type the name of the original LAN Manager server.

4.	Restart the computer.


Completing the Upgrade
Chapter 5	1 of 13

Completing the Upgrade

After running the upgrade utilities under Windows NT Server, check the log files generated by the restenv and aclcomp utilities. These log files provide status information on the upgrade. For example, RESTENV.LOG indicates if restenv was unable to restore a particular registry setting or sharename or if there is a discrepancy between the original LAN Manager protocol settings and those set under Windows NT Server. ACLCOMP.LOG entries indicate whether permissions were applied successfully.

This chapter describes some final steps to take to ensure that your new Windows NT Server computer and domain are fully functional.


Required Tasks
Completing the Upgrade	2 of 13

Required Tasks

The following sections list the tasks that you must complete to have a fully functioning server under Windows NT.


Restoring Replication and Logon Scripts
Completing the Upgrade	3 of 13

Required Tasks

Restoring Replication and Logon Scripts

To determine if replication and logon script paths are correctly restored, check the [Replicator] and [Netlogon] portions of RESTENV.LOG. The log file indicates where restenv expected to find replication and logon script directories and whether it was successful. If the account REP was created prior to the upgrade, then all replication paths should be correctly restored.

If you upgrade to a clone, you may have copied logon and replication directories to a new drive. In this case, restenv will not find these directories and you will have to restore them manually.

Make sure that permissions for logon scripts and replication directories are set so that the appropriate users have access to these directories.

After upgrading, logon scripts will be unavailable to users until user account replication occurs. You should force a synchronization before you begin adding new accounts.

To synchronize after upgrading

1.	Select the Windows NT Server primary domain controller from the list in the Server Manager window.

2.	From the Computer menu, choose Synchronize Entire Domain.

Conversion of Replication Paths

The way replication export and import paths are restored by the restenv utility depends on whether the LAN Manager export and import paths specified in LANMAN.INI were absolute or relative.

If a LAN Manager export or import path specified in LANMAN.INI was an absolute path (for example, if the export path was C:\EXPORT), restenv sets the Windows NT export or import path to that absolute path.

If a LAN Manager export or import path specified in LANMAN.INI was a relative path, restenv renames the Windows NT export or import subdirectory, adding the .BAK extension. Restenv then moves the old LAN Manager export or import subdirectories (including all their files and subdirectories) under the Windows NT export or import path.

For example, if the LAN Manager export path specified in LANMAN.INI was REPL\EXPORT (a relative path), restenv renames the Windows NT export subdirectory (for example, it might be C:\WINNT\SYSTEM32\REPL\EXPORT) by adding the .BAK extension (for example, it would become C:\WINNT\SYSTEM32\REPL\EXPORT.BAK).
Restenv would then move all the old LAN Manager export subdirectories under C:\WINNT\SYSTEM32\REPL\EXPORT.

After the upgrade is complete, the replication paths can be viewed or modified using Server Manager (or the Server option in Control Panel). Directories, subdirectories, and files can be moved or deleted using File Manager.

If an \EXPORT.BAK subdirectory was created, check it for subdirectories and files. You will probably want to move those back into the export path by moving them under the \EXPORT subdirectory. You can then delete the \EXPORT.BAK subdirectory.

If an \IMPORT.BAK subdirectory was created, you can optionally check it for subdirectories and files, and move them back into the import path by moving them under the \IMPORT subdirectory. However, this is not required, since if the replication export servers are properly set up, all export files will be replicated to the import directories. Once replication is functioning and all needed files are present in the import tree, you may want to delete the IMPORT.BAK directory.

Note

Unlike LAN Manager, where export servers replicate only those export subdirectories for which there is a matching first-level import subdirectory on the import server, when a Windows NT export server replicates to an import computer, it exports all its export subdirectories. If an equivalent first-level import subdirectory does not exist on an import computer, it is created.

Conversion of Logon Script Path

The way logon scripts are restored by the restenv utility depends on whether the LAN Manager logon script path specified in LANMAN.INI was an absolute or a relative path.

If the LAN Manager logon script path specified in LANMAN.INI was an absolute path (for example, C:\SCRIPTS), restenv changes the Windows NT logon script path and the Windows NT NETLOGON share from their defaults, and sets them to that absolute path.

If the LAN Manager logon script path specified in LANMAN.INI was a relative path, restenv renames the Windows NT logon scripts subdirectory, adding the .BAK extension. Restenv then moves the old LAN Manager logon scripts subdirectory (including all its files and subdirectories) to the Windows NT logon script path.

For example, if the LAN Manager logon script path specified in LANMAN.INI was REPL\EXPORT\SCRIPTS (a relative path), restenv renames the Windows NT logon scripts subdirectory (for example, it might be C:\WINNT\SYSTEM32\REPL\EXPORT\SCRIPTS) by adding the .BAK extension (for example, it would become C:\WINNT\SYSTEM32\REPL\EXPORT\SCRIPTS.BAK). Restenv would then move the old LAN Manager logon scripts subdirectory to C:\WINNT\SYSTEM32\REPL\EXPORT\SCRIPTS.

After the upgrade is complete, the logon script path can be viewed or modified using Server Manager (or the Server option in Control Panel). The assignment of logon scripts to individual user accounts can be viewed or modified using User Manager For Domains. Directories, subdirectories, and files can be moved or deleted using File Manager.

If a \SCRIPTS.BAK subdirectory was created, check it for logon scripts. If it contains logon scripts, you will probably want to move those logon scripts back into the logon script path by moving them to the \SCRIPTS subdirectory. You can then delete the \SCRIPTS.BAK subdirectory.

In most cases, one server in each domain should maintain a replication export subdirectory of logon scripts, and the other servers in that domain should import copies of that subdirectory. In this way, each server will have an identical local copy of all logon scripts for all domain users. Following are some related considerations:

You should consider logon scripts on a domain basis (rather than just on a per-computer basis). You should make sure all logon scripts for all domain user accounts are gathered in one replication export directory on one server, and are imported by all other servers. If necessary, copy or move files between servers until the export subdirectory contains a master copy of all logon scripts for that domain.

You will usually want a server's logon script path to be a subdirectory of its replication path. Therefore, if the LAN Manager logon script path was an absolute path and restenv (as described above) converted the Windows NT logon script path to that path, you may want to use File Manager to move that logon script directory and its files into the replication path (for example, to C:\WINNT\SYSTEM32\REPL\IMPORT\SCRIPTS).

After the directory is moved, you should then use Server Manager to reset the logon script path accordingly. After the logon script path is reset, you should use Server Manager to stop and restart the Net Logon service. This automatically assigns the NETLOGON share to the new logon script path and assigns it the appropriate permissions. (Alternately, after the logon script path is reset, you could shut down and then restart the computer. When the computer starts up, the Net Logon service starts and creates the NETLOGON share with the appropriate permissions.)

Note that for the server that exports the replicated logon scripts, the logon script path can be set to either the export subdirectory (for example, C:\WINNT\SYSTEM32\REPL\EXPORT\SCRIPTS), or, if the server replicates to itself, to the import subdirectory (for example, C:\WINNT\SYSTEM32\REPL\IMPORT\SCRIPTS). However, all other servers should have their logon script paths set to the import subdirectory.

Creation of RESTENV.DAT

If the replication paths and/or the logon script path are relative, then those directories and their files are relocated as described above. When this occurs, restenv creates the RESTENV.DAT file, which records this information and which is later used by aclcomp to verify proper ACL migration.

If both the replication path and the logon script path are absolute, they are treated as described above, and restenv does not create the RESTENV.DAT file.

Conversion of REPL.INI Replication Information

For a replication export server, the information contained in the [replicator] section of the LAN Manager REPL.INI file (extent = [tree | file], integrity = [tree | file]) is not converted to Windows NT settings. The Window NT replication subdirectories are initially set to the Windows NT replication defaults (Subtree = Yes, Stabilize = No).

After the upgrade is complete, the Stabilize and Subtree settings for each first-level export subdirectory can be viewed or modified using Server Manager (or the Server option in Control Panel). Any REPL.INI files in the first-level export subdirectories should be deleted using File Manager.

Conversion of USERLOCK Files

LAN Manager USERLOCK files are not converted to locks on Window NT subdirectories. All Windows NT replication subdirectories (both export and import) are initially set to the Windows NT replication default (Locks=0).

After the upgrade is complete, the locks placed on each first-level export or import subdirectory can be viewed or modified using Server Manager (or the Server option in Control Panel). Any USERLOCK files in the first-level export subdirectories should be deleted using File Manager.

Conversion of Signal Files

With LAN Manager, the Replicator service indicates the status of import subdirectories by placing a signal file in each first-level import subdirectory. With computers running Windows NT Server and Windows NT Workstation, the replication status of each first-level import subdirectory is displayed in Server Manager's Manage Imported Directories dialog box.

After a server has been upgraded, the LAN Manager signal files are ignored. They do not determine the import replication status displayed by Windows NT.

After the upgrade is complete, the status of each first-level import subdirectory can be viewed using Server Manager (or the Server option in Control Panel). Any signal files (OK.RP$, NO_MASTR.RP$, or NO_SYNC.RP$) in the first-level import subdirectories should be deleted using File Manager.


Preparing to Operate a Mixed Domain
Completing the Upgrade	4 of 13

Required Tasks

Preparing to Operate a Mixed Domain

If you are operating a mixed domain that contains both Windows NT Server computers and LAN Manager servers, there are some steps required to make all resources available to everyone on the network:

Perform an audit of the SERVERS group. This should be done before an upgrade, see Chapter 3, "Preparing to Upgrade."

Create local accounts for users outside a mixed domain who must access LAN Manager servers in that domain.

Create local accounts for users from other untrusted Windows NT Server domains, or other LAN Manager domains, who must access resources in a Windows NT domain.

Place Windows NT Server local accounts in the appropriate global groups.

Creating Local Accounts

To create a new local account

1.	Choose User Manager For Domains from the Administrative Tools group.

2.	From the User menu, choose New User.

3.	In the Username box, type a unique user name of up to 20 characters.

4.	In the Full Name box, type the user's complete name.

5.	In the Description box, type a description of the user or the user account.

6.	In both the Password and Confirm Password boxes, type a password of up to 14 characters.

7.	Select the Account button and then choose Local Account.

To place local accounts in appropriate global groups

1.	Choose User Manager For Domains from the Administrative Tools group.

2.	Double-click the user account name and then choose the Groups button in the User properties dialog box.

3.	Add the user to the appropriate global group.


Removing Server Accounts
Completing the Upgrade	5 of 13

Required Tasks

Removing Server Accounts

If you upgraded to an evaluation domain, and left the original LAN Manager domain intact, make sure to remove LAN Manager server accounts from the evaluation domain. These duplicate accounts can interfere with account replication in the original domain.

To remove LAN Manager server accounts

1.	Log on to the Windows NT Server evaluation domain.

2.	Choose Server Manager from the Administrative Tools group.

3.	Highlight the LAN Manager server account you want to remove.

4.	From the Computer menu, choose Remove From Domain.


Adding LAN Manager Servers to a Windows NT Server domain
Completing the Upgrade	6 of 13

Required Tasks

Adding LAN Manager Servers to a Windows NT Server domain

To add a LAN Manager backup or member server to an existing Windows NT Server domain

1.	Use the LAN Manager Net Admin tool to demote the server to backup or member server, if it is not one already. Use the Setup program to rename it, if it does not have a unique computer name, and give it the Windows NT Server domain name.

2.	Log on to a Windows NT Server in the domain you want to join.

3.	Choose User Manager For Domains from the Administrative Tools group.

4.	Create a new user account for the LAN Manager server.

5.	Make the LAN Manager server a member of the global group SERVERS. If the SERVERS group does not exist, create it.

6.	Check to see that the LAN Manager server appears in the Server Manager dialog box.

7.	Connect the LAN Manager server to your network.


Recommended Tasks
Completing the Upgrade	7 of 13

Recommended Tasks

The following sections list optional tasks that you may want to perform, depending on your preferences and network configuration.


Checking for Duplicate Server Accounts
Completing the Upgrade	8 of 13

Recommended Tasks

Checking for Duplicate Server Accounts

If duplicate server accounts exist in different domains, replication and trust relationships may function incorrectly. This situation can also cause the Net Logon service to fail in a LAN Manager domain.

The following circumstances can result in the creation of duplicate accounts:

Upgrading a LAN Manager PDC to a Windows NT Server clone and leaving the original LAN Manager domain intact. In this scenario, portuas creates computer accounts on the clone for each of the LAN Manager servers in the original Servers group. Thus, server accounts exist in both domains. Typically, this situation prevents LAN Manager users from logging on.

Using Server Manager to create an account for a computer that already exists in another domain. For example, if you add the computer account \\CHEETAH to a Windows NT domain controller, and \\CHEETAH already exists in another domain, you will have problems setting up a trust relationship between the two domains.

To rectify this problem, use User Manager For Domains to delete accounts for LAN Manager SERVERS that exist in another domain.


Creating Printers
Completing the Upgrade	9 of 13

Recommended Tasks

Creating Printers

The ADVISORY.TXT file created by the backenv utility records printer and print queue settings on the source LAN Manager server. Use this file to help you set up printers on Windows NT Server computers. Use the Windows NT Print Manager tool to create and share printers.

For instructions on setting up a printer, see the Windows NT Server Network Operations Quick Reference.


Performing a Post-Upgrade Backup
Completing the Upgrade	10 of 13

Recommended Tasks

Performing a Post-Upgrade Backup

As soon as you've completed your upgrade, you should conduct a complete backup of the Windows NT server and adhere to a regular backup schedule thereafter. The upgrade resets all archive bits on files and directories, so that incremental backups will not be possible again until you have performed a full backup.


Removing Unnecessary Files and Directories
Completing the Upgrade	11 of 13

Recommended Tasks

Removing Unnecessary Files and Directories

After completing the upgrade, you can create extra space by removing the upgrade utilities and their output files, and in the case of an in place upgrade, OS/2 and LAN Manager system files, the OS/2 swap file, and unnecessary LAN Manager directories. However, be careful about removing the following directories:

LANMAN\ACCOUNTS\USERDIRS and LANMAN\ACCOUNTS\USERDIRS\SCRIPTS. These directories are used by Windows NT Server for home directories and scripts in order to use the existing LAN Manager configuration. If these directories are referenced in logon script paths, be sure to retain them.

lanman\logs, if you want to keep the error, message, or schedule logs.

LANMAN\RPL, if you plan to upgrade to Windows Remoteboot service.

lanman\repl, or wherever replicated directories reside.


Re-establishing Audit Settings
Completing the Upgrade	12 of 13

Recommended Tasks

Re-establishing Audit Settings

Audit settings are not ported as part of the upgrade. To restore these settings under Windows NT, manually configure audit parameters for each resource previously audited under LAN Manager. Then, specify "Everyone." To set up auditing, go to File Manager, and from the Security menu, choose Auditing.

Note that if auditing is enabled for LAN Manager, the aclcomp utility notes which LAN Manager files and directories were audited in the file ACLCOMP.LOG.


Testing the UPS Command File
Completing the Upgrade	13 of 13

Recommended Tasks

Testing the UPS Command File

If a UPS command file exists under LAN Manager, the backenv utility copies it into the UPGRADE directory. Restenv copies it to the \WINNT\SYSTEM32 directory. Before relying on your UPS configuration, test the command file to make sure that it works under Windows NT Server.

Hint

In most cases, you can use the same cable to connect UPS to a clone running Windows NT, but verify this with your UPS manufacturer.


Upgrading to a Trusted Domain Model
Chapter 6	1 of 14

Upgrading to a Trusted Domain Model

Windows NT Server enables you to use domains and trust relationships to centralize administration. With a trust relationship, servers in one domain recognize and allow access to accounts from another domain. If you design your network with domains and trust relationships in mind, you need to create only one account for each user, and that account can be used to give the user access to network resources. Trust relationships significantly reduce administrative effort and network management.

To help you implement a trusted domain model, the upgrade includes a utility to map LAN Manager user accounts to existing Windows NT Server accounts in a local or trusted domain. The userconv utility includes a graphical user interface that provides for:

Automatic mapping of identical usernames from a LAN Manager domain to a trusted Windows NT Server domain.

Manual mapping of user accounts that are not identical.

Creation of local groups consisting of users from trusted domains.

This chapter discusses concepts related to the trusted domain models and then describes how to use the userconv utility to upgrade to that model. Before upgrading to a trusted domain model, you need to understand the problems that the userconv utility solves.


Concepts to Understand
Upgrading to a Trusted Domain Model	2 of 14

Concepts to Understand

Depending on the size of your organization, you may decide to implement a master domain - a domain that contains all the user accounts and global groups on the network, or you may decide to implement a complete trust model in which user accounts are managed in each domain. In any trusted domain model, prior to establishing a trust relationship between two Windows NT Server domains that have been upgraded from LAN Manager, make sure you are familiar with the concepts discussed in this section.


User Accounts, SIDs, and Security
Upgrading to a Trusted Domain Model	3 of 14

Concepts to Understand

User Accounts, SIDs, and Security

Under Windows NT and LAN Manager, an administrator creates user accounts by assigning usernames to each account. In addition, Windows NT generates a security identifier (SID) for each new user account. Each user account SID uniquely identifies the user, regardless of when or where the account was created.

The underlying operating system always uses SIDs when referencing users. When a user is granted or denied access to a resource such as a file, the SID of the user's account is used instead of the username. This enables a system administrator to change the username of an account without changing permissions on resources. The illustrations in this chapter use SIDs and usernames interchangeably for clarity.

Each computer running Windows NT Workstation or Windows NT Server contains a SAM (security accounts manager) database. This database stores the information required to authenticate users and provides users' SIDs to the Window NT security system when the user logs on. The authentication process extends from a single Windows NT workstation (that may be a member of a domain), to a Windows NT Server domain, to a Windows NT Server trusted domain model. The same view of security can be applied in all three cases.

The use of SIDs by Windows NT has the following implications:

When a user account is deleted, it cannot be re-created to retain the same access to resources. For example, you create a user account with a username of johnh and give it permissions to resources. If you subsequently delete the user account, johnh can no longer access the resources even if another account is created. This is because the second user account has a different SID.

A domain user account can be used to assign access permissions in any other domain that trusts the local domain. Johnh can have an account in the Engineering domain and another account in the Sales domain. If the Sales domain trusts the Engineering domain, access permissions can be assigned to johnh from Engineering to resources in the Sales domain while also specifying different access permissions for johnh from Sales. Creating multiple accounts for a user is not recommended if trust relationships exist.

Understanding Account Types

There are two types of Windows NT accounts: a domain account and a local workstation account. Both types of accounts are accessible from computers running Windows NT Workstation. Computers running Windows NT Server, however, do not maintain local accounts - users logging on at a server must use their domain account. When you upgrade a LAN Manager server to Windows NT Server, all LAN Manager accounts become Windows NT Server domain accounts.

Workstation Accounts

Workstation accounts are only valid locally on the Windows NT Workstation computer where they were created. Control over these accounts belongs to users who have administrative privileges on the Windows NT computer. Every workstation has a built-in Administrator account for administering the computer. In some organizations, the primary user of a Windows NT computer will be expected to use that account to administer the user's own computer. In other organizations, the Domain Administrators global group is placed in the Administrators local group of each workstation in the domain. This makes it possible for the network domain administrators to administer the workstations that belong to their domain instead of relying on the computer's primary user to manage the system.

Apart from logging on with the Administrator account, a workstation user usually logs on to a Windows NT Workstation computer using a domain account. A Windows NT computer that belongs to a domain rarely requires workstation accounts for individual users. Most often, such accounts are created in unusual circumstances to allow network users without domain accounts to use shared resources on the workstation. For example, a worker from a different part of the organization is temporarily assigned to a project with your group, but that worker does not have an account in your domain. Rather than have a domain account created for the worker, you can create an account for the worker on your workstation so the worker can use its files and printers.

When you log on with a workstation account, you log on only at the workstation that stores the account. For example, assume John Hampton has a local account (johnh) on a Windows NT computer named Cheetah. To log on to this account, John Hampton enters "johnh" in the Welcome dialog box on Cheetah. He then chooses Cheetah in the From box, and enters the correct password. John Hampton's SID is retrieved from the SAM database on the Cheetah workstation as part of the authentication process. The security system on Cheetah uses this SID to perform access validation whenever johnh attempts to use local resources. However, other computers cannot use this SID when johnh attempts to use resources elsewhere on the network.

In the following illustration, the account johnh has a SID of XYZ.

Domain Accounts

A user can log on to his or her Windows NT Server domain account from any computer in the domain. This is similar to the way LAN Manager works.

A user logs on to a domain by entering a username, selecting a domain, and entering the correct password from a client computer on the domain. The user is authenticated by a computer running Windows NT Server in the domain rather than by the computer that the user logs on from. The user's SID comes from the SAM database on a computer running Windows NT Server in the domain.

The domain account can be used on any Windows NT computer to grant or deny access to resources. The following illustration shows what happens when John Hampton logs on to the Engineering domain using the johnh domain account. Note that johnh from Engineering has a different SID than the local johnh account on the workstation Cheetah, even though the usernames are the same.


Single Network Logon
Upgrading to a Trusted Domain Model	4 of 14

Concepts to Understand

Single Network Logon

Single network logon is a feature of Windows NT Server that allows users in an organization to have a single user account and to be able to log on from any computer in the organization.

Under LAN Manager, the largest administrative component is the domain. A user requires a separate user account in each LAN Manager domain she or he needs to access. Thus, a user might have three accounts: johnh, johnhampton, and johnha for three different domains.

Under Windows NT Server, the largest administrative component extends beyond a single domain to an entire network consisting of hundreds of domains. Domains are no longer independent entities; they can now be linked by trust relationships, which permit single network logon access to all domains.

The following example explains the use of trust relationships to achieve single network logon. Assume you must upgrade three LAN Manager domains: Engineering, Sales, and MIS (management information systems). The MIS domain is the logical choice to upgrade first. Create a unique user account in the MIS domain for each user in the organization. This makes MIS the "master" domain.

Next, upgrade the Engineering and Sales domains and create a trust relationship between Engineering and MIS, and Sales and MIS. Single network logon now exists in the organization; no other user accounts are necessary. A user can log on from any workstation on the network (regardless of which domain the workstation belongs to) by entering his or her unique MIS domain username from the MIS domain with the correct password.

Account Authentication

In the previous example, when a user logs on from a computer in the Engineering domain to an account in the MIS domain, the authentication is performed by the MIS domain. The MIS domain provides the user's SID to the Engineering domain, which in turn is provided to the Windows NT computer that the user is logging on from. It is important to understand that once a trust relationship is established between the Engineering domain and the MIS domain, it is not necessary to have user accounts in the Engineering domain.

In the following illustration, johnh is logging on to his account in the MIS domain. This is possible because the Engineering domain that John is logging on from trusts the MIS domain.

Using Master Domains

LAN Manager domains can be upgraded to Windows NT Server domains and trust relationships can be established ad hoc. However, to implement single network logon, a master domain must be selected as the trusted domain where all accounts are defined. All other domains (or second-tier domains) can then trust the master domain. For very large organizations, multiple master domains may be required to distribute administrative responsibilities. Two-way trust relationships must be established between all master domains, and trust relationships must be established between all second-tier domains and each master domain in order to achieve single network logon.

In the following example, MIS1 and MIS2 are master domains and the Engineering, Sales, and Manufacturing domains are second-tier domains that trust each master domain.


Using Local and Global Groups
Upgrading to a Trusted Domain Model	5 of 14

Concepts to Understand

Using Local and Global Groups

Local and global groups simplify user management when used in combination with a master domain model. The advantage of global groups is that they can be used by more than one domain, and control of the group resides in the domain it was created in. For example, if the Engineering and Sales domains trust the MIS domain (the master domain), a global group defined in the MIS domain can be used by both the Engineering and Sales domains to assign permissions.

The advantage of local groups is that they offer flexibility for second-tier domains because they can contain users and global groups from other domains. Local and global groups also have SIDs associated with them, which are used when assigning permissions. The following examples use group names for simplification.

In the following example, the MIS domain is responsible for maintaining the global group Account Managers. The Account Managers group can be assigned permissions for files in the Engineering and Sales domains.

Consider the following example, where the Sales domain needs to assign permissions to the Account Managers group as well as to johnh. In the Sales domain, a printer exists that only Account Managers and johnh are given access to. A local group called Sales Printer Group has been created in the Sales domain, which consists of Account Managers and johnh. The Sales Printer Group can then be given access to the printer.

The Sales Printer Group local group in this example shows how a second-tier domain can use local groups to maintain a level of autonomy from the master domain. This is advantageous for large organizations that are too difficult for a single administrator in the master domain to administer, or where there are so many second-tier domains that it would be difficult for the administrator of a master domain to meet the needs of all second-tier domains.


Mapping LAN Manager User Accounts
Upgrading to a Trusted Domain Model	6 of 14

Mapping LAN Manager User Accounts

Mapping a LAN Manager account is the process of associating an account that existed in a LAN Manager domain to an account that exists in a local or a trusted Windows NT Server domain. The goal of the mapping process is to allow LAN Manager users to take advantage of single network logon while maintaining access permissions to resources.

Mapping accounts allows duplicate accounts from multiple domains to be combined and also allows user accounts to be centralized in a single domain to simplify administration. Mapping an account does not create a new account; instead, permissions on files are replaced with the SID of a trusted domain account. In most cases, it is not necessary to restore accounts on LAN Manager domains that are being upgraded. It is only necessary to restore accounts (or create new accounts) on domains that will maintain user accounts, such as a master domain.


Single Account Mapping
Upgrading to a Trusted Domain Model	7 of 14

Mapping LAN Manager User Accounts

Single Account Mapping

Assume a network has three LAN Manager domains: MIS, Engineering, and Sales. An account with the username of johnhampton exists in the Engineering domain. Once the MIS primary domain controller is upgraded to Windows NT Server, unique user accounts are created in the MIS domain including an account johnh for the user John Hampton. When the Engineering domain's primary domain controller is upgraded to Windows NT Server, the account johnhampton is not upgraded. Instead, a trust relationship is established in which the Engineering domain trusts the MIS domain. The user account johnhampton is not necessary because the user account johnh has access to both the MIS and Engineering domains.

Consider what needs to happen to allow the account johnh in the MIS domain to take the place of the old LAN Manager account on the Engineering domain called johnhampton. First, the SID of johnh needs to be retrieved from the MIS domain. Second, johnh from MIS needs to be given access to all resources that johnhampton had in the Engineering domain. This requires that all the access permissions that johnhampton had before upgrading the Engineering domain be determined so that the SID of johnh can be used to replace all permissions on files and resources for johnhampton.


Mapping Multiple Accounts into One
Upgrading to a Trusted Domain Model	8 of 14

Mapping LAN Manager User Accounts

Mapping Multiple Accounts into One

You can also use the upgrade to combine multiple user accounts from many domains into a single user account. For example, assume that John Hampton had another account in the Sales domain with the username johnha. When the Sales domain is upgraded to Windows NT Server, the account johnha should be mapped to the MIS domain account johnh (an account which has already been mapped to the LAN Manager user account johnhampton). John Hampton could then log on to the network using the single username of johnh.


Planning How to Map Accounts
Upgrading to a Trusted Domain Model	9 of 14

Mapping LAN Manager User Accounts

Planning How to Map Accounts

If your LAN Manager domains contain usernames that can easily be associated with users, the task of achieving a single network logon is straightforward. If accounts exist in your LAN Manager domains that are difficult to associate with a particular user, you must do some preliminary investigation work to determine what the mappings should be.

For example, suppose that an account existed in the Engineering domain called John. Should this account be mapped to johnh, or is there another user in the organization with the first name of John? The userconv utility will automatically map users who have identified usernames under LAN Manager and Windows NT Server, and will allow you to manually map LAN Manager account usernames to a different single network logon username. For example, automatic mapping allows you to map user johnh from a LAN Manager domain called Manufacturing to the account johnh in the MIS domain. Manual mapping allows you to map user johnhampton from the Engineering domain to account johnh in the MIS domain.


Mapping LAN Manager Local Groups
Upgrading to a Trusted Domain Model	10 of 14

Mapping LAN Manager User Accounts

Mapping LAN Manager Local Groups

After upgrading a LAN Manager server to a computer running Windows NT Server, you probably want to continue using groups that existed under LAN Manager. If you are taking advantage of a trust relationship, you might want the group to be defined in the trusted domain. Alternatively, you might want the group to be defined in your own domain, while only user accounts are defined in the trusted domain.

The userconv utility allows you to map your LAN Manager groups to global groups, and it also allows you to re-create local groups consisting of users defined on other trusted domains.

Mapping to Global Groups

To continue to use your groups and have them defined in a trusted domain, you must ensure that the group is created in the trusted domain and consists of the same trusted domain users. Then you can map groups as easily as user accounts are mapped. When you do this, you are using global groups.

Mapping to Local Groups

To continue to use your groups and have them defined in your own domain, you must create the groups in your own domain, and the group should consist of users from the trusted domain. When you do this, you are using local groups.


How Account Mapping Fits in the Upgrade Process
Upgrading to a Trusted Domain Model	11 of 14

How Account Mapping Fits in the Upgrade Process

To map trusted accounts, you must run the userconv utility (Map to trusted domain accounts) followed by the aclconv utility (Restore permissions). The portuas utility (Convert accounts) should not be run on the domain you are upgrading. Instead, it can be used to create trusted domain accounts in another domain that you have already upgraded.

Userconv creates an output file that is used by the aclcomp utility to verify successful mapping of accounts and permissions. For example, if user johnha is mapped to user johnh, userconv logs this name change so that aclcomp does not indicate that johnha no longer has access to files.

You can run userconv on its own or from within the Windows NT Server Upgrade Manager. Userconv corresponds to "Map user accounts to trusted domains" in the Upgrade Manager interface.


Account Mapping Requirements
Upgrading to a Trusted Domain Model	12 of 14

Account Mapping Requirements

In order to map accounts, userconv requires that accounts exist in a local or in a trusted domain. You cannot use userconv to create new user accounts. This does not restrict the ability to combine multiple LAN Manager domains into a single Windows NT Server domain.

Userconv uses the output from the backacc utility (NETACC.BKP). Backacc must be run under LAN Manager before upgrading to Windows NT Server.


Account Mapping Limitations
Upgrading to a Trusted Domain Model	13 of 14

Account Mapping Limitations

Due to the format of NETACC.BKP, you can use userconv to map users only during the upgrade process. Once your trusting domain is put into production on your network, you cannot map any additional users from a trusted domain with this tool. However, you will be able to map users on other trusting domains that have not yet been upgraded.

This restriction is required because the organization of files and directories on the disk partitions on the computer running Windows NT Server will most likely change as users add, modify, and delete files. Once the file organization changes, the "snapshot" of the file permissions that existed under LAN Manager is no longer valid, so the file permissions can no longer be restored correctly.


Mapping Accounts
Upgrading to a Trusted Domain Model	14 of 14

Mapping Accounts

This section:

Tells you how to start the User Conversion program.

Tells you how to select a NETACC.BKP file

Describes the elements of the main User Conversion dialog box.

Tells you how to map user accounts and groups from a LAN Manager NETACC.BKP file to one or more Windows NT Server domains.

For information on how userconv executes the mapping process, see "Userconv" in Chapter 8, "Upgrade Utilities Reference."

Starting User Conversion

There are two ways to run user conversion: from within Windows NT Server Upgrade Manager (the recommended method) or stand-alone.

To run User Conversion from within Windows NT Server Upgrade Manager

Run Express upgrade. When configuring Upgrade Manager, include the Map To Trusted Domain Accounts tool in the Upgrade Tool Schedule.

When Upgrade Manager executes this tool, the User Conversion program starts and the Open dialog box appears

To run User Conversion stand-alone

1.	From the command prompt, change to the UPGRADE directory.

2.	Type userconv.

The User Conversion program starts, and the Open dialog box appears.

Note

If you are running User Conversion from within Upgrade Manager and if you will be converting more than one NETACC.BKP file, for each NETACC.BKP file to be converted you will need to add one instance of the Map To Trusted Domain Accounts tool to the Upgrade Tool Schedule. (Each NETACC.BKP file must reside in a different directory.)

Selecting a NETACC.BKP File

Once User Conversion starts, the Open dialog box appears. In this dialog box, you specify the NETACC.BKP file whose user accounts and groups will be mapped to Windows NT.

To select a NETACC.BKP file for mapping to Windows NT Server

1.	In the File Name box, select a NETACC.BKP file.

Often, this file is located in the local UPGRADE directory, and is automatically selected in the File Name box. However, if necessary you can use the Network button, the Drives box, and the Directories box to locate the appropriate NETACC.BKP file.

Note

Each NETACC.BKP file can only be converted once by the User Conversion program. Do not select a NETACC.BKP file that has previously been converted.

2.	Choose the OK button.

The selected NETACC.BKP file is loaded, and the User Conversion dialog box appears.

The User Conversion Dialog Box

After a NETACC.BKP file is chosen, the User Conversion dialog box appears.

The User Conversion dialog box contains the following elements.

Item	Function

LAN Manager Accounts list	Lists the user accounts and groups from the NETACC.BKP file. One or more names can be selected from this list.

Once a user account or group has been mapped, it is removed from this list and is added to the Current Assignments list.

Trusted Domains box	Displays the selected domain.

When this list box is opened, it lists the local domain and all domains that the local domain trusts.

Trusted Accounts list	Lists the user accounts and global groups of the domain that is displayed in the Trusted Domains box. (If the local domain is selected, its local groups are also listed.)

Current Assignments list	Lists the mapped user accounts and groups. The LAN Manager names are shown in the left column. The Windows NT names (including domain) are shown in the right column.

These are the mappings that will be performed when the Convert button is selected.

Auto Map button	Allows you to merge identically-named user accounts and identically-named groups.

When one or more names are selected from the LAN Manager Accounts list and this button is chosen, User Conversion examines the Trusted Accounts list for identical names.

When a match is found, a mapping is added to the Current Assignments list, and that name is removed from the LAN Manager Accounts list. When no match is found, that name remains listed in LAN Manager Accounts.

Note:  Even if they have identical names, groups are not mapped to user accounts, nor are user accounts mapped to groups.

Manual Map button	Allows you to merge user accounts and groups when they are not identically named. This is particularly useful when a user had several LAN Manager accounts under various usernames, but will be provided with only one Windows NT account.

When one or more names are selected from the LAN Manager Accounts list and one name is selected from the Trusted Accounts list, choosing this button adds the names that map to the Current Assignments list, and removes the selected names from the LAN Manager Accounts list.

Note:  Groups cannot be manually mapped to user accounts, nor can user accounts be mapped to groups.

Convert button	Accomplishes the conversions as mapped in the Current Assignments list, and then exits User Conversion.

Cancel button	Exits User Conversion without conversion, canceling any specified mappings.

Help button	Provides access to online Help. It displays the table of contents for User Conversion Help.

About button	Provides version and copyright information for Microsoft Windows NT User Conversion.

Add Group button	When a group is selected from the LAN Manager Accounts list, choosing this button adds a new local group of the same name to the Current Assignments list, maps the selected LAN Manager group to that new local group, and adds the member user accounts from the LAN Manager group to the new group.

Note:  This can only be performed for the local domain. It cannot be done for trusted domains. Also, a local group of that name cannot already exist in the Windows NT domain.

Sort By option	Sorts the Current Assignments list. The Username option sorts by the old LAN Manager account name. The Domain option sorts first by the Windows NT domain (the right column) and then, for each domain, by the old LAN Manager account name (the left column).

Remove button	When one or more accounts are selected from the Current Assignments list, choosing this button removes the selected mappings. The removed accounts are returned to the LAN Manager Accounts list.

Mapping User Accounts and Groups

You can map user accounts from a LAN Manager NETACC.BKP file to a Windows NT domain as part of your upgrade.

To map user accounts and groups

1.	Start User Conversion.

2.	Select the appropriate NETACC.BKP file.

3.	Select a domain from the Trusted Domain box.

4.	To merge identically named user accounts and groups, select one or more names from the LAN Manager Accounts list, and then choose the Auto Map button.

User Conversion searches in the Trusted Accounts list for identical Windows NT names. When it locates a match, a mapping from the LAN Manager name to the identical Windows NT name is added to the Current Assignments list, and the mapped LAN Manager name is removed from the LAN Manager Accounts list. When no match can be found, the LAN Manager name remains in the LAN Manager Accounts list.

Note

Even if they have identical names, groups are not mapped to user accounts, nor are user accounts mapped to groups.

5.	When user accounts or groups do not have identical names, you can manually merge them. Select one or more names from the LAN Manager Accounts list, select one name from the Trusted Accounts list, and then choose the Manual Map button.

Each selected LAN Manager name is mapped to the selected Windows NT name. The mappings are added to the Current Assignments list, and the mapped LAN Manager names are removed from the LAN Manager Accounts list.

Note

Groups cannot be manually mapped to user accounts, nor can user accounts be mapped to groups.

6.	To map a LAN Manager group to a new Windows NT local group, select a group from the LAN Manager Accounts list, then choose the Add Group button.

A new local group of the same name is added to the Current Assignments list, the selected LAN Manager group is mapped to that new local group, the mapped LAN Manager group is removed from the LAN Manager Accounts list, and the member user accounts from the LAN Manager group are added to the new group.

Note

This can only be performed for the local domain. It cannot be done for trusted domains.

7.	To map LAN Manager user accounts and groups into other Windows NT domains, repeat steps 3 through 6.

You can choose to map to the local domain or to a domain trusted by the local domain.

8.	To perform the conversion as mapped in the Current Assignments list, choose the Convert button.

The conversion will be performed, and then User Conversion will quit.

User Conversion will verify that the usernames of accounts being mapped exist only once on the network. If any user is left unmapped, User Conversion will create an output file containing the account information for each unmapped user. User Conversion will generate error messages as a result of account name conflicts.


Troubleshooting
Chapter 7	1 of 4

Troubleshooting

This chapter contains information to help you troubleshoot the upgrade process and any interoperability problems. For additional information, check the README.TXT file on the upgrade utility disk.


Common Problems
Troubleshooting	2 of 4

Common Problems

The section contains hints for solving various problems that can occur during or after the upgrade.

Using the Upgrade Manager and utility programs

The following conditions could prevent execution of a utility or upgrade manager program.

Required input files are not present to run the program (see "Input and Output Files" in this section).

Log files are present from a previous upgrade attempt. Delete all log files before proceeding.

You have chosen to run Custom upgrade from the Windows NT Server Upgrade Manager, but have not configured options.

The Express upgrade does not schedule appropriate upgrade steps because an input file is missing from the UPGRADE directory. If you select Express upgrade, the Windows NT Server Upgrade Manager examines the output files in the UPGRADE directory and determines what programs to run to complete the upgrade. See "Running Express Upgrade" in Chapter 6, "Upgrading to a Trusted Domain Model," for a list of files that Express upgrade uses to determine the available schedule.

You have run out of space on your hard disk to store output files. Acllist, aclconv, userconv, and aclcomp can create large output files. If a utility suddenly stops, check that disk space is adequate.

SCSI devices are improperly configured. For example, incorrect SCSI bus termination can cause the aclconv utility to hang.

Acllist runs slowly. Acllist can cause excessive paging on disks containing large numbers of files and/or directories. To avoid this problem, run acllist specifying one or more root-level subdirectories, instead of a drive.

Files are corrupt.

After converting partitions to NTFS, the Windows NT Server Upgrade Manager fails to restart when foreign language versions are involved in an upgrade. After converting partitions to NTFS, the Windows NT Server Upgrade Manager schedules a reboot and then places itself in the Startup Group. This guarantees that the upgrade continues automatically after the reboot. For foreign language versions of Windows NT Server, the Upgrade Manager uses the native translation for "Startup group." If the Upgrade Manager cannot be placed in the default "Startup group" for a foreign language version, then a group titled "Startup" is created containing an icon for the Upgrade Manager. If you double-click on this icon, the Upgrade Manager restarts and continues with the upgrade.

Net logon service doesn't start in your LAN Manager domain

The LAN Manager net logon service will not start if server accounts are duplicated in a Windows NT Server domain. This situation can also cause replication and trust relationships to function incorrectly.

The following circumstances can result in the creation of duplicate accounts:

Upgrading a LAN Manager PDC to a Windows NT Server clone and leaving the original LAN Manager domain intact. In this scenario, portuas creates computer accounts on the clone for each of the servers running LAN Manager in the original Servers group. Thus, server accounts exist in both domains. This situation prevents LAN Manager users from logging on.

Using Server Manager to create an account for a computer that already exists in another domain. For example, if you add the computer account \\FRISBEE to a Windows NT domain controller, and \\FRISBEE already exists in another domain, you will have problems setting up a trust relationship between the two domains.

To rectify this problem, use User Manager for Domains to delete accounts for LAN Manager server(s) that exist in another domain.

Replication Problems

Replication is not working in a mixed domain because the local time of a LAN Manager importer is different by a half-hour or more from the local time of a Windows NT exporter. In this scenario, replication synchronization will not occur, and the Replicator service will repeatedly copy files between the computers (increasing network traffic).

During replication, "ERROR 123: Invalid Name" occurs. This may be because a Windows NT Server tried to import a tree with a pathname greater than 255 characters.

Replication is not working in a LAN Manager domain because server accounts are duplicated in another Windows NT Server domain. Delete accounts from the Windows NT domain.

Replication is not working because the replication directories were not located during the upgrade process, and thus were not copied to the correct location on the Windows NT Server computer. Check the [Replicator] section of RESTENV.LOG to see if restenv recorded an error when it tried to upgrade replication. This typically occurs if you forgot to copy replication directories to a clone computer, or if you copied them to a new drive (from drive C to drive D, for example).

After upgrading a LAN Manager export server, Windows NT Server import servers are unable to access the export directory tree.

The restenv utility moves all import server accounts in the LAN Manager group "rep" to the Windows NT Server group Replicator. If such a group exists under a different name, restenv does not port it. In this case, rename the group to "rep" and rerun restenv.

After upgrading to a dual boot configuration, replication stops working under OS/2. If the original LAN Manager export or import path specified in LANMAN.INI was a relative path, restenv moves the old LAN Manager export and import subdirectories under the Windows NT export or import path. To maintain a dual boot configuration, modify the LANMAN.INI import and export path entries and update permissions assigned to those directories.

If you are having replication problems in a mixed domain and cannot determine the cause, try the following steps to troubleshoot:

Try rebooting LAN Manager servers.

Does your security database contain usernames with extended characters such as Š, ¢, and so on? Usernames containing these characters can cause problems with replication. Try deleting or changing these usernames.

Change LAN Manager backup domain controllers and member servers to standalone servers and then change them back to their original roles.

Note what operating system is running on the import computer (Windows NT Workstation, Windows NT Server, OS/2, UNIX).

Review the error log of both the import and export computers. The applications log has entries for the Replicator service and often contains useful information.

What file systems are installed in the partitions pointed to by the import and export paths?

What time zones are the import and export computers running in?

Make sure the import computer has Backup Operator permissions. If these permissions are not set up, errors 5, 1300, and 1307 will appear in the event log.

Are the import and export computers in the same domain? If so, are the password and username the same in both domains? Do the domains trust each other?

Are alerts being received by administrative accounts? (Has the Alerter service been started?)

Are there any extended attributes in the files or directories being replicated?

If the source directory is on an NTFS partition, are there any alternate data streams in the files or directories being replicated?

If the source or destination directories are on an NTFS partition, look at the permissions on the import and export trees with File Manager. Does the Replicator local group have at least CHANGE privileges to these directories?

Is it possible that an account has a file open (on import or export) all the time? This would appear as a sharing violation in the event log (error 32).

Is there a REPL$ share on the export computer? (The share is created as a side effect of the Directory Replicating dialog box on the export computer. This dialog box also sets an ACL for the REPL$ share. Using the NET command or any other means to create the REPL$ share is likely to cause problems.)

If you run the NET START command on the export and import computers, do both computers show "Directory Replicator" (or equivalent) in the list?

If you are exporting or importing from an NTFS directory, does either tree have filenames that differ only in case? Which file gets replicated is not predictable. It is possible that the export computer will choose one file and the import computer will choose another. This results in the replication being out of sync.

Some versions of the OS/2 importer leave the archive bit set on all files imported, whether or not it was set on the export side. This too could result in continuous copying. One alternative is to set the archive bit on all files on the export computer. (Windows NT to Windows NT replication correctly clones the archive bit.)

Some LAN Manager 2.1a import computers do not set their status file to OK.RP$, causing a few side effects. Files will not be recopied each pass, but a file comparison will occur. Except for the status file state, the files are correctly replicated. This behavior does not occur on LAN Manager 2.2 importers.

Some versions of LAN Manager allow hard disk files with reserved names, such as LPT1 or COM1. This can cause replication problems and should be avoided. The Windows NT replicator currently lets these filenames exist.

OS/2 LAN Manager only allows one set of credentials to be in use at a time. (The credentials consist of the user name and password.) If someone is interactively logged on to one user identification (ID) and the replicator is trying to use a different user ID, then replication cannot occur until the interactive user logs off. On the other hand, if the interactive user and the replicator user have the same user ID, then replication is possible, depending on the value of the TryUser value in the LANMAN.INI file.

LAN Manager importers are generally designed with a limit of 1000 files per directory. You should be aware that the "." and ".." directory entries use two of those 1000 entries. Also, some versions may have an off-by-one error that causes repeated file copies with exactly 1000 entries. This gives a practical limit of 997 files for those importers. The Windows NT importer does not have these limitations.

Are there some files being replicated from an HPFS partition (written by OS/2) to a Windows NT Server computer? Do these files have extended attributes (EAs)? If so, OS/2 may have written the EAs in discontiguous parts of the disk, which Windows NT does not support. The directory replicator includes the EA sizes in its checksums, and they may be wrong in this case. The replication may stay out of sync permanently. You can use Windows NT to rewrite the same EA values to a single contiguous area, if you know the original EA values. Note that an HPFS volume can be accessed over the network while OS/2 is directly reading or writing the volume.

Restoring logon scripts

The logon script path specified under Windows NT does not exist, perhaps because you did not copy the LANMAN root to a clone server, or because you copied it to a different drive.

Backing up and restoring files

Windows NT Backup may have a problem restoring files from a Sytos Plus tape if the file is in a backup session that spans two Sytos Plus tapes and the file itself is entirely on the second tape. If this occurs, you can restore the file by rerunning backup after setting the following Windows NT Registry key to 0: HKEY_CURRENT_USER\Software\Microsoft\
Ntbackup\Backup Engine\Use fast file restore. After restoring the file, reset the key to 1.

When restoring or cataloging a Sytos Plus tape under Windows NT, you get the error "Fatal tape translation error on Tape drive 1" because the backup error correction flag value is incorrect in the Registry.

To correct this problem, edit the following registry key: CURRENT_USER\SOFTWARE\
Microsoft\Ntbackup\Translators\Sytos Plus ECC flag. This value can be 0 for OFF, 1 for ON, or 2 for AUTO. Values should be set accordingly:

4mm DAT 0	1/4 in 525 0
8mm DAT 0	1/4 in 150 1
Establishing connections between LAN Manager and Windows NT computers

You cannot see the other server on the network because you are running different protocol software.

You are not logged on using an administrative account that exists on both computers.

The local Workstation service is not started or the Server service is not started on the target.

There are physical network problems.

Copying (backing up) files to another server

The LAN Manager Upgrade Manager will not accept a drive that you specify. This could occur if you did not previously set up the connection, or if you do not provide an accurate pathname. For example, entering H: will not work; you must type H:\ or H:\PROGRAMS.

You can connect to another server but cannot copy files. Check that you have full permission to access the share on the destination server. For example, if you have Read permission instead of Change, copying cannot occur.

Possible logon problems

You cannot log on to a server running LAN Manager in a mixed domain because you are using a case-sensitive password. This is typically indicated by the following error message:

"Two passwords exist for you on the domain, one that is case-sensitive and one that is not: "System error 1219 has occurred. The credentials supplied conflict with an existing set of credentials."

You may be trying to log on to the wrong domain for your account.

You are unable to access a server running LAN Manager in a mixed domain and are given the error "Incorrect password" or "Password expired." This may be because you were given a Windows NT account with default settings (user must change password at first logon). You must log on and change your password before being allowed access to the server running LAN Manager.

Administration problems in a Windows NT Server domain

When you try to administer user accounts in a mixed domain you get an error stating that there is an invalid session key and access is denied. This may be because you have changed your administrative password on a server running LAN Manager. Passwords for administrative accounts may only be changed on the Windows NT Server computer. (Users, however, can change their passwords at any computer in the domain.)

When an administrator's password is changed, an additional session key needs to be applied to the administrator user account security identifier (SID). When the password is changed from a down-level computer, the session key is not properly applied, so the Admin account is affected.

Problems with Macintosh files and volumes

The Macintosh Finder only reports up to 2 GB volume sizes, although you may have created a larger volume. Because Windows NT supports volumes greater than 2 GB, it allows larger Macintosh volumes even though the Finder cannot show volume sizes greater than this value.

Volume sizes are shown as follows under Windows NT:

If available volume size is > 2 GB, show 2 GB

If amount "in disk" is > 2 GB, show 2 GB

If amount "available" is < 2 GB, show correct amount

If amount "in disk" is < 2 GB, show correct amount

If hcopy generates "Error 2" in the process of copying Macintosh files, check for folders and file names with nonstandard names. For example, the folder name "option-a" will cause an error to occur. To avoid this problem, rename the offending file(s) or folder(s).

ADVISORY.TXT does not show tape or CD-ROM drives.

ADVISORY.TXT cannot record information for non-LADDR components.

Sytos Plus not Found

The Upgrade Manager searches for SYPLUS.EXE in the \SYPLUS directory of all drives. If you have Sytos Plus installed in a different directory, it will not be detected and therefore not be started automatically.


Input and Output Files
Troubleshooting	3 of 4

Input and Output Files

The following table lists input and output files associated with each upgrade utility.

Utility		Input files		Default output files
backacc		BACKACC.EXE, NET.ACC		NETACC.BKP, ACLBAKdrive.ACL
backat		BACKAT.EXE, SCHED.LOG		RESTAT.CMD
acllist		ACLLIST.EXE		ACLLIST.DAT¹
backenv		BACKENV.EXE, SERVER.CFG, TCPUTIL.INI, LANMAN.INI, PROTOCOL.INI, CONFIG.SYS, LMUSER.INI, COMDEV.INI		LMBAKENV.DAT, ADVISORY.TXT, SFMCONV.RUN (if Services for Macintosh present)
hcopy		HCOPY.EXE		-
convert		CONVERT.EXE		-
userconv		NETACC.BKP, USERCONV.HLP, USERCONV.EXE		ACLWORK.DAT, USERWORK.DAT, USERCONV.LOG
portuas		PORTUAS.EXE, NETACC.BKP		PORTUAS.LOG
aclconv		ACLCONV.EXE, ACLBAKdrive.ACL ACLWORK.DAT (optional)		ACLBAKdrive.LOG²
restenv		RESTENV.EXE, LMBAKENV.DAT		RESTENV.LOG, RESTENV.DAT³
sfmconv		SFMCONV.EXE, LANMAN.INI, SRVAUTO.PRO, CONFIG.AFP, CONFIGSV.AFP, USERINFO.AFP, USERBACK.AFP, DESTOP.AFP, DIRID.AFP, VOLINFO.AFP, FILEINFO.AFP		SFMCONV.LOG, SFMCONV.DAT
aclcomp		ACLCOMP.EXE, RESTENV.DAT, ACLLIST.DAT¹, USERCONV.DAT, SFMCONV.DAT		ACLCOMP.LOG
lmupmgr		LMUPMGR.EXE,LMUPMGR.INF, LMUPMGR.HLP,CLEANUP.EXE		LMUPMGR.LOG
wntupmgr		WNTUPMGR.EXE, WNTUPMGR.INI, WNTUPMGR.EXP, WNTUPMGR.HLP		WNTUPMGR.LOG
¹  This filename is ACLLISTdrive.DAT when acllist and aclcomp are run from the Upgrade Manager.

²  A default output file if the utility is run from the Upgrade Manager program.

³  Created if replication and/or logon script paths refer to relative paths.


Error Messages
Troubleshooting	4 of 4

Error Messages

This section explains some of the more common error messages generated by the upgrade software. Error messages generated by the LAN Manager Upgrade Manager (Imupmgr) are listed first, followed by messages for each of the utilities.

Lmupmgr

Error_DISK_Full

This error message can occur if the output of acllist (ACLLIST.DAT) exceeds available disk space. Free disk space and run record file permissions again.

Information file is not in current directory.

Check that LMUPMGR.INF is present in the UPGRADE directory.

Printer returned error 1533.

This occurs if you try to print ADVISORY.TXT and the file is not found.

Upgrade Manager encountered error 2.

Check that CLEANUP.EXE and other upgrade utility executables are present in the UPGRADE directory.

Wntupmgr

The Windows NT Server Upgrade Manager (wntupmgr) does not generate error messages; it only displays messages generated by the upgrade utilities.

Aclcomp

When upgrading partitions (particularly Macintosh volumes) with file names containing certain extended characters, aclcomp may incorrectly report that some files could not be found.

In addition, the following specific error requires no action because the file EA DATA.SF is normally deleted after conversion:

Error: the file E:\EA DATA. SF could not be found.

Aclconv

Access denied

You may have: (1) tried to write to a read-only file; (2) tried to access a resource (for example, a file, subdirectory, or named pipe) that is in use; or (3) tried to access a resource or perform an action for which you do not have privilege.

Do one of the following: (1) change the attribute of the read-only file; (2) wait until the resource may no longer be busy, then try again; or (3) make sure you are logged on with administrative privileges.

Cannot open <filename>.

The aclconv utility was unable to open the specified file. It may have been attempting to query an existing data file, set the file pointer to the top of an existing log file, or create a new log file.

Check to make sure that the file names are valid in the command line, and that the data file (if specified) and log file (if specified) exist and are accessible.

Conversion ceased due to error.

The aclconv utility was unable to convert an access control list.

Examine the log file you specified as a parameter in the aclconv command. Resolve any problems that are listed there, then try the conversion again. Before you try again, free up as many Windows NT resources as you can. If this message persists, you will have to apply the file permissions manually, using File Manager.

Error encountered reading data file.

The aclconv utility was either unable to read the next access control list from the input data file, or was unable to write the converted access control list to the Windows NT resource.

The data file associated with this access control list, which had been imported into the NTFS file system earlier by the convert utility, is still good. It is only the access control list that cannot be converted. Use Windows NT File Manager to locate any converted files that do not have access control lists associated with them, and add file security manually, using File Manager.

Error encountered writing log file.

The aclconv utility was unable to write an entry to the log file.

Since the log file is suspect, you will have to use Windows NT File Manager to manually confirm that all the access control list conversions you specified were completed.

Acllist

Drive X is full. Free additional disk space and run acllist again.

The output file from acllist (ACLLIST.DAT) can be large, depending on the number of files and permissions assigned. Writing acllist output to a floppy disk is not recommended, as the size of ACLLIST.DAT can easily exceed the size of a floppy.

General Protection Fault

This may occur if you do not pause the server running LAN Manager and delete all sessions prior to upgrading. The LAN Manager Upgrade Manager prompts you to take these steps when it first starts up.

Backacc

NET 3552: File C:\LANMAN\LOGS\NET.AUD cannot be opened.

This error can be ignored as the NET.AUD file is not used in the upgrade.

Backenv

Backenv writes error messages to the screen and to the ADVISORY.TXT file. Messages in ADVISORY.TXT may indicate that backenv was unable to locate a device. For example, if backenv does not detect a disk in floppy disk drive A, it writes the following error to ADVISORY.TXT: "Floppy A: Information could not be obtained. Error code - 21." Inserting disks in floppy disk drives eliminates this error and also speeds up the execution of backenv.

Possible error messages include:

Error copying <filename> to <filename> or Error writing <filename>.

Backenv could not copy a file into the UPGRADE directory because of a bad sector or because the disk was full.

Error occurred trying to obtain server information. The server is not running. Please start the server and rerun.

Backenv requires that the Server service be active to run.

Insufficient Space on Volume. Please restart BACKENV.EXE with a target drive that has sufficient free space.

There is not sufficient space for backenv to copy LANMAN.INI, PROTOCOL.INI, and other files into the UPGRADE directory.

Mouse hardware could not be detected. MouOpen error - 385.

Mouse hardware is not present or it is configured incorrectly.

SYS 0197. Operating system is not presently configured to run this configuration.

Check that IOPL=Yes in the CONFIG.SYS file.

<filename> could not be opened.

Backenv could not find a particular file such as LANMAN.INI or PROTOCOL.INI.

Backat

NET 3804. SCHED.LOG cannot be opened.

The SCHED.LOG file is not present, it is in use, or the disk is full.

Convert

<File system> is not a valid file system

The convert utility does not support the target file system you specified in the second parameter of the convert command. The only valid target file system for the convert utility is NTFS.

If you want to convert the drive to the NTFS file system, retype the convert command and specify NTFS as the target file system. To check the syntax of the convert command, type HELP CONVERT at the command prompt.

A file contains extended attributes, but the Extended Attribute File was not found.

During a FAT to NTFS file conversion, the convert utility could not find the extended attribute file associated with a FAT file.

The FAT volume is corrupted. Run the chkdsk utility with the /f option and then retry the conversion.

AUTOCONV: could not check volume <file system> for errors. The conversion to <drive letter> did not take place.

The autoconv utility cannot run the chkdsk utility on the target drive to fix any errors that may exist before the conversion is done. This may be because the drive could not be opened for the exclusive write access that chkdsk needs.

Once your computer is restarted, run the convert utility from the command line.

Cannot convert <file system> volumes to <filename>.

The convert utility cannot make the specified file system conversion. In Windows NT, two conversions are possible: (1) FAT to NTFS, or (2) HPFS to NTFS.

Cannot CONVERT a network drive.

You cannot use the convert command on drives that have been redirected over the network.

Run the convert utility on the computer that is local to the drive you want to convert.

Cannot convert an extended attribute.

During a FAT to NTFS file system conversion, the convert utility was unable to convert an extended attribute.

The FAT partition is still in its original (unconverted) state. Run the chkdsk command with the /f option and try the conversion again.

Cannot create the elementary file system structures.

During a FAT to NTFS file system conversion, the convert utility could not create the elementary NTFS file system structures on the target volume.

Delete unnecessary files and retry the conversion. If this message reappears, the volume may not be suitable for conversion.

Cannot determine location of system directory.

The convert utility needs to use files that it assumes are in the system directory, but it cannot find the system directory.

Make sure you have the privileges associated with the administrators group and that you have access to the system directory.

Cannot locate or create an NTFS index.

During a FAT to NTFS file system conversion, the convert utility was unable to create an NTFS root index.

The FAT partition is still in its original (unconverted) state. Delete some files from the partition and run the chkdsk utility with the /r option. Then retry the conversion.

Cannot relocate existing file system structures.

During a FAT to NTFS file system conversion, the convert utility was unable to find contiguous space on the volume for the NTFS structures that have to be at a fixed location on the disk.

Delete unnecessary files and retry the conversion. If this message reappears, the volume may not be suitable for conversion.

Could not find file <filename>. Make sure that the required file exists and try again.

The convert utility could not find the programs that do automatic disk checking and file system conversion in the SYSTEM32 directory (these files are AUTOCHK.EXE and AUTOCONV.EXE). No conversion was done.

Restore those two program files from the Windows NT distribution medium to the Windows NT SYSTEM32 directory (you will have to decompress the files). Then retry the convert command.

Could not schedule an automatic conversion of the drive.

The convert utility tried to schedule an automatic file system conversion of a drive because it could not be done now (because, for example, the drive could not be locked). The conversion could not be scheduled.

Make sure you have the privileges associated with the administrators group.

Drive <drive letter> is already <file system>.

The automatic file system conversion utility (autoconv) had been scheduled to convert the file system on the specified drive the next time the computer was restarted. At restart time, autoconv is running, but has found that the drive already has the target file system. No conversion is necessary, so no conversion will take place.

Error converting directory <filename>.

During a FAT to NTFS file system conversion, the convert utility was unable to convert the specified directory. Conversion was stopped at that point.

The FAT partition is still in its original (unconverted) state. Run the chkdsk command with the /f option, then try the conversion again.

Error converting file <filename>

During a FAT to NTFS file system conversion, the Convert utility was unable to convert the specified file. It will not be included in the NTFS volume file set.

The FAT partition is still in its original (unconverted) state. Run the chkdsk command with the /f option, then try the conversion again.

Error converting file data.

During a FAT to NTFS file system conversion, the convert utility was unable to move the data for a file into the NTFS file structure.

The FAT partition is still in its original (unconverted) state. Run the chkdsk command with the /f option, then try the conversion again.

Error during disk read

During a conversion from a FAT file system to NTFS, the convert utility was unable to read a structure that is part of the FAT file system description.

The FAT partition is still in its original (unconverted) state. Run the chkdsk command with the /r option on the FAT partition to map out bad (unreadable) sectors. Then try the conversion again.

Error during disk write

During a conversion from a FAT file system to NTFS, the convert utility was unable to write a structure that is part of the NTFS description.

The FAT partition is still in its original (unconverted) state. Run the chkdsk command with the /r option on the FAT partition to map out bad (unwriteable) sectors. Then try the conversion again.

Error reading directory <filename>

The FAT or HPFS volume may be corrupted. Run the chkdsk utility with the /f option and try the conversion again.

Error returned: 4

This error message occurs if you run convert on a volume that is already converted.

Insufficient disk space for conversion

In order to do the FAT to NTFS or HPFS to NTFS conversion, you will have to delete unneeded files on the volume to be converted. Then retry the conversion.

Invalid drive - <drive letter>

When you specified the drive for the convert utility to convert to NTFS, either you specified a drive that does not exist or you specified a redirected drive.

Convert cannot be run on a remote drive. If you simply mistyped the drive letter in the convert command line, retry the command with the correct drive letter.

Must specify a file system

The convert command takes two parameters: the volume to be converted and the target file system. You did not supply the second parameter.

To check which parameters are valid for this command, type help at the command prompt followed by the command name (in this case, convert).

The conversion failed. The <file system> drive was not converted to <file system>.

The file conversion from a FAT partition or HPFS volume to an NTFS volume is not complete.

The FAT partition or HPFS volume is still in its original (unconverted state). Free up some system resources and try the conversion again.

The specified volume has hotfixes; it cannot be converted. Run CHKDSK /f to resolve these references.

On the HPFS volume you specified as the source for an HPFS to NTFS file system conversion, not all temporary areas (which were created to correct disk write errors) have been written to permanent areas on the volume.

Run the chkdsk command with the /f switch on the HPFS volume. Then retry the conversion.

The specified volume is dirty; it cannot be converted. Run CHKDSK /f to correct this problem.

On the HPFS volume you specified as the source for an HPFS to NTFS file system conversion, not all file changes have been written to permanent areas on the volume.

Run the chkdsk command with the /f switch on the HPFS volume. Then retry the conversion.

This volume cannot be converted to <file system> Possible causes are: 1.- Bad sectors in required areas of the volume. 2.- <file system> structures in areas required by <file system>.

The volume is still in its original (unconverted) state. However, there is nothing you can do to make this volume suitable for conversion.

Hcopy

Error 2

If hcopy generates "Error 2" in the process of copying Macintosh files, check for folders and file names with nonstandard names. For example, the folder name "option-a" causes an error to occur. To avoid this problem, rename the file(s) or folder(s).

Portuas

*** NAME TOO LONG! ***

User and group names are limited to 256 characters in Windows NT. However, names are limited to 20 characters in the user accounts database.

Specify a name within the prescribed limits.

Adding administrator <name> as a regular user...

Windows NT requires accounts to be added as users. Then the account can be changed to an administrator, which portuas does automatically.

No action is needed.

Adding guest <name> as a regular user...

Consider deleting or deactivating the guest account because the account may not need the permissions that regular users have.

An error occurred while processing the logon hours for user <user name>.

The time zone for the Windows NT system must be the same as the time zone in the down-level system.

An error occurred while processing the workstation list for user <user name>.

When portuas was translating the list of workstations from the user accounts database to the Windows NT security database, either the system ran out of memory or one of the workstations has an invalid name. Workstation or computer names must have between 1 to 15 characters, must not begin or end with a blank space, and must not contain any control characters. The names also must not contain any forward or backslashes ( \ / ), double backslashes ( \\), brackets ([ ]), angle brackets (< >), colons (:), semicolons (;), quotation marks ( ), pluses (+), equal signs (=), question marks (?), wildcards (*), or vertical bars ( | ).

Verify that the workstation names from the down-level user accounts database are valid.

Changing accounts to allow null password for user <user name>...

Down-level accounts do not always have passwords even though the Password required bit is activated for the account. Portuas deactivates the bit which enables the account to be used.

No action is needed unless you decide to disable the account.

Changing group <name>...

A Windows NT group has the same name as a group from a down-level system so the Windows NT group's comments are changed to the down-level group's comments. The users from the down-level group are merged into the Windows NT group.

Before proceeding, verify that this is the desired outcome.

Changing unknown permissions for <user name> from <number> to a regular user...

The user accounts database may be corrupted.

Enter a new name:

Enter a new user or global group name.

Error 87 occurred adding user <user name>. User information: <text>

Error 87 indicates that portuas encountered an invalid parameter. The user accounts database may be corrupted.

Error 87 occurred changing user <user name>. User information: <text>

Error 87 indicates that portuas encountered an invalid parameter. The user accounts database may be corrupted.

Group <name> is already used as a user name in the Windows NT security database <text>.

Portuas will ask you for another name for the group, unless the Force Ignore option has been implemented.

Ignoring communication operator flag for <user name>...

Windows NT Workstation and Windows NT Server do not use communication operators so this flag is ignored when portuas adds or updates users.

No action is needed.

Ignoring redundant group <name>...

Groups with the same names are merged.

No action is needed.

The log file could not be created, possibly because it already exists. If this is the case, either delete or rename the log file, or change the log file name used on the command line when running portuas again.

Portuas creates the file PORTUAS.LOG. It must not exist from a previous upgrade attempt.

name <name> conflicts with a domain name <name>.

A user or global group name from the down-level database that is being upgraded is a duplicate of the domain name.

Portuas will ask you for another name for the user or global group, unless the Force Ignore option has been implemented.

Name: <user name>

All information about the specified user will be displayed on screen. The user accounts database may be corrupted.

Portuas must be run on a Windows NT Server domain controller or Windows NT system, not a server.

Run portuas on the domain controller. The servers in the domain that are running Windows NT Server will automatically be updated.

Portuas returned - -<code>. More information about this and other error codes greater than 2100 may be available by typing NET HELPMSG <code> at the command prompt. A zero indicates that no errors were detected when the database was converted.

The name of the database is invalid or does not exist.

Processed or skipped <number> users out of <number> total users.

The two numbers should be the same unless you used the -u option. If the numbers do not match, your down-level user accounts database may be corrupted.

Unexpected product type <number>.

The product type should be either a 1 or 2 for Windows NT Workstation and Windows NT Server, respectively.

Make sure you are running a version of portuas that is compatible with your operating system. Otherwise, your Registry may become corrupted.

Unexpected return code <code> from API <name>.

If the return code is 2100 or higher, type NET HELPMSG <code> at the command prompt. Otherwise, contact technical support.

User <user name> already exists. The security database is being updated...

The security database is being updated with the current information for the specified user.

No action is needed.

User <user name> is already used as a global group name in the Windows NT security database <text>.

Portuas will ask you for another name for the user, unless the Force Ignore option has been implemented.

Your account does not have permission to do this.

Portuas has stopped without making any updates to the Windows NT security database.

You must log on as an administrator to update the security database.

Restenv

Restenv could not find group Rep. You should rename the old replicator group to Rep and run Restenv again, or add users to local group Replicator manually.

The restenv utility moves all import server accounts in the LAN Manager group "rep" to the Windows NT Server group Replicator. If such a group exists under a different name, restenv does not transfer it. If this is the case, you can rename the group to rep and rerun restenv.

Restenv encountered <errornumber> enumerating the members of local group Rep. Members will not be propagated to local group Replicator.

If the error code is 2247 or 2219, the user account database may be corrupt. If error is 2229, problem may be disk I/O failure.

Share upgrade failed adding <SHARENAME>. The system cannot find the path specified.

Restenv has tried to reinstate a LAN Manager share, but cannot find the path on the Windows NT Server computer. For example, restenv cannot restore the share USERS = C:\LANMAN\ACCOUNTS\USERDIRS, if the directory path does not exist on the Windows NT Server computer.

Share upgrade requested for existing but different resource.

Restenv did not upgrade a share because the directory did not exist on the same drive.

USE upgrade failed adding <drive:>=\\<SERVERNAME>\<SHARENAME>. The credentials supplied conflict with an existing set of credentials.

Restenv could not reinstate a USE connection because the USE conflicted with an existing drive letter.

Error 2

If various extended characters appear in LAN Manager directory names, network connections, or shares, the network connections and shares may not upgrade successfully. Successful upgrading depends on whether the Windows NT Server code page supports an uppercase version of the extended characters in question.

If restenv encounters an unsupported extended character, it displays "Error 2" and skips the respective share or directory name.

The following characters have no uppercase equivalents under the specified code pages:

Codepage 437 (US)

Codepage 850 (Multilingual)

Codepage 865 (Nordic)

ƒ	ALT + 131		ALT + 149
…	ALT + 133	–	ALT + 150
ˆ	ALT + 136	-	ALT + 151
‰	ALT + 137	˜	ALT + 152
Š	ALT + 138	(space)	ALT + 160
‹	ALT + 139	¡	ALT + 161
Œ	ALT + 140	¢	ALT + 162
�	ALT + 141	£	ALT + 163
"	ALT + 147
Codepage 860 (Portuguese)

Š	ALT + 138
¡	ALT + 161
Codepage 863 (Canadian French)

Š	ALT + 138
£	ALT + 163
¢	ALT + 162
Sfmconv

Warning: open error on \<LANROOT>\MACINTOSH\*.*, The system cannot find the path specified.

If your system contains Macintosh volumes, check that the LANROOT directory is on its original LAN Manager drive. For example, if the LANROOT is on the C drive under LAN Manager, it must be on the C drive on the Windows NT Server computer.

Unable to Locate DLL. The dynamic link library SFMAPI.dll could not be found in the specified path.

This message under Windows NT Server typically indicates that Services for Macintosh has not been installed. Install Services for Macintosh and rerun sfmconv.

SFMCONV.EXE - Unable to Locate DLL. The dynamic link library SFMAPI.DLL could not be found in the specified path.

The following error message under Windows NT Server usually indicates that Services for Macintosh has not been installed. Install Services for Macintosh and rerun sfmconv.

Error=2 Can't Find File

Files or folders with names ending in a period or a space character cause the error "Can't Find File" during sfmconv execution. These files are converted, but the access permissions present on the file or folder may be more than they should be. In addition, the Macintosh volume is not mounted. To correct this problem, view permissions using File Manager, revoke those that should not be present, and add the Macintosh volume.

error: open error on G:\AIOSHARE\~AFP\VOLINFO.AFPError=3 The system cannot find the path specified.

If a LAN Manager Macintosh volume uses a directory name with an unsupported extended character, sfmconv skips the volume during conversion and generates an entry in SFMCONV.LOG. Note that, in this case, sfmconv successfully converts non-offending volumes.

If this error occurs, check unconverted volumes for directory names with any of the unsupported characters listed in Chapter 8, "Upgrade Utilities Reference." To convert the volumes, remove these characters prior to running sfmconv.


Upgrade Utilities Reference
Chapter 8	1 of 15

Upgrade Utilities Reference

This chapter describes each upgrade utility in detail. The following figure shows utilities in the order they are run under LAN Manager or Windows NT Server. The lines represent utility dependencies. For example, restenv depends on the output of backenv.


Aclcomp
Upgrade Utilities Reference	2 of 15

Aclcomp

Purpose

Aclcomp is a Windows NT utility that reads the file ACLLISTdrive.DAT created when the LAN Manager acllist utility is run on an OS/2 volume. Aclcomp compares the contents of ACLLISTdrive.DAT with converted data to ensure that all settings are retained or translated appropriately to Windows NT Server. Aclcomp must be run once for each drive you are upgrading.

Syntax

aclcomp [/dat:filename] [/a] [/newdrive:drive:] [/log:logfilename] [/s] [/q] [/?]

/dat:filename

Specifies the inventory filename, defaulting to ACLLIST.DAT in the current directory.

/a

Tells Aclcomp to append the inventory information to an existing file

/newdrive:drive

Tells Aclcomp to check a drive other than the one specified by the ACLLISTdrive.DAT file

/log: logfilename

Specifies the conversion report filename. If not specified, output defaults to ACLCOMP.LOG in the current directory.

/s

Sets silent mode. No status information is echoed to the screen during execution.

/q

Sets quiet mode. Minimal status information is echoed to the screen during execution.

/?

Displays command usage.

Comments

Aclcomp checks for mismatches in the creation date and time, the last write date and time, the data checksum, file size, and file attributes. If permissions (ACLs) are present, aclcomp reports on missing users and groups and mismatches in their permissions to files or directories.

If you have copied files to a drive other than that specified by ACLLISTdrive.DAT, you must direct aclcomp to check the new drive by using the /newdrive:drive option.

Aclcomp creates a report file (ACLCOMP.LOG) that lists any discrepancies in the file conversion process. File and directory information is compared against data stored in ACLLISTdrive.DAT. New files and directories, such as the \WINNT directory, are ignored.

Example

To use aclcomp to check information stored in ACLCOMP.DAT in the current directory and write it to ACLCOMP.LOG in the current directory, type:

aclcomp

To write ACLCOMP.LOG to another drive, type:

aclcomp /log:b:\aclcomp.log

To direct aclcomp to check a particular filename, type:

aclcomp /dat:acllistd.dat

To direct aclcomp to check a drive different from the one specified by ACLLISTdrive.DAT, such as the D drive, type:

aclcomp /dat:acllistc.dat /newdrive:d:


Aclconv
Upgrade Utilities Reference	3 of 15

Aclconv

Purpose

Aclconv is a Windows NT utility that uses the file and directory permissions stored in the file ACLBAKdrive.ACL, created when the LAN Manager backacc utility is run on an OS/2 volume. Aclconv then applies equivalent permissions to the files and directories on that volume once it has been converted to NTFS.

Syntax

aclconv /data:datafile /log:logfile [/NEWDRIVE:n:] [/DOMAIN:domain] [/?]aclconv /log:logfile /list

/data:datafile

Specifies the backup file produced by backacc (the default file name is ACLBAKdrive.ACL).

/log:logfile

Specifies a log file in which to write ACLs that aclconv could not restore.

/newdrive:n:

Is the drive to which permissions are to be restored. This parameter is only necessary if the files are stored on a different drive from that used on the source server. For example, if files are transferred from the E partition of the source OS/2 computer to the D partition of the destination Windows NT computer, n is D.

/DOMAIN:domain

Searches only the specified domain for account names.

/list

Lists the contents of the specified log file.

/?

Lists the command usage.

Comments

Since only NTFS supports the security features of Windows NT, aclconv can only be run on volumes that have been converted to NTFS. Before you convert a volume to NTFS or run aclconv,
you must first run the backacc utility on the LAN Manager volume you intend to convert to NTFS.

Aclconv supports moving files from drive C on the source LAN Manager volume to drive D on the destination Windows NT computer. It also allows you to merge files from two LAN Manager volumes into one Windows NT volume.

Access control lists (ACLs) that could not be restored by aclconv need to be restored manually.

Aclconv uses the file ACLWORK.DAT, created by the userconv utility. If aclconv detects this file, it prompts the user to verify use of the file to map permissions. This verification reduces the likelihood that aclconv uses the wrong file to map permissions. For example, if you run portuas, instead of userconv, aclconv should not use ACLWORK.DAT. If ACLWORK.DAT is present from a previous conversion attempt, aclconv cannot automatically determine if it is valid.

Under Windows NT, each file and directory has a discretionary access control list (ACL), which identifies users and groups that are granted or denied access. ACLs are controlled by the owner of the resource.

An ACL consists of a set of access control entries (ACEs); an ACE in turn consists of a user or group name and a set of associated access privileges. For each LAN Manager access permission, aclconv creates an equivalent ACE and adds it to the file or directory's discretionary ACL. Because there are no "owners" under LAN Manager, aclconv gives resource ownership to the Admin account.

Aclconv is often the most time-consuming portion of the upgrade. For large numbers of accounts, it can take several hours.

The Windows NT directory is excluded from processing by aclconv, to avoid overwriting the default security created by Windows NT Setup.

Examples

To restore permissions for files transferred from the C drive on the LAN Manager server to the C drive on the destination server, where the logfile name is ACLLOG, type:

aclconv /data:aclbakc.acl /log:acllog

To view the log file created by aclconv, type:

aclconv /list /log:acllog

To restore permissions for files transferred from the C drive on the source server to the D drive on the destination server, type:

aclconv /data:aclbakc.acl /log:logfile /newdrive:d:

To merge files from two LAN Manager volumes (C and D) into a single Windows NT volume (C), type:

aclconv /data:aclbakc.acl /log:acllog

and then type:

aclconv /data:aclbakd.acl /log:acllog /newdrive:c

File and Directory Permissions Conversion

The following table shows how file and directory permissions (ACEs) map.

LAN Manager permissions	Windows NT Server equivalents
Read (RX)	Read and Execute (RX)
Write (W)	Write (W)
Create (C)	Write and Execute (WX)
Delete (D)	Delete (D)
Execute (X)	Execute (X)
Change Attributes (A)	N/A
Change Permissions (P)	Change Permissions/Take Ownership (PO)
Yes (RWCDA)	Full Control (RWXDPO)
No	No Access
If no permissions exist for the root directory, aclconv does not change this.

Interpretation of ACLs under Windows NT is order-dependent. All Access-Denied ACEs are placed before Access-Allowed ACEs. Aclconv is consistent with this convention; it inserts new Access-Denied ACEs before the first Access-Allowed ACE in the existing ACL, and new Access-Allowed ACEs at the end.

Permission Inheritance

Under LAN Manager, if a file or directory does not have a set of permissions, it uses the parent directory's permissions. If the parent directory does not have permissions, those of the drive are used (if it is a FAT drive).

Because aclconv does not determine drive permissions, it cannot preserve this behavior. Instead, when the security information for a directory is converted, it is propagated to all the files and subdirectories in that directory that do not have explicit LAN Manager security information of their own. The subdirectories in turn propagate security information to any of their subdirectories that do not have LAN Manager permissions.

If no permissions are specified in a directory tree, aclconv does not apply permissions. Newly-created files and subdirectories inherit the converted security, regardless of existing NTFS ACLs.

For example, assume that the following directory structure and permissions exist on a LAN Manager server:

K:\	No permissions
K:\LANGUAGE	Ernesta has Read permission
K:\ACCENT	No permissions
K:\LANGUAGE\DUTCH	No permissions
K:\LANGUAGE\DUTCH\TEST	Ernesta has Delete permission
After installing NT and converting the partition to NTFS, the following directories are added:

K:\ACCENT\CANADIAN	Ernesta has Read, Write, Execute, and Delete permission
K:\LANGUAGE\ITALIAN	Ernesta has Read, Write, Execute, and Delete permission
Running aclconv at this point gives the Administrators group full access to all paths and results in the following permission assignments:

K:\	Only default NTFS permissions
K:\LANGUAGE	Ernesta has Read and Execute permission
K:\LANGUAGE\DUTCH	Ernesta has Read and Execute permission
K:\LANGUAGE\DUTCH\TEST	Ernesta has Delete permission
K:\ACCENT\CANADIAN	Ernesta has Read, Write, Execute, and Delete permission
K:\LANGUAGE\ITALIAN	Ernesta has Read and Execute permission
Notice that K:\ACCENT\CANADIAN retained NTFS permissions because \ACCENT, the LAN Manager parent directory, had no permissions. However, settings for K:\LANGUAGE\ITALIAN were overwritten because converted LAN Manager permissions for the directory \LANGUAGE propagated downward.

User and Group Conflicts

Under LAN Manager, if an ACL includes an ACE that grants some set of privileges to a group and another that grants a set of privileges to a user who is a member of that group, the user receives only those privileges explicitly granted in the user ACE. In other words, if an ACE for a particular user exists on the file, that user does not benefit from membership in any groups that have access to the file.

This means that a LAN Manager permission setting that grants a user partial access should correspond to two Windows NT ACEs: an Access-Allowed ACE that grants the privileges granted under LAN Manager, and an Access-Denied ACE that denies all access except that granted by LAN Manager. However, the Windows NT file permissions editor does not accept ACEs that deny specific access; the only Access-Denied ACE it accepts is that which denies all access.

Aclconv does not generate partial Access-Denied ACEs. Instead, in the case described above, aclconv produces an ACL that combines the privileges granted directly to the user and indirectly by membership in the group.

User ID Conversion

Aclconv uses the LookupAccountName API to determine the security identifier (SID) for an ACL. The following accounts are automatically mapped to their equivalents prior to the lookup operation.

LAN Manager name	Windows NT name
Admin	Admin
Admins	Administrators
Users	Users
Guests	Guests
Note that if a trusted domain is specified as a command line option, aclconv polls the specified domain for user and group information. However, the administrator and administrators accounts are always on the local system.

Changing File Location

Aclconv supports changing files from one drive to another, provided you specify a new drive. For example, if you copy files from LAN Manager drive C to Windows NT Server drive D, you must specify D as the new destination drive using the /NEWDRIVE:drive: option.

Merging LAN Manager Directory Trees

Aclconv supports moving files from two drives onto one. However, because aclconv disregards existing Windows NT ACLs, you must be careful when you merge directory trees from two LAN Manager servers under a single Windows NT Server tree.

For example, assume you have copied directories from a LAN Manager server to a clone running Windows NT Server. Then, after running aclconv, you copy directories from another LAN Manager server to the same partition on the clone and run aclconv again. If the merger combines two LAN Manager subdirectories under a common root, and there is an ACL on the root, a set of subdirectory permissions is overwritten the second time you run aclconv.

To avoid this situation, remove ACLs from the LAN Manager root directory prior to running the backacc utility. For example, if you intend to combine LAN Manager C and D drives onto a C drive under Windows NT, remove LAN Manager permissions for C:\ and D:\. This preserves all subdirectory permissions, provided these are not directories with common names. Or, copy files and directories from various LAN Manager servers onto different Windows NT Server partitions and merge directory trees after running aclconv on each partition.


Acllist
Upgrade Utilities Reference	4 of 15

Acllist

Purpose

The acllist utility records information for files and directories on LAN Manager for OS/2 volumes. This information includes permissions for high-performance file system 386 (HPFS386) volumes, if they exist. Acllist verifies that settings are mapped according to convert and aclconv specifications (For mapping specifics, see the sections describing aclconv and convert in this chapter.)

Syntax

acllist [drive1:\subdirectory drive2:\subdirectory...][/a][/dat:filename] [/q] [/s] drive1: [drive2: drive3: ] [/?]

drive1:\subdirectory - driveN:1:\subdirectory

Specifies subdirectories to be examined, defaulting to OS/2 volumes.

/a

Tells acllist to append information to an existing file.

/dat:

Specifies the inventory filename, defaulting to ACLLIST.DAT in the current directory. If there are many files on your disk, the output of acllist may be too large for a single floppy disk.

/q

Limits screen output to status information during acllist execution.

/s

Suppresses screen output entirely during acllist execution.

drive1: - driveN:

Are the drive designations of the drives to be verified.

/?

Lists command usage.

Comments

Acllist records important file and directory information, such a file's time stamp, size, and security settings. Acllist does not report on other system resources such as named pipes or print queues.

Acllist creates an inventory file (ACLLISTdrive.DAT) that lists all resources on the specified LAN Manager drive along with their security settings. Aclcomp compares the contents of ACLLISTdrive.DAT with converted data to ensure that all settings are retained or translated appropriately to Windows NT Server.

By default, acllist acts on the entire volume. To improve speed, you can specify one or more subdirectories to work on, appending that information to the output file.

Note

When run from the command line, acllist generates the file ACLLIST.DAT unless another filename is specified.

Example

To run acllist for the E drive and specify a filename in the current directory, type:

acllist /dat:aclliste.dat /q e:

To run acllist in "quiet mode" and direct output to the D:\UPGRADE directory, type:

acllist /dat:d:\upgrade\acllistc.dat /q c:

To run acllist on one or more root-level subdirectories instead of on an entire volume, type:

acllist c:\programs c:\projects /a


Backacc
Upgrade Utilities Reference	5 of 15

Backacc

Purpose

Backacc is a LAN Manager utility that backs up the permissions for high-performance file system 386 (HPFS386) volumes, and backs up the NET.ACC and NET.AUD files.

Syntax

backacc [drive:]pathname [/f:[drive:]target][/a] [/s]

drive:

Is the drive letter for the directory.

pathname

Is the directory or file whose permissions are to be backed up. If drive and pathname are omitted, only the NET.ACC and NET.AUD files are backed up (not file permissions).

/f:target

Is a target file used to store the access control list information. If target is not an absolute path, the default directory is the current working directory. If target is not specified, the target is \LANMAN\ACCOUNTS\ACLBAKd.ACL, where d is the drive letter of the volume being backed up.

/a

Appends access permissions to an existing backup file.

/s

Is valid only if pathname is a directory. When pathname is a directory, /s recursively backs up permissions for all subdirectories and files under pathname.

Comments

Backacc extracts file and directory permissions (access control list information, or ACLs) associated with the files and directories on HPFS volumes and writes that information to files as follows:

Copies of NET.ACC are written to \LANMAN\ACCOUNTS\NETACC.BKP. (The Upgrade Manager program copies this file to the UPGRADE directory.)

Copies of NET.AUD are written to \LANMAN\LOGS\NETAUD.BKP. This file is not relevant to the upgrade.

ACLs are written to a file called ACLBAKdrive.ACL, or to a file specified using the /f: target switch. The aclconv utility uses this file to duplicate file and directory permissions on NTFS drives.

ACLs are written to a file called ACLBAKdrive.ACL, or to a file that you specify using the /f:target switch. You will be using the information contained in the ACLBAKdrive.ACL file to duplicate file and directory permissions on newly converted NTFS volumes.

You must run backacc once for each partition you want to upgrade. For example, if you are migrating all the data on your D drive but only a portion of your C drive, you will run backacc twice, using the pathname parameter to specify the drive or directory tree you want copied. For example, you don't need to back up permissions on OS/2 system files because they are no longer needed under Windows NT.

Examples

To back up NET.ACC and extract permissions from the files on a C volume, placing them in ACLBAKc.ACL, type:

backacc c:\  /s

If you have two volumes, C and D, type:

backacc c:\  /s

and then:

backacc d:\  /s

which produces NETACC.BKP, ACLBAKc.ACL, and ACLBAKd.ACL.

To back up only NET.ACC, type:

backacc

For more information about using backacc, consult the LAN Manager Administrator's Guide.


Backat
Upgrade Utilities Reference	6 of 15

Backat

Purpose

Backat reads the SCHED.LOG file on a LAN Manager for OS/2 server and generates a batch file containing scheduled commands and programs, if they exist. When this batch file runs under Windows NT, it writes the at commands into the Registry provided the Schedule service is running.

Syntax

backat filename [/?]

filename

Is the name of the batch file that will contain at commands found in the SCHED.LOG file.

/?

Lists command usage.

Comments

Under LAN Manager, scheduled commands are stored in the server's \LANMAN\LOGS\SCHED.LOG file, so scheduled tasks are not lost if you have to restart the server. Backat reads the binary file SCHED.LOG, interprets the commands there, reprocesses the output, and writes the commands to RESTAT.CMD or to a user-specified filename.

If there are no entries in SCHED.LOG, no file is generated. To generate an entry, log on to the LAN Manager server with administrative privileges and type:

at 1:01 /every:m,t,w,th,f "dir c:\"

Example

To write schedule commands to the batch file RESTAT.CMD, type:

backat restat.cmd

To write schedule commands to the batch file SCHED.CMD, type:

backat sched.cmd


Backenv
Upgrade Utilities Reference	7 of 15

Backenv

Purpose

The upgrade process uses the backenv utility to back up LAN Manager environment settings to a file called LMBAKENV.DAT. The restenv utility restores relevant LMBAKENV.DAT settings under Windows NT Server.

Syntax

backenv [drive:] [/uif] [/noaclbak] [/nonetacc] [/noinis] [/?]

drive:

Is the target drive for backenv output. The default drive is A. Backenv creates an \UPGRADE directory on the target drive and writes output into the directory.

/uif

Creates a file called OS2.UIF that is an inventory of hardware settings. This file can be used by Microsoft support services to check for errors.

/noaclbak

Prevents backenv from copying ACLBAKdrive.ACL.

/nonetacc

Prevents backenv from copying NETACC.BKP.

/noinis

Prevents backenv from copying *.INI files.

/?

Lists command usage.

Comments

Backenv execution consists of the following stages:

Initialization

During initialization, backenv checks for various system components, such as fault tolerance, the LADDR I/O system, the server service and whether the current account has administrative privileges. It also checks for any predictable installation problems, such as insufficient disk space and unknown devices. Backenv will not prevent an upgrade even if it detects apparent configuration problems. Note that backenv ignores drives formatted as NTFS.

Inventory collection

During this stage, backenv collects inventory settings for three components: OS/2, the hardware, and LAN Manager.

Note

Backenv cannot detect tape and CD-ROM drives on non-LADDR computers. Consequently, these drives do not appear in the ADVISORY.TXT file.

File copying

Backenv creates the UPGRADE directory and copies the following files into it:

LANROOT\*.INI as well as CONFIG.SYS, STARTUP.CMD, and PRIVINIT.CMD (these files are for informational purposes)

LANROOT\ACCOUNTS\ACLBAKdrive.ACL

LANROOT\ACCOUNTS\NETACC.BKP

LANROOT\ETC\HOSTS and LMHOSTS, if TCP/IP is present

The UPS command file, if present

LMBAKENV.DAT generation

If a user specifies the /UIF switch, backenv creates an ASCII file called OS2.UIF. This file contains hardware inventory settings and can be used by Microsoft support services to diagnose errors.

Upgrade file generation

Backenv uses LANMAN.INI, PROTOCOL.INI, CONFIG.SYS and various LAN Manager APIs to obtain the information that it writes to LMBAKENV.DAT. If an entry for a particular service, such as remote access, does not appear in LANMAN.INI, it will not appear in LMBAKENV.DAT. Like LANMAN.INI, LMBAKENV.DAT only contains values if they vary from default LAN Manager values. Default LAN Manager settings automatically translate to the equivalent default setting under Windows NT Server.

SFMCONV.RUN generation

If backenv detects Services for Macintosh, it generates SFMCONV.RUN, a file whose presence causes the Windows NT Server Upgrade Manager to include sfmconv in the Express Upgrade Schedule. SFMCONV.RUN also contains the location of the LANROOT directory. SFMCONV.RUN is not required for sfmconv to run.

Advisory file generation

ADVISORY.TXT describes configuration settings. It includes:

A list of hardware components, such as disk drives and controllers, tape drives, and network cards.

Hardware settings, such as network card interrupt numbers and printer port settings.

Network information such as the computer name, domain name, and username.

A list of modem settings read from COMDEV.INI, if Remote Access Service is installed.

A list of printers, printer queue names, and printer queue settings.

A list of active LAN Manager services.

A list of any errors that occurred during backenv execution.

Note that when backenv reads LANMAN.INI and other configuration files, it collects all available information; it does not interpret data. This means that LMBAKENV.DAT may contain parameters that are not relevant to Windows NT.

For more information on possible entries in the file LMBAKENV.DAT, See Appendix D, "The LMBAKENV.DAT File."

Network Card Comparison

During the creation of LMBAKENV.DAT, backenv checks network card information and determines if an equivalent card exists under Windows NT. If so, backenv lists the card name in ADVISORY.TXT. Backenv uses the following lookup table to identify equivalent adapter card drivers under Windows NT. This comparison is for advisory purposes only.

OS/2 adapter card driver		Equivalent Windows NT adapter
3Com® 3C523 EtherLink®/MC Adapter		Elnkmc
3Com EtherLink II® (3C503)		Elnkii
3Com EtherLink III (3C509)		Elnk3
3Com EtherLink16/EtherLink16 TP Adapter		Elnk16
AMD AM2100/AM1500T/PCnet Adapter		Am1500t
COMPAQ® 32-Bit DualSpeed Token-Ring Controller		NETFLX
COMPAQ 32-Bit NetFlex Controller		NETFLX
DayStar Digital LocalTalk Adapter		lt200
DEC® EtherWorks™ LC		Lance
IBM Token Ring Adapter		IbmTok
Intel Ether Express™ 16 LAN Adapter		EE16
Network Peripherals FDDI EISA Adapter		NPEISA
Novell® NE1000 Adapter		NE1000
Novell NE2000 Adapter		NE2000
Novell NE3200 EISA Adapter		NE3200
Proteon P1390		Proteon
Proteon P1990 Adapter		Proteon
SMC® (WD) Adapter Driver		SMC8000N
Ungermann-Bass® Access/PC-16		UB
Ungermann-Bass NICps/2		UB
Ungermann-Bass NIUpc (PC2030)		UB
Examples

To direct the output of backenv to the C:\UPGRADE directory, type:

backenv c:

To have backenv generate only LMBAKENV.DAT and a UIF file in A:\UPGRADE, type:

backenv /noinis /noaclbak /nonetacc /uif


Convert
Upgrade Utilities Reference	8 of 15

Convert

Purpose

The Windows NT convert utility converts FAT, HPFS, or HPFS386 volumes into NTFS volumes.

Syntax

convert drive: /fs:targetfilesystem [/name-table:filename[/?]

drive:

Is the path of the drive to convert.

targetfilesystem

Is the file system to convert to. The default is NTFS.

/?

Lists command usage.

Comments

Convert operates on any volume to which it can gain exclusive access. If the utility cannot gain exclusive access to a volume, it offers to convert the next time you start your system. When you select this option, convert adds appropriate entries to the Windows NT Registry to force conversion after reboot.

Convert preserves all user file data and extended attributes (EAs) on a volume. Internal file-system data is not preserved. In particular, the FAT extended attributes file, EADATA.SF, is discarded; however, its contents are preserved as extended attributes attached to files on the NTFS volume. Convert also preserves volume labels and serial numbers.

Convert gives ownership of the root directory and of all converted files and directories to the Administrators group. It also creates an ACL for each file and directory that grants full access to everyone. HPFS386 permissions are discarded and must be reassigned using the aclconv utility.

When convert runs during system initialization, it uses a version of convert called autoconv. Autoconv automatically calls autochk (the system initialization version of chkdsk).

If autoconv fails, you can look in the event viewer for more details; look in the application log under WINLOGON. If autoconv fails because it can't convert a file with illegal names, you can run convert with the /name-table:filename option prior to running autoconv.

Conversion Requirements

Convert has the following requirements:

Drives must be local; remote drives are not supported.

This includes the system (boot) volume and any volume containing a paging file. Convert does not operate on the current drive.

Volumes must be consistent.

The LAN Manager utility chkdsk must not report errors on a volume. If convert can gain exclusive access to the volume during system initialization, convert (autoconv) invokes autochk (without the /f parameter) and does not proceed if errors are found. If convert is unable to lock a drive for conversion, it offers to convert it the next time the computer starts.

Free space must be adequate.

Convert requires free space equal to approximately 10% of occupied space on a drive. The utility estimates the minimum amount of free disk space needed to complete a conversion and proceeds only if adequate free space is available.

If convert fails because of insufficient memory, it will leave the volume in its original state. Chkdsk may be needed to restore the volume to a consistent state, but no data will be lost. Convert is able to perform without a swapping file.

How the Conversion Process Works

The conversion process consists of two stages: preparation and conversion. Each stage performs a specific transformation on a volume. Following is a description of each conversion stage.

Preparation

This stage prepares the current file system. Usually this involves shuffling the file system structure around in order to create zones of free space at specific physical locations on the volume. This stage creates free space only in those sectors that are absolutely required by the target file system. Data structures that should be in certain locations for performance reasons are not taken into account.

Preparation consists of three steps:

Free space estimation

If 50% or more of the disk is free, convert assumes that free space is adequate. Otherwise it gathers information (the number of files, number of extended attributes, and so on) which it then uses to estimate the amount of free space required for conversion. Conversion only proceeds if enough free space is available.

Remapping free space

Convert creates free space at specific locations. This is done by moving the data at those locations to other places (currently free) on disk. If a failure occurs during this process, no harm is done because the existing file system data structures, such as links and directories, have not been modified.

Overwriting the file system's data structures to reflect space changes

If a failure occurs during this process, autochk can restore the volume to a consistent state without loss of data.

Conversion

This stage converts the volume to the specified file system. During this process, all target file system data structures are created in the free space established in the preparation stage, so that if a failure occurs the volume is still consistent and convert can start over.

At the end of the process, the NTFS boot sector is written to the proper places on the drive. If a failure occurs at this point, autochk restores the disk to the original file system with its data intact.

Examples

To convert the C partition to NTFS, type:

convert c: /fs:ntfs

or:

convert c:

To convert a filename with illegal characters, type:

convert /name-table:filename


Hcopy
Upgrade Utilities Reference	9 of 15

Hcopy

Purpose

The upgrade uses the LAN Manager OS/2 hcopy utility to transfer files across the network. Hcopy is a modified version of the xcopy command capable of preserving hidden files and directories, and automatically preserves extended attributes (additional file information such as file type, creator, and so on). It does not copy system files.

Syntax

hcopy [source] [destination] [/f] [/v] [/e ] [/s] [/p] [/a] [/m] [/d:date]

source

Specifies the location and names of the files you want to copy. Source must include either a drive or a path.

destination

Specifies the destination of the files you want to copy.

/f

Checks that the destination drive supports extended attributes. If extended attributes are not supported, hcopy does not copy files.

/v

Verifies each file as it is written to the destination file to make sure that the destination files are identical to the source files.

/e

Copies empty directories.

/s

Copies directories and subdirectories unless they are empty. If you omit this option, hcopy works within a single directory.

/p

Prompts you to confirm that you want to create each new file.

/a

Copies files that have their archive bits set, without modifying the archive bit of the original file.

/m

Copies files that have their archive bits set and turns off the archive bit of the original file.

/d:date

Copies files that were modified on or after the specified date. The format of date depends on the country code you are using; the default format is mm-dd-yy.

Comments

Extended attributes are sometimes used by an application, file system, or operating system to identify file type. Services for Macintosh requires that files have extended attributes. Whenever possible, use hcopy to transfer files to a clone computer.

Note that after using hcopy to transfer directories to a clone, the aclcomp utility reports a mismatch in directory creation time. This reflects the difference between actual directory creation time under LAN Manager and the time it was copied to the clone. No action is needed.

The Upgrade Manager copies files using the hcopy utility with the following options: /f to ensure that the destination volume supports extended attributes, /e to copy empty directories, /v to verify transfer, and /s to copy subdirectories. System files are not copied.

Note

Windows NT does not support discontiguous extended attributes that may have been written to disk by OS/2. If you use Windows NT to copy files from an HPFS drive formatted by OS/2 to another location on the same or a different drive, all discontiguous extended attributes are lost. This is not a problem if you back up using Sytos Plus and restore using Windows NT Backup, or if you copy files across a network connection. Note that extended attributes are only important if you are upgrading Services for Macintosh.

Example

To copy volume K to volume L, including subdirectories, empty directories, file attributes, and copy verification, type:

hcopy k: l: /f /e /s /v


Portuas
Upgrade Utilities Reference	10 of 15

Portuas

Purpose

The portuas utility restores the user and group accounts of a LAN Manager server onto a Windows NT computer.

Syntax

portuas /f filename [/u username] [/v] [/?] [log filename]

/f filename

Specifies the path and filename of the LAN Manager 2.x NETACC.BKP file, which contains user account information. NETACC.BKP is created by running the LAN Manager backacc utility.

/log filename

Creates a log file in the current directory.

/u username

Specifies a single user or group to restore. The default is for all users and groups to be converted.

/v

Specifies verbose mode.

/?

Lists command usage.

Comments

Portuas merges a LAN Manager user accounts database (UAS) including remote access accounts, with an existing Windows NT Server security database by reading information from the NETACC.BKP file (generated by the backacc utility).

When a user or a group name in a LAN Manager domain matches a group on the destination Windows NT computer or the domain name of the destination system, portuas prompts you to decide whether to change the conflicting name, leave it as is, or skip it entirely. After you decide, the merge continues with the remaining users or groups.

To use portuas, you must be a member of an Administrator group and the Server and Net Logon services must be running on the Windows NT computer. If the file PORTUAS.LOG already exists, portuas will not run. Rename or delete the file.

Note that when you use the /u option to add a single user, in addition to transferring the specified user, portuas transfers all LAN Manager group names to Windows NT Server. For example, "portuas /f netacc.bkp /u pamsw" results in the following:

All groups listed in NETACC.BKP are added to the Windows NT security database.

The user pamsw is added with her group membership preserved.

If the groups or the user pamsw already exist, portuas overwrites previous information, which in the case of groups is a remark entry.

User Account Conversion

The following table shows how user account information is mapped to Windows NT Server.

LAN Manager user account entries		Windows NT Server equivalents¹
Account Name		Username
Password		Password
Full name		Full name
Comment		Description
Disable account		Account disabled
User comment		User comment (available only with Net User command)
Country code		Country code (available only with Net User command)
Groups		See "Group Conversion"
Logon hours		Logon hours
Account expires		Account expires
Valid workstations		Logon workstations
Logon server		N/A
Logon script path		Logon script path
Home directory path		Home directory path
User storage limit		N/A
¹  Except where noted, equivalents appear in the User Manager for Domains tool.

Note that portuas overwrites the Guest and Admin user accounts existing under Windows NT with LAN Manager account information.

Group Conversion

The following table shows how portuas maps default LAN Manager groups to Windows NT Server. Nondefault groups become new domain groups in the domain user accounts database.

LAN Manager default group	Windows NT Server group
Admins	Domain Admins
Users	Domain Users
Guests	Domain Guests
Servers	Servers
Account Operators	Account Operators¹
Print Operators	Print Operators¹
Server Operators	Server Operators¹
Comm Operators	N/A
Local	N/A

¹  These groups are local groups; the others are global.

If a LAN Manager account specifies a Macintosh Primary Group, portuas carries over this designation. A primary group is relevant for Windows NT Services for Macintosh and for POSIX applications.

The Conversion Process

Portuas conversion consists of the following steps:

Opening and validating the LAN Manager UAS database.

Reading each group from the UAS database.

If a group does not exist under Windows NT Server, adding the group to the Windows NT security database using the NetGroupAdd API. If the group already exists (for example, the default ADMIN group), portuas updates the group comment using the NetGroupSetInfo API.

If the group name matches an existing user name or local group name, portuas prompts the user to decide whether to change the conflicting name, leave it as is, or skip it entirely.

Copying the group name into a group table entry so that portuas can refer to the group later to add members.

Reading each user from the UAS database and adding the user to the security database using the NetUserAdd API. If the same user exists in the security database, portuas updates the user attributes using the NetUserSetInfo API.

Adding users to appropriate groups using the NetGroupAddUser API.

Setting global account policies such as minimum password length, from the UAS database.

Closing the UAS database.

Merging Multiple User Account Databases

Multiple LAN Manager user account databases (NETACC.BKP files) can be merged into a single Windows NT Server user account database. To do this, each NETACC.BKP (or NET.ACC) file from the LAN Manager domain that you want to merge must be copied to the Windows NT Server domain that it is to be merged with. (Note that you can give each file a different name.) After you have copied all the NETACC.BKP files to the computer running Windows NT Server, run the portuas utility separately on each file to merge it with the Windows NT Server user account database.

If a user account occurs in more than one of the NETACC.BKP files, the last account's information will supersede information in previous accounts. For example, if CHRISDR has an account in two LAN Manager domains that have been merged into a single Windows NT Server domain, CHRISDR will have a single account with the password that applies to the most recently converted user account database.

Use caution here because any groups from the LAN Manager domains that have the same names will be merged into a single group with that name in the Windows NT Server domain. If this is not what you want, you can merge a NETACC.BKP file, rename the group whose name matches that in another LAN Manager domain, and then merge the next NETACC.BKP file. You can continue this until all of the LAN Manager user account databases have been merged.

Examples

To merge a LAN Manager user account database into a Windows NT user account database, type:

portuas /f a:\lanman\accounts\netacc.bkp /v

To add the user account JEFFHO from a LAN Manager user account database to a Windows NT computer, type:

portuas /f a:\netacc.bkp /u jeffho


Restenv
Upgrade Utilities Reference	11 of 15

Restenv

Purpose

The restenv utility uses the file LMBAKENV.DAT, created by the backenv utility, to write applicable configuration information into the Windows NT Server Registry.

Syntax

restenv source file [/noalerter] [/nocountry] [/nonetlogon] [/nonetworks] [/noprotocol] [/noras] [/noreplicator] [/noshare] [/nouses] [/noworkstation] [/noserver] [/nosnmp] [/noups] [/test] [/noverbose] [/?]

source file

Is the name of the file created by backenv. If not specified, restenv attempts to read LMBAKENV.DAT in the current directory.

/noalerter

Do not restore alert service settings.

/nocountry

Do not restore country code setting.

/nonetlogon

Do not restore Netlogon service parameters.

/nonetworks

Do not restore network parameters.

/noprotocol

Do not restore protocol settings.

/noras

Do not restore Remote Access Service parameters.

/noreplicator

Do not restore Replicator service parameters.

/noshare

Do not restore sharenames.

/nouses

Do not restore network connections.

/noworkstation

Do not restore Workstation service parameters.

/noserver

Do not restore Server service parameters.

/nosnmp

Do not restore SNMP service parameters.

/noups

Do not restore UPS service parameters.

/test

Runs diagnostics only; does not change system settings.

/noverbose

Do not echo complete information to the screen.

/?

Lists command usage.

Comments

Restenv uses the file created by backenv (LMBAKENV.DAT) to restore whatever parameters were not set during Windows NT Setup.

The following table shows how restenv handles LMBAKENV.DAT parameters.

LMBAKENV.DAT parameter group	Action by restenv utility

[workstation]	Writes applicable settings to Registry and attempts to start service.

[server]	Writes applicable settings to Registry and attempts to start service.

[ups]	Writes applicable settings to Registry and sets service to start automatically. If UPS command file is in the UPGRADE directory, copies it to \WINNT\SYSTEM32\DRIVERS\ETC.

[netlogon]	Writes applicable settings to Registry and attempts to start service.

[alerter]	Attempts to start service (no settings applicable).

[replicator]	Writes applicable settings to Registry and sets service to start automatically. Assigns permissions to REPL$ and restores replication and logon script paths under Windows NT. If the logon script path and/or the replication paths are relative, restenv moves the appropriate directories and files and modifies ACLs appropriately. These changes are recorded in the file RESTENV.DAT, which is used by aclcomp to verify proper ACLs. See "Restoring Replication and Logon Scripts," later in this section.

Also moves import server accounts from the LAN Manager group "rep" to the Windows NT Server group Replicator.

[remoteaccess]	Writes applicable settings to Registry if Remote Access Service is installed.

[snmp]	Writes applicable settings to Registry if SNMP installed. Attempts to start service.

[timesource]	If timesource server, restenv adds the key "TimeSource" to the Registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters.

[protocol 1, 2...n]	Checks for existing protocol. If NetBEUI is installed, restenv upgrades settings. For TCP/IP, AppleTalk, and DLC protocols, restenv compares Windows NT settings with the original LAN Manager values. If a discrepancy exists, restenv notes it in RESTENV.LOG. Note that the value of one TCP/IP parameter (ScopeID) is transferred.

[netcard 1,2]	In RESTENV.LOG, lists adapter card driver name for LAN Manager and Windows NT configurations.

[shares]	Compares shares listed in LMBAKENV.DAT with existing shares on Windows NT Server. If there is a mismatch between an existing and a requested sharename and/or pathname, restenv writes an error message to RESTENV.LOG but does not make a change to the share. If no conflicts exist, restenv creates equivalent shares. Note that share permissions are not transferred.

[uses]	Compares persistent connections listed in LMBAKENV.DAT with existing connections. If there is a drive letter conflict, writes an error message to RESTENV.LOG but does not make a change to the connection. If no conflicts exist, restenv creates uses under Windows NT.

[countryinfo]	Checks to see if country code in LMBAKENV.DAT matches locale specified during Windows NT installation. Writes county code, country name and locale code to the log file and indicates if existing code is correct.

Restenv also configures the Windows NT Schedule service to start automatically. For a complete list of settings transferred by restenv, see the sample LMBAKENV.DAT file in Appendix D, "The LMBAKENV.DAT File."

The restenv utility performs the conversion of replication parameters, including the replication and logon script paths. Depending on the desired replication configuration, after completing the upgrade you may need to perform additional configuration tasks. See Chapter 5, "Completing the Upgrade," for more information.

Note

When establishing or converting replication paths, replication subdirectories, and logon script paths, remember that for Windows NT the maximum allowable path (including filename) is 255 characters, while for LAN Manager the maximum allowable path is 264 characters.

Example

To restore LMBAKENV.DAT parameters from a floppy disk in your B drive, type:

restenv b:\lmbakenv.dat


Sfmconv
Upgrade Utilities Reference	12 of 15

Sfmconv

Purpose

The sfmconv utility restores Macintosh volumes to Windows NT Server.

Syntax

sfmconv [ntfs drive:] [/SCRIPT:filename] [/v][/LOG:logfile] [lanroot][/?]

ntfs drive:

Causes only Services for Macintosh volumes located on that drive to be converted. If this option is not specified, all Macintosh volumes on all drives are converted.

/SCRIPT:filename

Specifies the location of a file that contains the LAN Manager root directory. If not specified, the default file name is SFMCONV.RUN. This file is created by the backenv utility if Services for Macintosh is present on a LAN Manager volume.

/log:logfile

Specifies a log file for status and error messages and warnings.

/v

Gives verbose output. Message are displayed for all file and directory conversions. If -v is not specified, only a summary of the total number of files and directories is printed.

lanroot

Specifies location of LAN Manager root directory (C:\LANMAN by default).

/?

Lists command usage.

Comments

To convert Services for Macintosh, you must preserve Macintosh volume structure exactly as it is under LAN Manager. The volume to be converted must have the same structure as the source LAN Manager for Macintosh volume. All partitions must be NTFS and Services for Macintosh must be installed. Sfmconv operates only on NTFS volumes.

Conversion Rules

Sfmconv upgrades Macintosh volumes to Windows NT as follows:

Equivalent volumes are created automatically and volume passwords are preserved.

Extended attributes are read, and the values are used, but they are not erased.

Wherever file and directory access permissions are found for the group Guests, they are duplicated for the group Everyone.

Note

If the Services for Macintosh Guest account is not enabled under LAN Manager, sfmconv does not transfer permissions for the group Everyone.

If See Files permission is allowed for a user, group, or Everyone, but See Folders is not, then sfmconv adds the RX (read and execute) permissions. This is necessary so that the same finder permissions will be available under Windows NT Services for Macintosh. The same is done if See Folders is allowed but See Files is not. RX is not necessary if both See Files and See Folders are allowed.

Comments attached to files and folders are preserved, as are comments attached to non-root directory volumes. Comments attached to root directory volumes (evol=e:\) are not preserved.

Note

If the Admins group is specified in the Macintosh permission matrix and the privileges are restricted to read-only, write-only, or no access, sfmconv revokes certain administrator permissions. This is because by default, aclconv gives the Administrators group all permissions on all files and directories. Sfmconv revokes some of the permissions so that access matches that specified by Macintosh permissions.

The Conversion Process

During conversion to Windows NT Services for Macintosh, sfmconv attempts to convert each file and directory of each Macintosh volume. Each directory is processed completely before attempting another directory. Subdirectories are processed prior to directories at the same level. After file and directory information is converted, files and directories are renamed from their "host" names ( MS-DOS 8.3 format) to Macintosh names, which can be considerably longer.

LAN Manager for Macintosh stores information about files and directories in a hidden directory (\~AFP). The ~AFP directory contains file resource forks, which contain Macintosh operating system resources, such as code, menu, font, and icon definitions. The ~AFP directory also contains FILEINFO.AFP, and the ~I directory. If AFPINFOINEAS=NO in the [macfile] section of LANMAN.INI, sfmconv uses information in the ~I directory. Otherwise, it uses information stored in the extended attributes attached to the files and directories. After sfmconv successfully converts volumes, it deletes the ~AFP and ~I directories and any other LAN Manager for Macintosh Services configuration files.

Sfmconv converts the information stored in ~AFP and ~I files, in extended attributes, and in various configuration files into NTFS streams. Streams are very similar to extended attributes under LAN Manager. They represent information associated with a file or a directory, but not contained within the file or directory.

Sfmconv generates the following streams:

:AFP_Resource, the resource fork for each Macintosh file that exists

:AFP_AfpInfo, information for each file and directory, such as its location and privileges

:AFP_DeskTop, which holds application and icon information

:AFP_IdIndex, which holds directory structure information

:Comments, comments from extended attributes, attached to each file or directory

Sfmconv also generates the file SFMCONV.DAT in UNICODE format. SFMCONV.DAT is used by aclcomp to verify file permissions on Macintosh volumes.

Required Files

SFMCONV uses the following files: SFMCONV.EXE, LANMAN.INI, SRVAUTO.PRO, CONFIG.AFP, CONFIGSV.AFP, USERINFO.AFP, USERBACK.AFP, DESKTOP.AFP, DIRID.AFP, VOLINFO.AFP, FILEINFO.AFP. If they are not available, it checks *.BAK files. Some files such as DESKTOP.AFP are optional; if they are missing sfmconv still attempts to convert the volume.

If volume conversion is successful, sfmconv attempts to delete these files, including the *.BAK versions.

Example

To convert only volumes C and D to Windows NT Services for Macintosh, where LAN Manager files are located in the C:\LANMAN directory, type:

sfmconv c

and then:

sfmconv d


Userconv
Upgrade Utilities Reference	13 of 15

Userconv

Purpose

Userconv enables you to map LAN Manager user accounts to accounts in trusted domains. It is used in place of the portuas utility. For a complete discussion of how and why you use userconv, see Chapter 6, "Upgrading to a Trusted Domain Model."

Syntax

userconv

Comments

Userconv runs only on Windows NT Server, not on Windows NT Workstation.

How the Userconv Process Works

Userconv execution consists of four stages: preparation, account and local group mapping, conversion, and output file creation.

Preparation

After you invoke the utility and select the appropriate NETACC.BKP file, userconv loads NETACC.BKP into memory and checks the network for trusted domains. If trusted domains exist, userconv displays them in the Trusted Domain box. Userconv then browses the local domain for groups and users, and displays them in the LAN Manager Accounts dialog box.

When you select a local or trusted domain, userconv looks in that domain for groups and accounts. This information is retained in memory should a user reselect the domain later in the session.

Account and Local Groups Mapping

When you choose the Auto Map button, userconv checks for matches between users and groups in the selected domain. It also records associations created when you choose Manual Map or add a local group. Userconv does not implement these changes until you choose the Convert button.

Conversion

Userconv's first step in this stage is to create local groups under Windows NT Server. Before creating groups, it checks to see that they don't already exist.

Userconv then checks to see if users in each group are mapped to an existing Windows NT account. If so, it retains the user in the group, using his or her Windows NT user account name. If not, the name is dropped.

For each user name specified in that file, it checks to see if mapping was specified. If so, it replaces the LAN Manager name with the mapped Windows NT username in a binary file it creates called ACLWORK.DAT.

File Creation

Userconv creates three files: ACLWORK.DAT, USERWORK.DAT and USERCONV.LOG. Aclconv checks ACLWORK.DAT (if it exists) to determine correct permission mapping. USERWORK.DAT is used by aclcomp to help it verify security changes. USERCONV.LOG contains a list of mapped user accounts and local groups.

Example

This starts the Windows NT utilities, userconv.

userconv


Xcopy
Upgrade Utilities Reference	14 of 15

Xcopy

The Windows NT xcopy command can also be used to restore files. Xcopy automatically preserves extended attributes as well as copies system files. Do not use the OS/2 xcopy command to transfer files as part of an upgrade.

Syntax

xcopy [source] [destination] [/e] [/f] [/h] [/k]

/e

copy subdirectories, including empty ones

/f

display source and destination filenames while copying

/h

copy files with hidden and system attributes

/k

copy attributes (read-only, archive, etc.)

Comments

Xcopy can be used to transfer files by running it from the Windows NT Server computer and copying files from the LAN Manager Server that you are upgrading. However, hcopy should be your first choice to use; LAN Manager OS/2 hcopy has been specially configured for the needs of the upgrade.


Upgrade Log Files
Upgrade Utilities Reference	15 of 15

Upgrade Log Files

The upgrade process generates various log files that contain advisory and status information as well as error explanations. Log files are saved to the \UPGRADE directory. If an error message appears during the upgrade process, check the log file for the Upgrade Manager program and/or utility that was running at that time.

The following table lists log files associated with the upgrade programs.

Upgrade program/ utility	Advisory or log file		Description		Created automatically?		How to read file
backenv	ADVISORY.TXT		Hardware configuration information and advice regarding Windows NT Server installation.		Yes		View from the Upgrade Manager programs or use text editor.
restenv	RESTENV.LOG²		Lists successful and unsuccessful attempts to upgrade configuration settings.		Yes		Use text editor.
userconv	USERCONV.LOG		Lists mapped and unmapped accounts.		Yes		Use text editor.
portuas	PORTUAS.LOG		Lists successful and unsuccessful conversion of users and groups.		You must specify /LOG: option when running portuas from command line.		Use text editor.
aclconv	ACLBAKdrive.LOG³		Binary file that lists successful and unsuccessful file permissions restoration.		You must specify /LOG: option when running aclconv from command line.		Use /LIST option as follows: aclconv /LOG:logfilename /list.
sfmconv	SFMCONV.LOG³		Text file containing status and error messages for Services for Macintosh conversion.		User must specify /LOG: option when running sfmconv from command line.		Use text editor.
aclcomp	ACLCOMP.LOG		Text file that lists successful and unsuccessful file permission transfers.		Yes. User must specify /LOG: option to specify log file name and location. Otherwise defaults to ACLCOMP.LOG in current directory.		Use text editor.
LAN Manager Upgrade Manager	LMUPMGR.LOG²		Lists errors encountered during upgrade process.		Yes		Use text editor.
Windows NT Server Upgrade Manager	WNTUPMGR.LOG²		Lists errors encountered during upgrade process.		Yes		Use text editor.
¹  If a utility is run from the Express Upgrade Manager configuration, a log file is automatically created.

²  Old log files are preserved.

³  Upgrade Manager default name for log file.


Differences in Administering LAN Manager and Windows NT Server
Appendix A	1 of 16

Differences in Administering LAN Manager and Windows NT Server

This appendix reviews basic differences that you will encounter in day-to-day management of a LAN Manager and a Windows NT Server network. These differences include how people are designated as administrators and operators, how security works, how resource permissions transfer, and file replication. For additional information, see Appendix B, "How LAN Manager Network Parameters Map to Windows NT" and Appendix C, "Command, Utility, and API Compatibility."


Administrators and Operators

Differences in Administering LAN Manager and Windows NT Server	2 of 16

Administrators and Operators

Windows NT Server and LAN Manager both support administrators and operators. Administrators are the people responsible for setting up and managing the network; they are allowed to configure the network and access all network resources. Operators are users with authority to perform a limited number of administrative tasks. Operators have more power on the network than regular users, but less power than full administrators.

With LAN Manager, you give administrator status (called admin privilege) to a user by giving the user's account the Admin privilege level. Each LAN Manager user account has one of three privilege levels - Admin, User, or Guest. All users whose accounts have Admin privilege are administrators and have full administrative power on the server.

With Windows NT Server, you give administrator status to a user by assigning the user to the Administrators group. Each Windows NT Server user account is assigned to one or more groups - Administrator, User, Guest, Server Operator, Account Operator, Print Operator, Backup Operator, and Replicator. All users in the Administrators group are administrators and have full administrative power over the system.

With LAN Manager, you make someone an operator by assigning operator privilege in his or her user account. With Windows NT Server, you make someone an operator by putting him or her in one of the operator groups using the User Manager for Domains tool.

The following table shows the types of operators in each system, explains the abilities of each type, and shows similarities to the other system, if any.

Operators

LAN Manager	Windows NT	Abilities

Server 	Server	Can perform some server management tasks, such as stopping services on the server or shutting it down entirely, and can view information about the server and the connections to it.

Print	Print	Can manage printers and print jobs, changing the order of jobs or deleting them.

Accounts 	Accounts	Can manage and modify user accounts. With LAN Manager, Account Operators can manage all user accounts (except admin accounts) on the server or in the domain and can also create new accounts. With Windows NT, Account Operators can manage all the server's user and group accounts except the user accounts of Administrators and the local groups of Administrators, Server Operators, Account Operators, Print Operators, and Backup Operators. Account Operators cannot assign user rights.

Comm	N/A	Can manage communication-device queues and requests, changing the order of requests or deleting them. Windows NT does not support communication-device queues or comm operators.


Administration and Configuration Tools

Differences in Administering LAN Manager and Windows NT Server	3 of 16

Administration and Configuration Tools

You can use a single tool to perform most administrative tasks with LAN Manager: the Net Admin interface. In contrast, Windows NT Server provides a group of tools for managing the network, including User Manager for Domains, Server Manager, and Disk Administrator. (For a complete list of administrative tools, see the Windows NT Server System Guide.)

To administer a mixed domain, you can use either a server running Windows NT Server or LAN Manager. However, computers running Windows NT Workstation and Windows NT Server cannot be managed by non-Windows NT computers.

Windows NT Server stores configuration information in a database called the Registry that is organized in a tree format. The Registry replaces all LAN Manager configuration files including CONFIG.SYS, STARTUP.CMD, and all .INI files. Users generally don't view the Registry directly, because most values can be set using Windows NT Server administrative tools. However, an experienced user can use the Registry Editor (REGEDT32.EXE) to directly inspect and modify the Registry.


Security

Differences in Administering LAN Manager and Windows NT Server	4 of 16

Security

LAN Manager has two levels of security: user-level security and share-level security. Each server running LAN Manager uses one of these two levels, and servers that have user-level security can be on the same network and in the same domain with servers that have share-level security.

With LAN Manager share-level security, users don't have accounts. Instead, the administrator gives each resource a different password. To access a resource, users have to know the password.

Windows NT builds on the security features available with LAN Manager. With Windows NT Server, users have accounts on all the servers they need to access. When a user tries to access a resource on a server, the server first compares the password the user types with the password in the user's account. If the passwords match, the server checks the permissions for the resource. If the permissions specify that the user can access the resource, the server grants access.

The following table compares the security features of LAN Manager and Windows NT Server. For more information on Windows NT security, see the Windows NT Server Concepts and Planning Guide.

Security Feature Comparison

LAN Manager domains		Windows NT Server domains
Local security is optional and supported only on servers running LAN Manager.		Local security is built in. Users must use an account and password to log on.
Do not contain local groups.		Contain local and global groups.
Do not support file and directory ownership.		Support ownership of files and directories. Owners can grant and deny access.
Administrators have access to all resources.		Administrators may be denied access to files, directories, and other resources that they do not own. They can take ownership, however, which creates an audit trail.
System functions are not protected.		System functions, such as setting system time and formatting hard disks, are protected.
Individual user permissions take precedence over groups.		User and group permissions are cumulative. Deny access takes precedence over Grant access.
Permissions apply only to network users, unless local security is implemented.		File and directory permissions apply to local and network users.
User rights, such as the right to administer a computer, are associated with groups, administrators, guests, and so on.		Specific user rights can be assigned to individual users as well as groups.


Resource Permissions

Differences in Administering LAN Manager and Windows NT Server	5 of 16

Resource Permissions

This section compares LAN Manager user-level permission settings with security settings on computers running Windows NT, including file, directory, printer, and named pipe settings. Windows NT does not support communication queues.

File and Directory Permissions

On a LAN Manager network, you can control access to all the files and directories in the FAT, HPFS, or HPFS386 file systems. On a Windows NT Server network, you can control users' access to directories and files on drives formatted to use the Windows NT File System (NTFS). Drives formatted to use FAT and HPFS do not support Windows NT security. You can, however, secure Windows NT shared directories no matter what file system is in use.

The standard permission for files and directories and their meanings are shown in the following tables, along with the individual permissions each standard permission represents.

File Permissions

LAN Manager		NTFS file		Description/differences
R (Read and Execute)		Read (RX)		User can read the contents of the file and run it if it is an application.
W (Write)		Change (RWXD)		User can open and write to a file, changing its contents. Windows NT allows deletion of the file.
D (Delete)		N/A		User can delete files.
X (Execute)		N/A		User can run a program, but not read or copy it.
A (Change Attributes)		N/A		User can change file attributes.
P (Change Permissions)		N/A		User can grant permissions for the file to other users.
Y (Yes)		Full Control (All)		With LAN Manager, serves as a shortcut to RWCDA permissions. When you give the user Y permission, you are granting RWCDA permissions. With Windows NT, enables the user to read, modify, delete, set permissions for, and take ownership of the file.
N (No)		No Access		User cannot use the file or directory in any way, even if the user is a member of a group that has been granted access to the file. With LAN Manager, Y access given to the user overrides N access given to the group. With Windows NT, Deny access takes precedence. For example, if the user has Full Control access for a file but is a member of a group that has No Access for the same file, access is denied.
In the second column of the following table, the first set of individual permissions applies to the directory itself, and the second set of individual permissions applies to new files in the directory.

Directory Permissions

LAN Manager		NTFS directory¹		Description/differences
R (Read and Execute)		Read (RX)(RX)		User can read files in the directory and run applications in the directory.
W (Write)		Change (RWXD)(RWXD)		User can read and add files and change the contents of current files.
C (Create)		Add  (WX) (Not Specified) Add & Read  (RWX) (RX)		User with C permission can create a file and then can read from or write to the file until closing it. Add enables a Windows NT user to add files to the directory but not to read the contents of current files or change them. Add & Read enables a user to add files to the directory and read current files, but not to change them.
D (Delete)		N/A		User can delete files and subdirectories within the shared directory but cannot delete the shared directory itself.
X (Execute)		N/A		User can run a program in the directory, but not read it or copy it.
A (Change Attributes)		N/A		User can change the attributes of files in the directory.
P (Change Permissions)		N/A		Users can change the permissions for the directory and for files in the directory.
Y (Yes)		Full Control (All)(All)		With LAN Manager, serves as a shortcut to RWCDA permissions. When you give a user Y permission, you are granting RWCDA permissions. User can read and change files, add new ones, change permissions for the directory and its files, and take ownership of the directory and its files.
N (No)		No Access (None)(None)		Prevents a user from using the file or directory in any way. Usually, you can prevent a user from accessing a file or directory simply by not giving the user any permissions to it; however, you must use N permission to prevent a specific user from accessing a file while granting access to the file or directory to a group the user belongs to. With Windows NT, users cannot access the directory in any way, even if they have Full Control access through group membership.
N/A		List (RX) (Not Specified)		User can only list the files and subdirectories in this directory and change to a subdirectory of this directory. User cannot access new files created in this directory.
¹ Permissions on shared Windows NT directories that are not NTFS are identical. Note that if a directory is both shared and on an NTFS volume, permissions are cumulative over the network.

Named Pipe Permissions

Named pipe permissions with LAN Manager are set through the Net Admin user interface. With Windows NT, access to named pipes is set only through applications. By default, unless an application specifically restricts access to the pipes it creates, all users have Read and Write access. Permissions on named pipes are reset every time a computer restarts. The following table lists access permissions for both platforms.

Named Pipe Permissions

LAN Manager		Windows NT		Description/differences
Permitted Access (Yes)		Read access  Write access  Create Instance Read Control		Yes access in LAN Manager permits a user to create a named pipe and then read and write to it.  A Windows NT application can grant more specific access, such as permission to create a pipe, and read and write to it. A user with Read Control access is the owner of the named pipe and can grant or deny access.
Denied Access (No)		-		Prevents access.
Permitted Access; can change permissions (Yes+Change Permissions)		Write Owner Write DAC		With Windows NT, Write Owner access enables a user to change ownership of a named pipe. Write DAC enables a user to change permissions.
-		Delete		Permits user to delete instance of a named pipe.
Printer Permissions

Creating and sharing a printer under Windows NT Server is similar to installing a printer and setting up a print queue under LAN Manager. The following table compares print permissions on each platform.

Printer Queue Permissions

LAN Manager		Windows NT		Description/differences
Y (Yes)		Print		User can send jobs to the printer queue.
N (No)		No Access		User can access the printer queue.
Y+P (Yes+Change Permissions)		Full Control		Users can send jobs to and set access permissions for the printer queue. Users can print documents and change print settings.
N/A		Manage Documents		Users can pause, resume, restart, delete, and control settings for documents.
Inherited and Default Permissions

The following table shows how LAN Manager and Windows NT handle inherited permissions, and files and directories that have no permissions.

Permissions		LAN Manager/ HPFS386		Windows NT/ NTFS
Inherited permissions		To use inherited permissions, set permissions for a directory using the LAN Manager screen and then specify that those permissions are copied down through the directory tree.		By default, changing the permissions on a directory changes the permissions on files that exist in the directory, but not on subdirectories or subdirectory files.
Default permissions		If you don't set permissions for a directory or file, LAN Manager uses the permissions of the directory that contains the directory or file. If you have not specified permissions for the directory in which a file or subdirectory resides, only administrators can access the file or subdirectory.		New files and subdirectories in a directory inherit permissions from the directory.
Disk Resources Shared by Default

With both LAN Manager and Windows NT, you can share directories and specify which users can access them. To share a directory, you assign a sharename to it. The following table shows sharenames (also known as disk resources) that are set up automatically with LAN Manager and Windows NT.

Shared Resources

LAN Manager		Windows NT		Description
ADMIN$		ADMIN$		A special administrative resource for remote administration. All sharenames that end in a dollar sign($) are hidden; they do not appear when a user uses the net view command or File Manager to examine server resources.
C$		C$		An administrators-only connection to the root of the C drive. If the server has a D drive, it shares a D$ resource, and so on.
IPC$		IPC$		Supports interprocess communication.
PUBLIC		-		The directory for public storage.
NETLOGON		NETLOGON		LAN Manager shares the directory specified by scripts with the sharename NETLOGON.


Auditing

Differences in Administering LAN Manager and Windows NT Server	6 of 16

Auditing

With Windows NT and LAN Manager, you can audit the way network resources are used. Auditing writes an entry to a log file whenever a resource is used in a particular way. The entry includes information on how the resource was used, by whom, and when.

Network-related audit events		LAN Manager		Windows NT
Successful and failed attempts to log on to the network		Yes		Yes
Successful and failed attempts to begin using resources on a particular server		Yes		Yes
Successful and failed attempts to use a particular resource		Yes		Yes
Changes to the user accounts (security) database		Yes		Yes
Logoff attempts and breaking network connections				Yes
Use of user rights (except logon and logoff)				Yes
Network-related audit events		LAN Manager		Windows NT
Changes made to user rights, audit, or trust relationship policies				Yes
Restarting and shutting down a computer, or any event that affects system security or the security log				Yes
Process tracking				Yes
File and directory audit events		LAN Manager		Windows NT
Successful and failed attempts to:
Open a file		Yes		Yes
Write to a file		Yes		Yes
Delete a file		Yes		Yes
Change the permissions for a file		Yes		Yes
Display names of files in a directory				Yes
Display directory attributes				Yes
Change directory attributes				Yes
Create subdirectories and files				Yes
Go to a directory's subdirectories				Yes
Display the directory's owner and permissions				Yes
Delete a directory				Yes
Change directory permissions				Yes
Change directory ownership				Yes
Display file attributes				Yes
Display a file's owner and permissions				Yes
Change file attributes				Yes
Run a file				Yes
Change a file's owner or permissions		Permissions only		Yes


Domains and Servers

Differences in Administering LAN Manager and Windows NT Server	7 of 16

Domains and Servers

Both LAN Manager and Windows NT group workstations and servers into domains. All the servers within a domain can be set up to use copies of the user accounts database, which contain user accounts and groups (and computer accounts and security policies with Windows NT). All changes made to the domain-wide user accounts database affect all servers that use copies of the database. Neither LAN Manager or Windows NT Server support remote administration of LAN Manager replication servers.

Windows NT simplifies the types of computers in a domain. With Windows NT, one server is called the primary domain controller, where the master copy of the user account database is stored. The Windows NT primary domain controller has functions similar to a LAN Manager primary domain controller, and a Windows NT Server is similar to a backup domain controller in LAN Manager.

Domain Administration Features

LAN Manager domains		Windows NT Server domains
Contain a primary domain controller, backup controllers, member servers, and standalone servers.		Contain a primary domain controller, backup controllers and servers.
Do not support trust relationships.		Support trust relationships between domains.
Do not support local groups.		Support local and global groups.
LAN Manager computers can be administered from any MS-DOS, UNIX, or OS/2 computer running LAN Manager, or from a Windows NT computer.		Windows NT computers can be administered only from other Windows NT computers.
Admins can designate the logon server.		The server with the lightest load processes logons.
User accounts database contains user and group accounts.		The security database contains user, group, and computer accounts as well as security policy information.
In a domain containing servers running both LAN Manager and Windows NT Server, LAN Manager backup, member, and stand-alone servers function just as they do in a LAN Manager-only domain. However, backup controllers cannot authenticate Windows NT logons and cannot be promoted to primary domain controller of a Windows NT domain.


Replication

Differences in Administering LAN Manager and Windows NT Server	8 of 16

Replication

Both Windows NT and LAN Manager use replication to maintain identical copies of specified files and directories on different computers. Changes made to files on one computer are automatically replicated to other computers configured to receive the changes. In a mixed Windows NT Server domain, designate computer(s) running Windows NT Server to be the export server(s). The import server(s) can be other computers running Windows NT Server or Windows NT Workstation, or LAN Manager version 2.x servers.

This section compares the way directory and file replication is handled for LAN Manager domains and computers and for Windows NT Server domains and computers by answering the following questions:

What tools are used to manage replication?

How does replication work?

What are the Windows NT equivalents to the replication information in the LAN Manager LANMAN.INI file, REPL.INI files, USERLOCK files, and signal files?

What is the effect of creating and deleting import subdirectories?

How are permissions assigned for replication?

What Tools Are Used to Manage Replication?

With LAN Manager, the Replicator service is controlled with the net start and net stop commands. No special tools are provided for the management of other aspects of replication, for example, editing the [replicator] section of the LANMAN.INI file, placing REPL.INI files in first-level export subdirectories, placing USERLOCK files in first-level export subdirectories, and monitoring signal files in import subdirectories.

In Windows NT Server domains, most aspects of replication are managed by either the Server Manager tool or Control Panel. Server Manager manages replication for both the local computer and remote computers. The Server and Services options in Control Panel manage replication for only the local computer. The remainder of this section assumes the use of Server Manager, rather than its Control Panel equivalents.

A few replication parameters cannot be administered with Server Manager and can only be modified by editing the Registry. In addition, you must use User Manager for Domains to create and configure a domain logon account, which is required by the Directory Replicator service.

For information about using Server Manager to manage replication, see the Windows NT Server System Guide and the Windows NT Server Concepts and Planning Guide.

How Does Replication Work?

Replication works in similar ways on LAN Manager and Windows NT. In both cases, you designate one or more export servers where you maintain a master set of the directories and files to be replicated. You also designate one or more import computers (LAN Manager refers to these import computers as import servers) to receive replicated copies of those master directories and files.

Types of Computers

The following table shows which types of computers can participate in replication and what roles they can perform in a Windows NT Server domain.

Replication role		Type of computer
export server		running Windows NT Server
import computer		running Windows NT Serverrunning Windows NT Workstationrunning LAN Manager (2.1 or later) server
Notes on Interoperation

Server Manager cannot administer LAN Manager replicators. A LAN Manager export server cannot replicate to Windows NT import computers. However, a Windows NT export server can replicate to LAN Manager (2.1 or later) import servers, including LAN Manager for UNIX Systems (2.1 or later) import servers.

Windows NT and LAN Manager export servers do not usually coexist in the same domain.

Replication Guidelines

The following guidelines summarize guidelines for successful replication.

A server running Windows NT Server can be an import and an export file replication server.

A LAN Manager server can function as an import server to both computers running Windows NT Workstation and Windows NT Server.

A computer running Windows NT Workstation can function as only an import server. A computer running Windows NT Server can replicate files across domain trust relationships by establishing the equivalent Replication accounts and passwords in each domain.

Windows NT can support any import and export paths. However, maintaining the default paths, C:\WINNT\SYSTEM32\REPL\IMPORT and C:\WINNT\SYSTEM32\REPL\EXPORT, is recommended.

The Windows NT message "The account DOMAIN\REPL has been granted the Log On As A Service right and added to the Replicator local group.", indicates that the specified account has been added to the Backup Operators and Domain Users groups by default in addition to the Replicator group.

You can replicate directories or files from a Windows NT NTFS volume to an OS/2 (with LAN Manager 2.x) FAT volume if the filenames adhere to FAT file system naming conventions. The same is true for OS/2 as long as the filenames adhere to OS/2 HPFS style naming conventions.

Directories or files can be replicated from a Windows NT Server NTFS volume to an MS OS/2 LAN Manager 2.x HPFS volume; however, the names of the directories or files must adhere to the HPFS conventions, as follows:

Names can be up to 254 characters.

Paths and filenames can together be up to 259 characters long.

Blank spaces and periods can occur anywhere in the file or directory name.

These characters can be used in naming HPFS files:

[ ] , + = ;

These characters are not currently allowed:

< > : " / \ | * ? &

Windows NT Equivalents to LAN Manager Replication Information

The following sections discuss the Windows NT equivalents to LAN Manager replication information in the LANMAN.INI file, REPL.INI files, USERLOCK files, and signal files.

LANMAN.INI File

LAN Manager has an initialization file named LANMAN.INI, and you can edit the [replicator] section of this file to configure many aspects of replication. With Windows NT, most of the equivalent information is managed in Server Manager's Directory Replication dialog box. However, there is some information that can only be managed by editing the Registry.

The following table lists the entries from the [replicator] section of the LANMAN.INI file and compares them to equivalent Windows NT information in Server Manager's Directory Replication dialog box and the Windows NT Registry.

Entry in LANMAN.INI		Equivalent Windows NT information in the Directory Replication dialog box		Equivalent entry in theWindows NT Registry¹
exportlist		To List		ExportList
exportpath		From Path		ExportPath
guardtime		-		GuardTime
importlist		From List		ImportList
importpath		To Path		ImportPath
interval		-		Interval
logon		-		-
password		-		-
pulse		-		Pulse
random		-		Random
replicate		Do Not Export or Export Directories and Do Not Import or Import Directories		Replicate
tryuser		-		-
¹ In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Replicator\
Parameters.

The LANMAN.INI tryuser entry has no equivalent in Windows NT.

The LANMAN.INI logon and password entries have no direct equivalent in Windows NT. However, the Directory Replicator service does require that a user account be created (using User Manager for Domains) and assigned as the service's logon account (using Server Manager). For more information, see "Assigning a Logon Account to the Directory Replicator Service," later in this appendix.

REPL.INI Files

With export servers under both LAN Manager and Windows NT, you can control how much of each subdirectory tree in the export directory is replicated and under what conditions.

With LAN Manager, you can create a REPL.INI file for each first-level subdirectory of the export directory and in this way control how much of that subdirectory tree is replicated and under what conditions. You do this by placing two entries in the REPL.INI file: extent and integrity, and setting each to either tree or file. If you don't create a REPL.INI file, the defaults (extent=tree, integrity=file) are used for that subdirectory tree.

With Windows NT, similar functions are managed using Server Manager's Manage Exported Directories dialog box, as shown in the following table.

LAN Manager REPL.INI entry		Windows NT equivalent in the Manage Exported Directories dialog box		Effect
extent=tree		Subtree (Yes)		Replicates all files and subdirectories in that subdirectory tree.
extent=file		Subtree (No)		Replicates only files in the first-level subdirectory of that tree.
integrity=tree		Stabilize (Yes)		All files and subdirectories in that subdirectory tree must be stable (cannot be changed) for a specified interval before replication can occur.
integrity=file		Stabilize (No)		Each file can be replicated as soon as it is changed.
In Windows NT, the default settings are Subtree (Yes) and Stabilize (No). The default Windows NT stabilization interval is two minutes (or more).

USERLOCK Files

With LAN Manager, exporting from an export subdirectory tree on an export server can be prevented by placing a file named USERLOCK in a first-level export subdirectory of the export subdirectory. For the lock to work, integrity must be set to tree in that subdirectory's REPL.INI file.

With Windows NT, exporting from an export subdirectory tree or importing to an import subdirectory tree can be prevented by placing locks on selected first-level subdirectories of the export or import directory. Exporting and importing are accomplished using the Add Lock buttons in Server Manager's Manage Exported Directories and Manage Imported Directories dialog boxes.

Signal Files

The status of imported subdirectories can be monitored on any import computer.

With LAN Manager, the Replicator service indicates status by placing a signal file in each first-level subdirectory. With computers running Windows NT Server or Windows NT Workstation, the replication status of each first-level import subdirectory is displayed in Server Manager's Manage Imported Directories dialog box.

The following table compares the status indicators used by LAN Manager and Windows NT.

LAN Manager signal file		Windows NT status displayed in the Manage Imported Directories dialog box		Meaning
OK.RP$		OK		The subdirectory is receiving regular updates and the data is identical to that exported.
NO_MASTR.RP$		No Master		The subdirectory is not receiving updates.
NO_SYNC.RP$		No Sync		The data is not up to date.
-		[blank]		Replication of the subdirectory never occurred.
The Effect of Creating or Deleting Import Subdirectories

In LAN Manager, export servers replicate only the export subdirectories for which there are matching first-level import subdirectories on the import server. Export subdirectories are not replicated unless the equivalent first-level subdirectories already exist in the import path of the import server.

In this case with Windows NT, when an export server replicates to an import computer, it exports all its export subdirectories. If an equivalent first-level import subdirectory does not exist on an import computer, the subdirectory is created.

With Windows NT, deleting a first-level import subdirectory does not stop replication to that subdirectory. It only temporarily removes that subdirectory and its files from the import computer. They will be replaced the next time replication occurs. (To temporarily stop exporting of a subdirectory from an export server, use Server Manager's Manage Exported Directories dialog box to place a lock on that first-level subdirectory. To temporarily stop importing a subdirectory to an import computer, use Server Manager's Manage Imported Directories dialog box to lock that first-level subdirectory.)

How Are Permissions Assigned for Replication?

In LAN Manager, to replicate files and directories to an import computer, the Replicator service must be able to access the export directory tree on behalf of the import computer. Whether the import server has user-level security or share-level security, it must be granted RA (Read and Change Attribute) permissions for the export directory tree on the export server.

In Windows NT, the system automatically applies appropriate permissions to the export directory tree. For the export share (meaning REPL$, the network share for the export directory), the appropriate permissions are applied automatically when Server Manager (or the Server option in Control Panel) is used to configure export replication on an export server.

In Server Manager, when replication export is configured and then the Directory Replication dialog box is closed by choosing the OK button, the system starts the Directory Replicator service, creates the REPL$ share representing the export directory on that export server, and grants appropriate permissions for that share (Full Control to the domain's Administrators local group; and Read access for the domain's Replicator local group).

However, before replication export is configured for an export server, a domain user account must be created, configured, and assigned to the Directory Replicator service of the export server. (Eventually, the same user account must be assigned to the Directory Replicator service of every computer that participates in replication in the domain.)

Assigning a Logon Account to the Directory Replicator Service

With LAN Manager, one way to give export directory access to multiple import servers is to create a group on the export server, give the group RA permissions for the export directory tree, and then give the group an account for each import server.

In Windows NT, when services start, they log on in an account context. Most services log on to a special system account. The Directory Replicator service, however, must be assigned a special user account, created and configured to support replication. This domain user account must belong to the domain's Backup Operators local group. It must be assigned to all computers (export servers and import computers) participating in replication in the domain. Note that the user account should be assigned to an export server's Directory Replicator service before export replication is configured (using the Directory Replication dialog box) for that server.

User Manager for Domains is used to create the domain user account. Server Manager (or the Control Panel Services option) is used to assign that account to the Directory Replicator service of each export server and import computer of the domain.

When a domain user account is assigned to the Windows NT Server Directory Replicator service, the system automatically adds it to the domain's Replicator local group and grants it the Log On As A Service right for the domain. When a domain user account is assigned to the Directory Replicator service of a computer running Windows NT Workstation, the system automatically adds it to the workstation's Replicator local group and grants it the Log On As A Service right for the workstation.

For more information, see the Windows NT Server System Guide and the Windows NT Server Concepts and Planning Guide.


Groups

Differences in Administering LAN Manager and Windows NT Server	9 of 16

Groups

Both Windows NT and LAN Manager domains contain groups, or sets of users (with user accounts) who share common permissions for one or more resources. Putting users into groups makes it easier and faster to grant multiple users access to a resource and simplifies administration.

Windows NT supports two types of groups: global and local. A local group can be granted permissions and rights only for the servers of its own domain. However, it can contain user accounts and global groups both from its own domain and from trusted domains. Local groups provide a way for you to create handy sets of users from both inside and outside the domain, to be used only at servers of the domain.

A global group is called global because it can be used in many places: its own domain, servers and workstations of the domain, and trusting domains. In all those places it can be granted rights and permissions and can become a member of local groups. However, it can contain only user accounts from its own domain. Global groups provide a way for you to create handy sets of users from inside the domain, available for use both in and out of the domain.

LAN Manager groups correspond to Windows NT global groups - LAN Manager does not support local groups.


User Accounts

Differences in Administering LAN Manager and Windows NT Server	10 of 16

User Accounts

This section compares LAN Manager user accounts with Windows NT Server user accounts. These topics are compared:

Where is user account information maintained?

What tools are used to manage user accounts?

What information is contained in a user account?

Where are password and logon requirements set?

Where Is User Account Information Maintained?

With LAN Manager domains and servers, information about user accounts is maintained in the user accounts database (NET.ACC).

In Windows NT Server domains, information about user accounts is maintained in the domain's security database. The master is kept by the primary domain controller, and each server of the domain receives a copy. The security database is implemented as settings in the Registry. It is not accessible as a file.

Tools for User Account Administration

The following table provides an overview of the tools that can be used to manage tasks associated with user accounts.

Management task		LAN Manager¹		Windows NT Server domain
Set up and maintain user accounts		Administrator's LAN Manager screen (net admin command); or the net user command		User Manager for Domains; or the net user command
Determine security settings (set password and logon requirements)		Administrator's LAN Manager screen (net admin command); or the net accounts command		User Manager for Domains; or the net accounts command
¹ User-level security

With Windows NT Server, the net user and net accounts commands can be used to manage the tasks listed above. However, in most cases User Manager for Domains offers the easiest and quickest method for administering user accounts. Except where noted, the remainder of this section is written from the perspective of User Manager for Domains, comparing the account information it can administer to the account information that can be administered with an administrator's LAN Manager screen.

User Account Information

For the most part, identical or similar information is maintained for user accounts from LAN Manager domains and servers set for user-level security, and user accounts from Windows NT Server domains. The following table compares user account information.

User account information		LAN Manager¹		Windows NT Server domain
Account name (Username)
Password
Disable account (Account disabled)
Full name
Comment (Description)
User comment
Country code
Privilege level
Operator privileges
Group memberships
Local group memberships
Global group memberships
Macintosh primary group (Primary group)
Account expires
Valid workstations (Logon workstations)
Hours logon allowed (Logon hours)
Logon server
Logon script
Home directory
User storage limit
User must change password at next logon
User cannot change password
Password never expires
User profile path
Account type

¹ User-level security

The following sections discuss differences between LAN Manager account information and Windows NT Server account information. In most cases, the LAN Manager terminology is taken from the administrator's LAN Manager screen (net admin), and the Windows NT terminology is taken from options displayed in User Manager for Domains dialog boxes. Exceptions to this are noted.

Account Expires

For both LAN Manager and Windows NT, Account Expires is an optional entry that specifies a date (month, day, and year) on which the user account will expire. An expired account becomes disabled (it is not deleted). The default is for an account to never expire.

With LAN Manager, an account expires at the beginning of the specified day. With Windows NT, an account expires at the end of the specified day.

Account Name (Username)

With LAN Manager, a username can be up to 20 characters. It can contain letters, numbers, and these characters:

!   #   $   %   &   (  )   -   .   @   ^   _   '   {   }   ~

With Windows NT, a username can be up to 20 characters. It can contain any uppercase or lowercase characters (including spaces) except for the following:

"    /    \    [    ]    :    ;    |    =    ,    +    *    ?    <    >

Account Type

This option is not offered by LAN Manager.

Windows NT Server user accounts are configured with an account type. They are either global accounts or local accounts. Most user accounts are global accounts, and this is the default.

A local account is an account provided in a domain for a user whose regular account is not in a trusted domain. The nontrusted domain might be another Windows NT Server domain that is not trusted by this domain, a Microsoft LAN Manager domain that has not yet upgraded to Windows NT Server, or another type of domain or network.

For example, you can use local accounts to allow users from LAN Manager domains to have access to a Windows NT Server domain. You can also use local accounts to allow users from other Windows NT Server domains to access LAN Manager computers that belong to a Windows NT Server domain.

Local accounts function much like global accounts. They can be used to access computers running Windows NT Workstation and Windows NT Server over the network, and they can be granted resource permissions and user rights.

However, local accounts cannot be used to log on interactively at a Windows NT Server computer. Local accounts created in one domain cannot be used in or viewed by trusting domains.

Comment (Description)

The Comment for LAN Manager user accounts is the same as the Description with Windows NT user accounts. Both are optional entries, and both can be up to 48 characters.

Country Code

With LAN Manager, each user account can be assigned an operating-system country code to implement the specified files for a user's help and error messages.

With Windows NT, User Manager for Domains cannot be used to assign an operating-system country code to a user account. (Although a country code can be assigned to a user account in Windows NT by using the net user command, it has no effect on Windows NT except when the OS/2 subsystem is used.)

Disable Account (Account Disabled)

The LAN Manager Disable Account option is similar to the Account Disabled option in Windows NT. Both can be set to on or off (selected or cleared).

In LAN Manager, disabling prevents access to server resources. In Windows NT, disabling prevents use of the account (logons are not allowed). For both, the default is for accounts to be active (the disable account option is cleared).

Full Name

For both LAN Manager and Windows NT, the user's full name can be included in the user account information. This is an optional entry.

Group Memberships

In LAN Manager, a user account can be added to one or more user groups. All resource permissions granted to a group are also provided to the group's members. Grouping is helpful when assigning resource permissions to users who use the network in the same or similar ways.

Home Directory

With LAN Manager, a home directory assigns storage space on a server to a user account. It is always expressed as a network path. The default is to have no home directory.

For user accounts in a Windows NT Server domain, a home directory is a directory that is accessible to the user and can contain files and programs for that user. It becomes that user's default directory for the File Open and Save As dialog boxes, for the command prompt, and for all applications that do not have a working directory defined.

A Windows NT home directory can be assigned to a single user or it can be shared by many users. A home directory can be a shared network directory or a local directory on a user's workstation. However, when administering domain user accounts, a network directory will usually be assigned. (If this is done, a user can log on from any computer running Windows NT Workstation, yet still have access to his or her own home directory.)

When no home directory is assigned to a user account, the system uses the default local home directory (\USERS\DEFAULT on the user's local drive where Windows NT is installed).

Home directories make it easier for an administrator to back up user files and delete user accounts, because they collect many or all of a user's files in one location.

Hours Logon Allowed (Logon Hours)

For both LAN Manager and Windows NT, this can be used to restrict the days and time during which the user can connect to a server. The user can be permitted all days and hours (the default) or can be restricted to specific days and hours.

Local and Global Group Memberships

Each Windows NT Server domain offers two types of groups: local and global. Some built-in local and global groups are provided with the domain, and additional groups can be created using User Manager for Domains.

In most cases, the group memberships a user account is granted determine the actions the user can perform and the resources the user can access. Giving a user account membership in a group provides that user all the user rights, built-in abilities, and resource permissions that have been granted to the group. This provides an easy way to grant common capabilities to sets of users.

A local group can be granted permissions and rights only for the servers of its own domain. However, it can contain user accounts and global groups both from its own domain and from trusted domains. Local groups provide a way to create handy sets of users from both inside and outside the domain, to be used only at servers of the domain. These built-in local groups are provided with a Windows NT Server domain:

Account Operators

Administrators

Backup Operators

Guests

Print Operators

Replicator

Server Operators

Users

A global group can be used in many places: its own domain, servers and workstations of its own domain, and trusting domains. In all those places it can be granted rights and permissions and can become a member of local groups. However, it can only contain user accounts from its own domain. Global groups provide a way to create handy sets of users from inside the domain, available for use both in and out of the domain. These built-in global groups are provided with a Windows NT Server domain:

Domain Admins

Domain Users

Domain Guests

Global groups can be members of local groups, so membership in a global group often provides a user account with the rights and permissions from a local group. For example, the Domain Users global group is by default a member of the Users local group; and the Domain Admins global group is by default a member of the Administrators local group. Domain Guests is a member of the Guests local group.

The following table summarizes how membership in local or global groups can be used to determine the user rights, built-in abilities, and permissions provided to user accounts.

If		Need to be used in		You can put them in
User accounts from this domain		The servers and workstations of this domain, or of other domains		A global group
User accounts from this domain or other domains		The servers of this domain		A local group
Global groups from this domain or other domains		The servers of this domain		A local group
For detailed information about group memberships for user accounts, the built-in local and global groups, user rights, built-in abilities, and permissions, see the Windows NT Server System Guide and the Windows NT Server Concepts and Planning Guide.

Logon Script

Sets a filename and, optionally, a relative path for the user's logon script.

With LAN Manager 2.1 or later, the path of the logon script is relative to the value for the scripts entry in the [netlogon] section of the logon server's LANMAN.INI file.

With Windows NT Server, the path of the logon script is relative to the local logon script pathusually, systemroot\SYSTEM32\REPL\IMPORT\SCRIPTS - of the server authenticating the logon. A Windows NT logon script can be a batch file (.BAT or .CMD filename extension) or an executable program (.EXE filename extension).

For both LAN Manager and Windows NT, the default is to have no logon script assigned.

Logon Server

In LAN Manager, a particular domain controller (the primary or a backup) can be assigned to authenticate a particular user account's logon requests.

This option is not offered by Windows NT. A logon request to a Windows NT Server domain might be authenticated by any domain controller, primary or backup. Load balancing occurs automatically. A specific server cannot be assigned to log on a specific user account.

Macintosh Primary Group (Primary Group)

In LAN Manager, if a server is running the optional LAN Manager Services for Macintosh, and if a user will be connecting from an Apple Macintosh or is to automatically have access privileges to directories created from a Macintosh, the user account should be assigned a Macintosh primary group. The default is to have no primary group assigned.

With Windows NT Server, a primary group is needed when a user logs on using Windows NT Services for Macintosh, or runs POSIX applications. In a Windows NT Server domain, every user account always has one global group assigned as the primary group. The Domain Users global group is the default primary group.

Operator Privileges

In LAN Manager, when an Operator privilege is granted to a user account, the user is allowed to perform certain administrative tasks. The available Operator privileges are Accounts operator, Comm operator, Print operator, and Server Operator. To be assigned Operator privileges, the user account must first be assigned the User privilege level.

Operator privileges are not offered in Windows NT. However, very similar functions are provided through user account memberships in local groups.

Password

With LAN Manager, a password can be up to 14 characters long. With Windows NT, a password can be up to 14 characters long and is case-sensitive as long as the computer you are logged onto and the computer whose resource you are trying to access are both Windows NT computers. For example, if a Windows NT user account is assigned a password of CHRISDR, a user will not be able to log on to that account by typing a password of Chrisdr.

The case of the password entered and the password stored in the Windows NT user database must match. However, if a logon procedure takes place on a non-Windows NT computer (a Windows for Workgroups computer, for example) or the share being accessed is on a non-Windows NT server (even if the server is in a Windows NT domain), password validation becomes case-insensitive. There is one exception to these rules and one error that results from mismatched case in passwords.

The exception is that if you change your password from a non-Windows NT computer (using the Windows NT NET PASSWORD command), Windows NT stores your new password as a case-insensitive password and permits all subsequent logons to be password case-insensitive. Even if another user logs on from a Windows NT computer, no password case checking is performed.

An error can be generated if you mismatch the case of your password after you've already logged onto a Windows NT domain. For example, if you establish a network session with a Windows NT computer by typing the following two lines:

net use x: \\winntcomputer\data /u:domain\user PASSWORD
net use y: \\winntcomputer\apps /u:domain\user password

The following error message is displayed:

System error 1219 has occurred. The credentials supplied conflict with an existing set of credentials.

To avoid this error message, make sure you always use the same case when attempting to connect to shared resources.

Password Never Expires

This option is not offered by LAN Manager.

With Windows NT, this option prevents a password from expiring (regardless of the password expiration setting, which applies to all user accounts, and which is set in the Account policy). It is typically used for accounts to which services (for example, the Directory Replicator service) log on.

Privilege Level

In LAN Manager, each user is assigned one of three privilege levels: User, Admin, or Guest. The privilege level determines the range of actions a user can perform on the network. A user account assigned the User privilege can also be assigned one or more Operator privileges.

Privilege levels are not offered in Windows NT. However, very similar functions are provided through user account memberships in local groups. The User Rights policy (administered with User Manager for Domains) also affects the range of actions a user can perform.

User Cannot Change Password

This option is provided for both LAN Manager and Windows NT.

User Comment

With LAN Manager, the user comment is an optional entry that is displayed when a user views a list of users on the server or domain.

In Windows NT, the user comment cannot be viewed by users. It cannot be administered with User Manager for Domains. Although it can be viewed and administered from the command prompt (using the net user command), this has no practical effect, since users cannot view it.

User Must Change Password at Next Logon

This option is not offered by LAN Manager.

With Windows NT, this option requires a user to change the password at the next logon. It is typically used when an administrator creates a new user account. At the first logon the user is required to change the password.

Note

Windows NT passwords cannot be viewed. However if necessary (for example, if the user forgets the password), an administrator or account operator can change it.

User Profile Path

This feature is not offered by LAN Manager.

Windows NT Server has a user profile. This is a special file loaded by the system during a user's logon that defines the Windows NT environment created for that user. This definition includes all the user-specific settings of a user's Windows NT environment, such as Program Manager groups and the program items in those groups, screen colors, network connections, printer connections, mouse settings, desktop settings (for example, a screen saver), window size and position, and more.

User profiles are optional - the default is to have no profile assigned. A user profile path for a Windows NT Server user account consists of a pathname, including a network path and the filename of the user profile.

User profiles are created with User Profile Editor. They should be stored on shared network directories, and are assigned to users with User Manager for Domains. When this is done, a user can move between various Windows NT computers in the network and still receive a consistent Windows NT environment.

A single profile can be assigned to a group of users who perform similar tasks, so that they can share a common Windows NT configuration. And, if appropriate, an administrator can also use user profiles to restrict the access and capabilities allowed to selected users.

For information about user profiles, the user profile path, and User Profile Editor, see the Windows NT Server System Guide.

User Storage Limit

With LAN Manager, each user account can be assigned a maximum amount of storage, specified in kilobytes, for a user's home directory.

This option is not offered by Windows NT.

Valid Workstations (Logon Workstations)

With LAN Manager, this can be used to specify the workstations from which the user may access the server. With Windows NT, this specifies the workstations from which the user can log on to the domain user account.

The user can be allowed to use all workstations (the default) or can be restricted to a list of between one and eight workstations.

Password and Logon Requirements

The following table compares the LAN Manager security settings (that can be set from the administrator's LAN Manager screen) with the Windows NT Server Account policy parameters (that can be set using User Manager for Domains).

Password and Logon Requirements

Parameter		LAN Manager		Windows NT Server
Minimum password length		Between 0 and 14 characters. Default is 6.		Permit Blank Password (the default); or between 1 and 14 characters.
Minimum password age		Between 0 and 49710 days. Default is 0.		Allow Changes Immediately (the default); or between 1 and 999 days.
Maximum password age		No Limit; or between 1 and 49710 days. Default is 90.		Password Never Expires; or between 1 and 999 days. Default is 42 days.
Password uniqueness		Between 0 and 8 passwords. Default is 5.		Do Not Keep Password History (the default); or between 1 and 8 passwords.
Force logoff		Immediately; Never; or after a defined number of minutes. Default is Never.		Selected (yes) or cleared (no). Default is cleared (no). Note: A wait time cannot be set with User Manager for Domains. When this option is selected, the default wait time is 0 minutes. However, the wait time can be set from the command prompt, using the net accounts command.
Lockout accounts		Never; or after a defined number of invalid logon attempts. Default is Never.		After a defined number of invalid logon attempts within a specified amount of time. Default is disabled.
Following is an illustration of the Account Policy dialog box from User Manager for Domains.


Logging On

Differences in Administering LAN Manager and Windows NT Server	11 of 16

Logging On

At a Windows NT workstation or a Windows NT Server, when no one is logged on, a Welcome message is displayed.

To use the local computer or the resources available from the network, a user must log on to a user account. To do so, the user completes the Welcome dialog box.

The following logon information is required by Windows NT.

Logon information	Definition

Username	The username of a valid user account.

From	The name of the domain or the local computer where the user account is defined.

Password	The password for the user account. The password is case-sensitive. (Windows NT distinguishes between uppercase and lowercase characters in passwords.)

For security, when the password is entered, only asterisks are displayed.

When a Windows NT Workstation computer is a member of a Windows NT Server domain, a user at that workstation has the choice of logging on a user account defined in the domain or a user account defined at the workstation. Usually, a user will log on to a domain user account, because this provides the user with access to the servers and workstations of the domain, and because that is probably where the domain administrator created the user's account. An account may not necessarily have been created at that workstation for that user.

When a user attempts a logon to a domain user account, the workstation sends the user name and password to the specified domain for authentication. A server in that domain checks the user name and password against that domain's security database. If the user name and password match an account, the server notifies the workstation that the logon is to be approved. The server also downloads any logon information about the user, such as the user's profile, logon script, home directory, and environment variables.

When a user attempts a logon to a user account from the local Windows NT workstation, the workstation checks its own security database for the user name and password specified by the user. If there is a match, the logon is approved, and the user's logon information is obtained from the account on the workstation.

The process for logging on at a Windows NT Server computer is identical to the process for logging on at a Windows NT Workstation computer, except that servers do not maintain their own separate, local accounts. A user must log on to a domain account. Also, not everyone with an account in the domain is allowed to log on locally at the domain's Windows NT Servers. By default, only members of the Administrators, Server Operators, Print Operators, Account Operators, and Backup Operators are allowed to do so.

Guest Logons

Both LAN Manager and Windows NT support logons to guest accounts.

With LAN Manager, guest accounts enable users who don't have accounts at a server to access the shared network resources of a server. As installed, LAN Manager servers have a default user account named guest. By default it has a blank password. If a user without an account on a server tries to access resources on the server, LAN Manager checks to see that the guest account exists, and that the password the user provides matches the password of the guest account. If so, the user can access the server's resources according to the resource permissions granted the guest account.

Every Windows NT Server domain and every Windows NT Workstation computer has a built-in guest account. By default, these accounts have blank passwords. By default, the guest account of a Windows NT Server domain is disabled, and the guest account of a Windows NT workstation is enabled. If domain guest logons are to be allowed, the domain's guest account must first be enabled (using User Manager for Domains).

With Windows NT, guest accounts can be used for two types of guest logons: local and network.

A local guest logon happens when a user at a Windows NT Workstation or Windows NT Server computer specifies guest as the user name in the Welcome dialog box. If the logon is allowed, the user can then work at that computer (subject to the permissions and rights granted to the guest account) and can also use it to access the network.

Note that Windows NT Servers usually do not allow local logons for the Guest account.

A network guest logon occurs when a user whose computer is not in a trusted domain tries to access a Windows NT computer over the network. In this case, as long as the Guest account has no password, the access is approved as a guest logon. The guest user then has all rights, permissions, and group memberships that are granted to the Guest account, even though the guest user doesn't specify Guest as his or her user name.

Network guest logons can occur when a user of a LAN Manager 2.x or Windows for Workgroups workstation logs on stand-alone and then accesses a Windows NT computer.

Cross Domain and Guest Access

The following scenario illustrates cross-domain and guest access on a network containing servers running both LAN Manager and Windows NT Server.

Consider this example: your Windows NT Server computer is the primary domain controller for DomainA, and you have problems seeing or using printers from LAN Manager DomainB. This could be a very simple problem: You are connecting to a printer on a non-Windows NT computer, so you must have the correct printer driver set up on your own workstation. Often, however, it is a permissions or account problem.

Possibility 1: Password Problems

There may already be an account with the same name on the other domain or workstation, but one that uses a different password. The DomainB server receives a request: "I'm Eric from DomainA, my password is q," and responds: "You can't be Eric, that's not his password here--Access Denied." If the request comes from an account that does not exist on the DomainB server, it responds: "I don't have an account called Miles, but I'll give you guest access" (if the server has a guest account enabled).

Windows NT and OS/2 LAN Manager react the same way to Possibility 1. There are some differences, however, when trusted domains are involved.

Possibility 2: Trusted Domains

You are logged on as DomainA\eric, and have no account on DomainB. Unless DomainA is a trusted domain for DomainB you have to rely on guest rights or secure an account DomainB\eric with the same password you have on your DomainA account. This is the same way you must do things now with LAN Manager.

The DomainB controller may not recognize the request "I'm Klaas from DomainA, my password is q." If DomainA is a trusted domain, however, the DomainB server checks the password with the DomainA controller, rather than automatically deny access. If the DomainA controller says the password is correct for the account, the server running Windows NT Server checks the account's access privileges to the resource in question and grants the same privileges allowed in DomainA.

MS-DOS or OS/2 clients send the Windows NT Server computer only their username and password because they do not support the extended SMB protocol; Windows NT Workstation computers identify their domain as well, which the server checks against the list of trusted domains. If a domain match exists, the server grants the requester the same privileges allowed in its own domain. If the account or domain is unknown, the server compares the requester's password against the guest account password (if that account is enabled) and grants guest privileges if a match exists.


Logon Scripts

Differences in Administering LAN Manager and Windows NT Server	12 of 16

Logon Scripts

For both Windows NT and LAN Manager, one logon script is run when a user logs on. The logon script for a particular user is defined in that user's account. You can create individualized scripts for each user, or you can create one standard script that will be run for all users. In Windows NT, logon scripts are always run when a user logs on. In LAN Manager, logon scripts are run only if the Netlogon service is running.

With Windows NT, any one of a domain's servers may authenticate a user's logon attempt, so logon scripts for all user accounts in a domain must exist on every Windows NT Server in the domain. This is handled automatically by the Replication service.


The Computer Browser

Differences in Administering LAN Manager and Windows NT Server	13 of 16

The Computer Browser

In LAN Manager, the net view command can be used to display a list of servers and resources shared by a server.

In Windows NT, the Computer Browser service maintains an up-to-date list of domains, workgroups, and computers, and provides the list to applications when requested. It provides the lists that are displayed in the Select Computer and Select Domain dialog boxes anywhere Windows NT presents lists of domains, workgroups, or computers (for example, in the main Server Manager window) and of course, by the net view command.

The list can contain the names of domains, workgroups, and computers that are running the server service. These can be:

Windows NT Server controllers and servers

Windows NT Workstation computers

Windows NT workgroups

Windows for Workgroups computers

Windows for Workgroups workgroups

LAN Manager (version 2.0 or later) domains and servers

For each domain or workgroup, the master copy of this list is maintained by a computer that is designated the master browser. Another copy of that list is maintained by one or more computers designated to be backup browsers. There is one backup browser for every 32 computers running the server service in the domain or workgroup. The master browser and the backup browsers are elected automatically, by the system. (Backup browsers, and to a limited extent master browsers, can be designated by an administrator by editing the Registry.)

In a Windows NT Server domain, the master browser will usually be the primary domain controller and the backup browsers will usually be Windows NT Server computers, but Windows NT Workstation computers and Windows for Workgroups computers can also act as backup browsers.

In a workgroup, the master browser and backup browsers will be Windows NT Workstation computers or Windows for Workgroups computers.

A LAN Manager (version 2.0 or later) domain is known to the browser only if at least one Windows for Workgroups computer or at least one Windows NT Workstation computer is a member of that LAN Manager domain.

Or, for the browser to know about the LAN Manager domain, you can administer the Control Panel of the Windows NT Server primary domain controller. Using the Network option in Control Panel, enter the LAN Manager domain name in the Browser Configuration dialog box. The browser then knows that LAN Manager domain.


Network Protocols

Differences in Administering LAN Manager and Windows NT Server	14 of 16

Network Protocols

This section compares how LAN Manager and Windows NT implement two protocols, NetBEUI and TCP/IP.

NetBEUI

The version of NetBEUI shipping with Windows NT is NetBEUI 3.0. Unlike previous versions of NetBEUI, version 3.0 uses the transport driver interface (TDI) as its upper-level interface (previous versions used the NetBIOS interface). For more information on TDI, see the Windows NT Server Concepts and Planning Guide.

NetBEUI 3.0 corrects 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 do previous versions of NetBEUI.

TCP/IP

When you use TCP/IP with LAN Manager, server names are matched automatically to their corresponding IP addresses on a local network using broadcast name resolution. LAN Manager uses LMHOSTS files to match server names across remote networks connected by routers (also called gateways).

Under Windows NT 3.5, server names are matched on the local network and across routers by using the Windows Internet Name Service, if WINS servers are installed on the network. Windows NT 3.5 can also use b-node broadcasts for name resolution or LMHOSTS files. For more information, see the Windows NT Server TCP/IP manual.

The LMHOSTS file is a local text file that lists the IP names and addresses of remote servers for communication. Under LAN Manager, TCP/IP loads the file into computer memory when the computer is started. Under Windows NT 3.5, LMHOSTS is checked as a last resort when other name resolution methods fail.

Under LAN Manager, LMHOSTS is stored on the local computer in the directory specified by netfiles in the [tcpip] section of the PROTOCOL.INI file. Under Windows NT, a sample LMHOSTS.SAM is placed in \systemroot\SYSTEM32\DRIVERS\ETC when Microsoft TCP/IP is installed. The network administrator must supply each Windows NT user with the appropriate LMHOSTS file. If LMHOSTS exists on a LAN Manager computer, the upgrade utilities copy the file from its LAN Manager location to the correct Windows NT directory.

The Windows NT implementation of LMHOSTS includes enhancements that allow entries to be preloaded into the name cache and that allow domain controllers to be designated. For details about LMHOSTS in Windows NT 3.5, see the Windows NT Server TCP/IP manual.

TCP/IP Features

LAN Manager		Windows NT Server 3.5
No routing capabilities.		A Windows NT computer with multiple network cards running Microsoft TCP/IP can use multiple default gateways. With WINS servers on the network, name resolution can occur across routers and across domains.
All clients must have an LMHOSTS file containing computername-to-IP address mappings.		With WINS servers, LMHOSTS is not required for name resolution. If used, a central LMHOSTS file can be used, with each client pointing to this file using #INCLUDE instructions in local LMHOSTS files.
LMHOSTS cache is limited to 32 IP addresses.		LMHOSTS cache can list 256 IP addresses, and this number can be extended by using #INCLUDE instructions to point to a central LMHOSTS file.
Supports simultaneous access to a single LAN Manager computer by 255 users.		Supports simultaneous access to a single Windows NT computer by 65,000 users.
Supports FTP client command.		Includes the FTP Server service.
Minimum MIB support for SNMP.		Provides MIB support for DHCP and WINS, in addition to LAN Manager MIB II.
Only LMHOSTS for name resolution.		Supports b-node, m-node, p-node, and h-node name resolution as defined by RFC 1001/1002 via WINS servers.
Manual TCP/IP configuration.		Provides automatic TCP/IP configuration, including dynamic IP addresses via DHCP servers.
Basic TCP/IP connectivity utilities.		Additional TCP/IP connectivity and diagnostic utilities, including a graphical Telnet application.
LMHOSTS only for name resolution.		Supports b-node, m-node, p-node, and h-node name resolution as defined by RFCs 1001/1002, implemented via WINS servers.
No TCP/IP printing support.		Supports printing to UNIX printers and direct-connect network printers, plus support for UNIX users to print to Windows NT printers.
Network monitoring via SNMP.		Networking monitoring via SNMP and Performance Monitor, including monitoring for FTP Server, IP protocols, and WINS.


Services

Differences in Administering LAN Manager and Windows NT Server	15 of 16

Services

Windows NT Server supports most LAN Manager services. To manage services on a server running LAN Manager, you use a single tool: the Net Admin interface. On Windows NT Server, two tools are available: Server Manager and the Services option in Control Panel. The Services option in Control Panel only manages services for the local computer; Server Manager manages services for both the local computer and remote computers.

The following table shows how LAN Manager services map to Windows NT.

LAN Manager service		Windows NT equivalent		Description/differences
Alerter		Alerter		Notifies selected users and computers of administrative alerts on a computer. Used by the Server and other services. Requires the Messenger service. Starts by default on both LAN Manager and Windows NT.
Messenger		Messenger		Sends and receives messages sent by administrators or by the Alerter service. Starts by default on both LAN Manager and Windows NT computers.
Netlogon		Net Logon		Verifies the username and password of each person who attempts to log on to the network or gain access to the server. Starts by default on LAN Manager and Windows NT computers.
Netpopup		Incorporated into Messenger service		Displays a message box when a message is received from another user or a server on the network. Starts by default on LAN Manager computers.
Netrun		Not supported		Lets users run applications on a server from their own workstations.
Remoteboot		Remoteboot		Enables users at workstations to boot workstations over the network.
Replicator		Directory Replicator		Replicates directories, and the files in those directories, between computers.
Schedule		Schedule		Must be active to use the at command. The at command schedules commands and applications to run on a computer at a specified time and date.
Server		Server		Provides file, print, and named pipe sharing, and support for remote procedure calls. Starts by default on LAN Manager and Windows NT computers.
Timesource		Built into Windows NT networking		Identifies a server as the time source for a domain.
UPS		UPS		Manages an uninterruptible power supply connected to a computer.
Workstation		Workstation		Provides network connections and communications. Starts by default on LAN Manager and Windows NT computers.


Country Codes and Locales

Differences in Administering LAN Manager and Windows NT Server	16 of 16

Country Codes and Locales

LAN Manager and Windows NT recognize the same country codes. However, Windows NT does not normally use country codes; instead, it asks for a locale during installation. The only time you need to specify a country code is when you are running the OS/2 subsystem from Windows NT. In that case, specify the correct country code in the CONFIG.NT file.

Country		Windows NT locale		Windows NT and LAN Manager country codes
United States		Universal English		001
Canada		Universal English/French		002
Latin America		Spanish/Portuguese		003
Netherlands		Dutch		031
Belgium		Dutch/French		032
France		French		033
Spain		Spanish		034
Italy		Italian		039
Switzerland		German/French/Italian		041
Austria		German		043
United Kingdom		Universal English		044
Denmark		Danish		045
Sweden		Swedish		046
Norway		Norwegian		047
Germany		German		049
Mexico		Spanish		052
Brazil		Portuguese		055
Australia		Universal English		061
New Zealand		Universal English		064
Portugal		Portuguese		351
Ireland		Universal English		353
Iceland		Icelandic		354
Finland		Finnish		358
Arabic speaking		Arabic		785
Hebrew speaking		Hebrew		972
Japan		Japanese		081
Korea		Korean		082
China		Chinese		086
Taiwan		Chinese		886


LAN Manager and Windows NT: Comparison of Network Parameters
Appendix B	1 of 4

LAN Manager and Windows NT: Comparison of Network Parameters

This appendix lists LAN Manager network parameters and their Windows NT equivalents. (LAN Manager parameters that relate to MS-DOS are not listed.) In LAN Manager, parameter settings are found in the file LANMAN.INI and PROTOCOL.INI. In Windows NT, these settings are a subset of the Registry.

Information for each setting includes its units, range, default value, description, and location in either LANMAN.INI or the Registry.

Overview: Service Parameter Locations

		In LAN Manager		In Windows NT
Alerter Service		These entries are found in the [alerter] section of LANMAN.INI.		These entries are in the registry in HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ Alerter\Parameters.
Messenger Service		These entries are found in the [messenger] section of LANMAN.INI.		These entries are in the registry in HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ LanmanServer\Parameters.
Netlogon Service		These entries are found in the [netlogon] section of LANMAN.INI.		These entries are in the registry in HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ Netlogon\Parameters.
Remote Access Service		These entries are found in the [remoteaccess] section of LANMAN.INI.		These entries are in two places in the registry:HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\ RemoteAccess\Parameters and \Parameters \NetBIOS Gateway.
ReplicatorService		These entries are found in the [replicator] section of LANMAN.INI.		These entries are in the registry in HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ Replicator\Parameters.
Server Service		These entries are found in the [server] section of LANMAN.INI.		These entries are in the registry in HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ LanmanServer\Parameters.
SNMP Service		These entries are found in the [snmp] section of LANMAN.INI.		These entries are in the registry in HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ Snmp\Parameters.
UPS Service		These entries are found in the [ups] section of LANMAN.INI of LAN Manager OS/2 servers. Workstations do not have this section.		These entries are in the registry in HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\UPS. The Registry does not contain information for the UPS service until the user checks the Uninterruptible Power Supply Is Installed check box in the UPS dialog box and then chooses OK. Changes to settings should be made using the UPS icon in Control Panel.
Workstation Service		These entries are found in the [workstation] section of the LANMAN.INI file.		These entries are in the registry in HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ LanmanWorkstation.
NetBEUI		These entries are found in the [netbeui] section of the PROTOCOL.INI file.		These entries are in the registry in HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ Nbf\Parameters.
TCP/IP		These entries are found in the [tcpip] section of the PROTOCOL.INI file.		These entries are in the registry in HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ adapter_name#\Parameters\Tcpip, where adapter_name# indicates a network adapter card name.
AppleTalk		These entries are found in the [ATALKn_XIF] section of the PROTOCOL.INI file.		These entries are in the registry in HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\ adapter_name#\Parameters\AppleTalk,  where adapter_name# indicates a network adapter card name.
COMTOKR/DLC		These entries are found in the [comtokr] section of the PROTOCOL.INI file.		These entries are in the registry in HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ DLC\Parameters\adapter_name.
The following table gives detailed information about LAN Manager services and Windows NT equivalents.

Service Parameter Details

Service		LANMAN.INI		Windows NT Registry		Description
Alerter Service:		sizalertbuf Units: bytes Range: 512 - 16384 Default: 3072		-		Sets the size of the buffer used for administrative alerts.
Messenger Service:		logfile Units:pathname Range:  -  Default:  MESSAGES.LOG		Messages are not stored.		In LAN Manager, sets the path for the messages log. Windows NT does not maintain a messages log. If a computer is not available to receive a message, the message will eventually time out.
		sizmessbuf Units: bytes Range:  512 - 62000  Default: 4096		Set by operating system Units: bytes  Range: -  Default: 8K		Sets the amount of buffer space, in bytes, allocated for sending and receiving messages. In Windows NT, this value is set to 8K.
Netlogon Service:		pulse Units: secs Range: 60 - 3600 Default: 300		Pulse Units: secs Range: 60 - 3600 Default: 300		Specifies how long a domain controller waits before sending update notices to other servers. If this value is not specified in the Registry, NetLogon determines optimal values depending on the primary domain controller's load.
		randomize Units: secs Range: 5 - 120 Default: 30		Randomize Units: secs Range: 0 - 120 Default: 1		Specifies the time a server will use to stagger requests sent to the domain controller.
		scripts Units: path Range: -  Default:  REPL\IMPORT \SCRIPTS		Scripts Units: path  Range: - Default: REPL\IMPORT \SCRIPTS		Specifies the fully qualified pathname where logon scripts reside. In Windows NT, this value is set using Server Manager or Services in Control Panel.
		update Units: Boolean Range: yes or no Default: yes		Update Units: Boolean Range: yes or no Default: no		Is set to yes to synchronize the user accounts database with the primary domain controller (or domain controller) when the service starts.
Remote Access Service:		audit Units:  -  Range: no, authentications, yes Default: authentications		EnableAudit Units:  -  Range: yes=1, no=0 Default: 1		Determines whether Remote Access auditing is turned on or off. On Windows NT, if this feature is enabled, all audits are recorded in the Security event log, which you can view using Event Viewer.
		authenticateretries Units: retries Range: 0 - 10 Default: 2		AuthenticateRetries Units: retries Range: 0 - 10 Default: 2		Sets the maximum number of unsuccessful retries allowed if the initial attempt at authentication fails.
		authenticatetime Units: secs Range: 20 - 600 Default: 120		AuthenticateTime Units: secs Range: 20 - 600 Default: 120		Sets the maximum time limit within which a user must be successfully authenticated. If the client does not initiate the authentication process within this time, the user is disconnected.
		autodisconnect Units: mins Range: 0 - 1000 Default: 20		Autodisconnect Units: secs Range: 0 - 60000 (1000 mins) Default: 1200 (20 mins)		Sets the time interval in minutes after which inactive connections are terminated. Inactivity is measured by lack of NetBIOS session data transfer.
		enablebroadcast Units:  -  Range: yes, no Default: no		EnableBroadcast Units:  -  Range: yes=1, no=0 Default: no		Determines whether broadcast datagrams are forwarded to remote workstations.
		maxdynmem Units: bytes Range: 65,700 -  650,700 Default: 197100		MaxDynMem Units: bytes Range: 131072 -  4294967295 Default: 655350		Sets the amount of memory allocated to support transfers of more than sizworkbuf of data. Under Windows NT, the amount of virtual memory used to buffer NetBIOS session data for each remote client. The Remote Access server minimizes the usage of the system's physical memory by locking only a minimal set of pages and making use of virtual memory (up to MaxDynMem) to buffer the rest of the data.
		maxnames Units: names Range: 1 - 255 Default: 12		MaxNames Units: names Range: 1 - 255 Default: 255		Sets the number of unique NetBIOS names each client may have.
		maxsessions Units: sessions Range: 1 - 255 Default: 20		MaxSessions Units: sessions Range: 1 - 255 Default: 255		Sets the maximum number of simultaneous sessions each client may have.
		multicastforwardrate Units: secs Range: -1,0, or n Default: 5		MulticastForwardRate Units: secs Range: -1(disabled),0 –32,676 Default: 5		Governs the multicasting of server announcements (groupname datagrams) to all the remote workstations in the server's domain.
		numworkbufs Units: buffers Range: 4 - 26 Default: 12		-		Sets the number of buffers per client used to store fast incoming data from the LAN for transmission over the slow telephone line. In Windows NT, the number of buffers is allocated dynamically.
		raslannets Units: names Range: -  Default: -		-		Indicates the names of LAN Manager networks made visible to remote clients. The Windows NT RAS server uses the network bindings parameters listed in the registry to identify available networks.
		remotelisten Units:  - Range: all=2, messages=1, none=0 Default: messages		RemoteListen Units:  - Range: all=2, messages=1, none=0 Default: messages		Sets remote NCB_LISTEN capability.
Replicator Service:		sizworkbufs Units: buffers Range: 1024 - 16,384 Default: 4400		SizWorkbufs Units: buffers Range: 1024 - 65536 Default: 4500		Sets the size of work buffers.
		exportpath Units: path Range:  -  Default: REPL \EXPORT		ExportPath Units: path Range:  -  Default: \WINNT\SYSTEM32 \REPL\EXPORT		Sets the path to the export directory. LAN Manager allows UNC path; Windows NT does not. Use Server Manager to set export path under Windows NT.
		exportlist Units: names Range: 0 - 32 Default:  -		Exportlist Units: names Range: unlimited Default:  -		Lists the import servers and domains to receive update notices.Use Server Manager to list namesunder Windows NT.
		guardtime Units: mins Range: 0 to (interval/2) Default: 2		Guardtime Units: mins Range: 0 to (interval/2) Default: 2		Specifies the number of minutes that the export directory must be stable before import servers can connect to it.
		importpath Units: path Range: 0 - 32 Default: REPL \IMPORT		ImportPath Units: path Range: unlimited Default: \WINNT\SYSTEM32 \REPL\IMPORT		Sets the path to the import directory. LAN Manager allows UNC path; Windows NT does not. Use Server Manager to set import path under Windows NT.
		importlist Units: names Range: 1 - 32 Default: 0		ImportList Units: names Range: unlimited Default: 0		Lists the export servers and domains to receive update notices.Use Server Manager to list namesunder Windows NT.
		interval Units: mins Range: 1 - 60 Default: 5		Interval Units: mins Range: 1 - 60 Default: 5		Sets the number of minutes that the subdirectories and files in the export directory are checked to determine whether changes are to be replicated.
		logon Units: name Range:  -  Default:  -		-		Sets the username that the import server uses to connect to the export server when no username is logged on at the import server.
		password Units: passwd Range:  -  Default:  -		-		Sets the password that the import server uses to connect to the export server when no username is logged on at the import server.
		pulse Units: cycles Range: 1 - 10 Default: 3		Pulse Units: cycles Range: 1 - 10 Default: 3		Specifies how often the export server sends update messages to an import server. The server waits (pulse * interval) minutes before sending each repeat notice.
		random Units: secs Range: 1 - 120 Default: 60		Random Units: secs Range: 1 - 120 Default: 60		Specifies the maximum time that the import servers can wait before requesting an update.
		replicate Units: -  Range: import/export/ both Default: import		Replicate Units: -  Range: 1=export; 2=import; 3=both Default: 3 (both)		Determines whether the server is to keep a master tree of directories and files to be replicated, is to replicate directories or files from another server, or both. Use Server Manager to set in Windows NT.
Server Service:		accessalert Units: violations Range: 0 - 65535 Default: 5		-		In LAN Manager, sets the number of resource-access violations that can occur within an alertsched interval before the server sends an alert message.
		alertnames Units: names Range: unlimited Default: null		Corresponds to Alertnames parameter in Alerter section of the Registry Units: names Range: unlimited Default: null		The list of users to whom administrator alerts are sent. In Windows NT, use Server Manager to list users to receive alert messages.
		alertsched Units: mins Range: 0 - 65535 Default: 5		AlertSched Units: mins Range: 1 - 65535 Default: 5		In LAN Manager and Windows NT, specifies how often the server checks alert conditions and sends needed alert messages.
		auditing Units:Boolean Range: yes=on,  no=off Default: on		-		Turns on auditing in LAN Manager. In Windows NT, use User Manager for Domains to set audit policy.
		autodisconnect Units: mins Range: -1 to 32767 Default: 120		Disc Units: mins Range: 0 to infinite Default: 15		Specifies the amount of idle time that a circuit is allowed before being disconnected. If the virtual circuit has any open files or searches, it is not automatically disconnected. When this parameter is set to a low value, it saves server resources, but hinders performance because of clients' overhead in reconnecting.
		autopath Units: path Default: null		-		Sets the location of the automatic server profile.
		autoprofile Range: load/save/both/ none Default: both		-		Determines behavior of the server's automatic profile under LAN Manager.
		diskalert Units: kilobytes Range: 0 - 65535 Default: 300		DiskSpaceThreshold Units: percent Range: 0 -  99% Default: 10%		For LAN Manager, sets the minimum number of free kilobytes of hard-disk space that must be available, otherwise the server sends an alert message. Increase this number if disk space on the server is a concern. For Windows NT, this setting is a percentage of remaining free disk space.
		erroralert Units: errors Range: 0 - 65535 Default: 5		ErrorThreshold Units: errors Range:1 - 65535 Default: 10		For both LAN Manager and Windows NT, sets the number of errors that can occur within an alertsched interval before the server sends an alert message.
		guestacct Units: name Range: up to 20 characters Default: GUEST		Use User Manager to enable guest account Units: name Range: up to 20 characters Default: disabled		Name of the server's guest account. The guest account on Windows NT Server is disabled by default.
		logonalert Units: integer Range: 0 - 65535 Default: 5		-		Sets the number of logon violations that can occur within an alertsched interval before a server sends an alert message.
		maxauditlog Units: K Range: 0 - 65535 Default: 100		Corresponds to MaxSize entry in Eventlog section of registry Units: K Range: limited by disk space Default: 512K		Sets the maximum number of kilobytes for the audit trail. When the size of the audit trail reaches this value, LAN Manager stops saving messages in the audit trail. The maximum size of the security (audit) log for Windows NT is set through Event Viewer.
		maxchdevjob Units: integer Range: 0 - 16 Default: 2		-		Sets the number of requests that the server accepts for all communication-device queues combined. Windows NT does not support comm queues.
		maxnetbios Units: integer Range: 1 - 18 Default: 18		-		Specifies the number of NetBIOS drivers the workstation or server can support.
		maxsessopens Units: integer Range: 1 - 8000 Default: 50		SessOpens Units: integer Range: 1 - 2048 Default: 2048		Sets the maximum number of files, pipes, and devices that one workstation can have open at the server.
		maxsessreqs Units: requests Range: 1 - 65535 Default: 50		MaxMpxCt Units: requests Range: 1 - 100 Default: 50		Sets the maximum number of resource requests that one workstation can have pending at the server.
		netioalert Units: integer Range: 0 - 65535 Default: 5		NetworkErrorThreshold Units: percent Range: 1 - 100 Default: 5		In LAN Manager, this parameter sets the number of network I/O errors that can occur within an alertsched interval before the server sends an alert message. Under Windows NT, triggers an alert whenever the percentage of failing network operations relative to total network operations exceeds this value during the AlertSched interval.
		noauditing Units: string Range:  -		Auditing policy  is set in User Manager for Windows NT.		Lists events that are not to be audited when auditing is turned on.
		numadmin Units: integer Range: 0 - 65535 Default: 64		-		Sets the maximum number of users who can simultaneously perform administrative tasks on a server. Windows NT has no limit setting.
		numfiletasks Units: integer Range: 1 - 8 Default: 1		-		Sets the number of processes designated to handle file and print requests from workstations.
		security Units: string Range: user or  share Default: user		No share security		Windows NT supports only user level security.
		sizreqbuf Units: bytes Range: 1024 - 32768 Default: 4096		SizReqBuf Units: bytes Range: 512 - 65536 Default: 4356		Specifies the size of request buffers that the server uses. Small buffers use less memory; large buffers can improve performance.
		srvanndelta Units: secs Range: 0 - 65535 Default: 3000		AnnDelta Units: millisecs Range: 0 - 65535 Default: 3000		Specifies time by which the announcement period can vary. This helps to prevent several servers from continuously announcing simultaneously, thereby reducing network load peaks.
		srvannounce Units: secs Range: 0 - 65535 Default: 60		Announce Units: secs Range: 1 - 65535 Default: 240		Specifies how often a non-hidden server announces itself to the network. More frequent announcements keep client-server tables up-to-date, but add to network overhead and processing on client computers, because clients must process every announcement.
		srvcomment Units: string Range: up to 48 characters Default: null		Comment Units: string Range:  -  Default: null		Provides the server's comment. This is sent in announcements and returned to NetServerGetInfo requests.
		srvhidden Units: string Range: yes, no Default: no		Hidden Units: Boolean Range: 0=false, 1=true Default: false		When this parameter is disabled, the server's name and comment can be viewed by others on the domain. When enabled, the server's name and comment are not announced. In Windows NT, setting this parameter is the only way to hide a server.
SNMP Service:		authtrap Units: Boolean Range: on or off Default: on		EnableAuthentication Traps Units: Boolean Range: 0 (off) or 1 (on) Default: on		A value of On (1) indicates that the SNMP service sends a trap whenever it receives a request that does not match any community name or host filter in its lists. Off (0) indicates that the SNMP service does not send a trap when this occurs.
		communitynames Units: names Range:  -  Default: public		ValidCommunities Units: names Range:  -  Default: public		Is one or more community names defining groups of hosts from which the SNMP service will accept requests.
		hostmasks Units: -  Range: A, H, N, or S Default: -		No hostmasks		For LAN Manager, specifies one or more address mask filters that the SNMP service applies to IP addresses of requesting hosts. When the address, after filtering through the mask, matches a specific network or subnet address, the SNMP service responds to the request. Windows NT does not support hostmasks; the hostmask or IP address is written directly into the registry.
		trapcommunity Units: name Range:  -  Default: public		TrapConfiguration Units: name Range:  -  Default: public		The name designating an Internet community of hosts to which the SNMP service sends traps.
		trapdestinations Units: names Range: -  Default: -		TrapConfiguration Units: names Range: -  Default: -		Specifies one or more host names or IP addresses defining hosts to which the SNMP service sends traps. TrapConfiguration contains the information embodied by both trapcommunity and trapdestination. Under the TrapConfiguration key you will find a key for each community and under the community key you will find the trap destination values for that community.
		version Units: -  Range:  -  Default: -		-		Specifies the SNMP service version number. Does not exist in Windows NT.
UPS Service:		batterytime Units: secs Range: sec Default: 60		BatteryLife Units: mins Range: 2– 720 Default: 2		Sets the number of seconds that the server can run on a battery before the UPS service initiates shutdown.
		cmdfile Units: path Range:  -  Default:  -		CommandFile Units: path Range:  -  Default:  -		Sets the path for the batch program to be run before the server is shut down. LAN Manager accepts any path; Windows NT accepts filenames with .CMD, .BAT, .COM or .EXE extensions that are located in the <systemroot>\system32 directory.
		port Units:  -  Range:  -  Default:  COM1		Port Units:  -  Range:  -  Default: COM1:		Specifies the name of the serial port the UPS is connected to. This parameter is located in CONFIG.SYS under LAN Manager.
		messdelay Units: secs Range: 0 - 120 Default: 5		FirstMessageDelay Units: secs Range: 0 - 120 Default: 5		Sets the number of seconds between the initial power failure and the first message sent to users.
		messtime Units: secs Range: 30 - 300 Default: 120		MessageInterval Units: secs Range: 5 - 300 Default: 120		Sets the number of seconds between messages sent to users notifying them of a power failure.
		recharge Units: mins Range: 5 - 250 Default: 100		RechargeRate Units: mins Range: 1 - 250 Default: 100		Sets the number of minutes of recharge time required for each minute of battery runtime.
		signals Units: 3 digits Range: High (1), Low (0) Default: 100		Options Units: 8 digits Range: High (1), Low (0) Default: –		Under LAN Manager, specifies whether the following signals are available from the battery: Power Failure, Low Battery, and Remote UPS Shutdown.
		voltlevels Units: 3 digits Range: High (1), Low (0) Default: 100				Under Windows NT, a single parameter defines the bit mask for messages related to options in the UPS dialog box, as the following: UPS Enabled PowerFailSignal LowBatterySignal CanTurnOff PosSigOnPowerFail PosSigOnLowBattery PosSigShutOff CommandFile
Workstation Service:		charcount Units: bytes Range: 0 - 65535 Default: 16		MaxCollectionCount  Units: bytes Range: 0 - 65535 Default: 16		Sets the number of characters in bytes that the workstation stores before sending them to a communication-device queue.
		chartime Units: millisec Range: 0 - 65535000 Default: 250		CollectionTime Units: millisec Range: 0 - 65535000 Default: 250		For LAN Manager, sets the time that workstation collects data before sending information to a comm queue. For Windows NT, sets the time that workstation collects data before sending information to a named pipe buffer. Changing this value may cause a named pipe applications performance to improve (but it will not effect SQL Server applications).
		charwait Units: sec Range: 0 - 65535 Default: 3600		CharWait Units: millisec Range: 0 - 65535 Default: 3600		Specifies time to wait for a requested communication device or named pipe to become available.
		computername, domain, othdomains Units: names Range: Computer and domain names can have 1 - 15 characters Default:  -		Must be set through Network option  in Control Panel Units: names Range: Computer and domain names can have 1 - 15 characters Default:  -		Unique names that identify computers, domains and additional domains to be shown in LAN Manager and Windows NT displays. Both LAN Manager and Windows NT require that these names be unique and between 1 – 15 characters. LAN Manager allows embedded spaces; Windows NT permits only computer names to have spaces. Of the three parameters, only Othdomains exists as a registry parameter and is used on Windows NT to list the LAN Manager domains available for browsing.
		keepconn Units: sec Range: 1 - 65535 Default: 600		KeepConn Units: sec Range: 1 - 65535 Default: 600		Specifies the maximum amount of time that a connection can be left dormant. Try increasing this value if your application closes and opens UNC files to a server at intervals greater than 10 minutes. This will decrease the number of reconnections made to a server.
		keepsearch Units: secs Range: 1 - 65535 Default: 600		Set to 5 minutes in Windows NT		Sets the number of seconds that the workstation maintains inactive file search information. In Windows NT, this value is always 5 minutes.
		maxcmds Units: commds Range: 5 - 255 Default: 16		Windows NT does not limit number of commands except as specified by the server		On LAN Manager, this sets the maximum number of NetBIOS commands that the workstation software can send simultaneously. Windows NT has no command limit but does limit the number of execution threads that can use the network simultaneously.
		maxerrorlog Units: K Range: 2 to total disk size Default: 100		Error logs sizes set in Event Viewer Units: 64K Range: 64K to total disk size Default: 512K		On LAN Manager, this sets the maximum size of the error log in kilobytes. Use Event Viewer in Windows NT to set log size maximum (settings must be in 64K increments).
		maxthreads Units: threads Range: 10 - 254 Default: 10		MaxCmds Units: threads Range: 0 - 255 Default: 15		Specifies the maximum number of execution threads that can use the network by means of the Workstation service. Increase this number if you simultaneously run multiple applications.
		maxwrkcache Units: K Range: 0 - 640 Default: 64		Set by Windows NT cache manager		On LAN Manager, sets the maximum number of kilobytes for the workstation's large transfer buffers. On Windows NT, this value is set dynamically depending on the network resources available.
		numalerts Units: alerts Range: 3 - 200 Default: 12		Not applicable in Windows NT		For LAN Manager, set the number of program tasks that can be waiting on alert condition.
		numcharbuf Units: buffers Range: 0 - 15 Default: 10		Windows NT allocates buffers as needed		Sets the number of pipe and device buffers for LAN Manager. On Windows NT, buffers are allocated as needed.
		numdgrambuf Units: buffers Range: 8 - 112 Default: 14		MailslotBuffers Units: buffers Range: Limited by memory Default: 5		numdgrambuf sets the number of buffers that process incoming datagrams (units of information that servers use to broadcast their presence). The closest Windows NT equivalent is Mailslotbuffers.
		numservices Units:  -  Range: -  Default: -		No limit to number of services in Windows NT		LAN Manager allows from 4 to 256 services to be listed in the internal service table. Windows NT has no limit.
		numworkbuf Units: buffers Range: 4 - 50 Default: 15		No limit to number of work buffers in Windows NT		Sets the number of buffers that workstations use to store data for transmission.
		sesstimeout Units: secs Range: 2 - 65535 Default: 45		SessTimeout Units: secs Range: 10 - 65535 Default: 45		Specifies the maximum amount of time that the workstation waits before disconnecting a session with a server that is no longer responding.
		sizcharbuf Units: bytes Range: 64 - 4096 Default: 512		SizCharBuf Units: bytes Range: 64 - 4096 Default: 512		Specifies the maximum number of bytes that will be written into named-pipe and character-device buffers. Adjusting this value may improve performance for a named-pipe application (but it will not affect SQL server applications).
		sizerror Units: bytes Range: 256 - 1024 Default: 1024		Self-configuring in Windows NT		Sets the size in bytes of the internal error buffer on LAN Manager. This is set dynamically in Windows NT.
		sizworkbuf Units: bytes Range: 1024 - 16384 Default: 4096		-		Sets the number of bytes for workstation buffers in LAN Manager. In Windows NT, the number is determined automatically, depending on server settings.
		wrkservices Units: names Range:  -  Default: messenger, netpopup, workstation		Use Services option in Control Panel to set for Windows NTUnits: -Range: Automatic, Manual or DisabledDefault: Clipbook Server, Computer Browser, EventLog, Messenger, Net Logon, Network DDE, Server, Workstation		Sets the services to start along with the Workstation service.


Server Heuristics

LAN Manager and Windows NT: Comparison of Network Parameters	2 of 4

Server Heuristics

The following LAN Manager server heuristics map to Windows NT Registry entries:

5/EnableFCOpens

Specifies whether MS-DOS file control blocks (FCBs) are folded together, so multiple remote opens are performed as a single open on the server. This saves resources on the server.

Range: Boolean
Default: 1 (True)

6/ThreadPriority

Specifies the priority of all server threads in relation to the base priority of the process. Higher priority can give better server performance at the cost of local responsiveness. Lower priority balances server needs with the needs of other processes on the system. Thread priority values 0 to 2 are relative to normal or background processes. The default value of 1 is equivalent to the foreground process. A value of 15 runs the server threads at real-time priority-which is not recommended.

Range: 0 - 9 (LAN Manager); 0, 1, 2 or 15 (Windows NT)
Default: 5 (LAN Manager); 1 (Windows NT)

10/ScavTimeout

Specifies the time that the scavenger remains idle before waking up to service requests. A smaller value for this parameter improves the response of the server to various events, but costs CPU cycles.

Range: 5 - 50 secs (LAN Manager); 1 - 300 secs (Windows NT)
Default: 5 secs (LAN Manager); 30 secs (Windows NT)

11/EnableSoftCompat

When the server receives a compatibility open request with read access, specifies whether the server maps it to a normal open request with shared-read access. Mapping such requests allows several MS-DOS computers to open a single file for read access.

Range: 0, 1, 2, 3(LAN Manager); 0 (False), 1 (True) (Windows NT)
Default: 2 (LAN Manager); 1 (Windows NT)

15/OplockBreakWait

Specifies the time that the server waits for a client to respond to an oplock break request. Smaller values can allow detection of crashed clients more quickly, but can potentially cause loss of cached data.

Range: 35 - 640 secs (LAN Manager); 10 - 180 secs (Windows NT)Autotuned Server Parameters

The LAN Manager parameters maxshares and maxusers set limits on the number of resources the server can share with the network and the number of users who can use the server simultaneously. The absolute upper limits are 500 resources and 1000 users. Windows NT Server sets no limit on your resources or users unless no memory is available.

Default: 35 secs (LAN Manager); 35 secs (Windows NT)

The LAN Manager parameters numbigbuf and numreqbuf set the memory buffers available to the server. Absolute upper limits are 80 big buffers and 300 request buffers. On Windows NT, there is no limit to the number buffers as long as memory is available. However, you can set an artificial limit by configuring Server settings in the Network option in Control Panel.


Workstation Heuristics

LAN Manager and Windows NT: Comparison of Network Parameters	3 of 4

Workstation Heuristics

The following LAN Manager workstation heuristics map to Windows NT workstation parameters:

0/UseOpportunisticLocking

Indicates whether the redirector should use opportunistic-locking performance enhancement. This parameter should be disabled only to isolate problems.

Default: 1 (True)

5/UseLockReadUnlock

Indicates whether the redirector will use the lock-and-read and write-and-unlock performance enhancements.

When this value is enabled, it generally provides a significant performance benefit. However, database applications that lock a range and don't allow data within that range to be read will suffer performance degradation unless this parameter is disabled.

Default: 1 (True)

11/UseRawRead and UseRawWrite

Enables the raw-read and write optimization. This provides a significant performance enhancement on a local-area network.

Default: 1 (True)

19/Use512ByteMaxTransfer

Specifies whether the redirector should only send a maximum of 512 bytes in a request to an MS-Net server regardless of the servers-negotiated buffer size. If this parameter is disabled, request transfers from the Windows NT redirector could cause the MS-Net server to crash.

Default: 0 (False)


Parameters for Network Protocols

LAN Manager and Windows NT: Comparison of Network Parameters	4 of 4

Parameters for Network Protocols

This section lists protocol parameters that LAN Manager and Windows NT have in common. LAN Manager protocol settings are found in the file PROTOCOL.INI. In Windows NT, these settings are a subset of the Registry. Settings that are not applicable to Windows NT are not shown. The upgrade does not transfer network protocols, but information is recorded in the file ADVISORY.TXT.

Information for each setting includes its units, range, default value, description, and location in either PROTOCOL.INI or the Registry.

NetBEUI (NBF)

PROTOCOL.INI		Windows NT Registry		Description
dlcretries Units: retries Range: 1 - 65535 Default: 8		LLCRetries Units: retries Range: 1 or higher; 0=no limit Default: 8		Specifies the number of times that NBF will retry polling a remote workstation after receiving a T1 time-out. After this many retries, NBF closes the link. Adjust this parameter only if NBF is connecting over networks with unusual reliability characteristics.
localring Units: Boolean Range: 0 or 1 Default: 0		QueryWithoutSourceRouting Units: Boolean Range: 0 or 1 Default: 0		When localring is 0, the source routing bit turns on immediately. When set to 1, it turns on when the packet has circled the ring 3 times.
ncbs Units: descriptors Range: 7 - 255 Default: 85		-		Specifies the number of NCB descriptors to allocate for managing NCBs submitted to the NetBEUI driver.
netbiosretries Units: retries Range: 1 - 50 Default: 2		AddNameQueryRetries, GeneralRetries, NameQueryRetries  Units: retries Range: 1 - 50 Default: 3		The number of times that NetBEUI retries transmissions at the NetBIOS level before assuming that the receiver is not present. Specifically, the number of times that NBF will retry sending STATUS_QUERY, FIND_NAME, NAME_QUERY, ADD_NAME_QUERY, ADD_GROUP_NAME_QUERY, and NAME_IN_CONFLICT frames. Adjust this parameter only if NBF is registering addresses on a network that drops many packets.
netbiostimeout Units: millisec Range: 500 - 9890 Default: 500		GeneralTimeout,  AddNameQueryTimeout, NameQueryTimeout Units: 100-nanoseconds Range:  – Default: 500000		Specifies the time-out between NetBEUI sending successive NAME_QUERY, STATUS_QUERY and FIND_NAME, ADD_NAME_QUERY and ADD_GROUP_NAME_QUERY frames. Adjust this parameter only if NBF is registering addresses on a network with slow computers or over a slow network.
sessions Units: sessions Range: 3 - 254 Default: 40		-		Sets the maximum number of NetBIOS sessions that can be open at one time. There is no limit under Windows NT.
t1 Units: millisec Range: 0 - 65535  Default: 500		DefaultT1Timeout Units: 100-nanoseconds Range:  -  Default: 6000000 (6 secs)		Specifies the initial value for the T1 time-out. T1 controls the time that NetBEUI waits for a response after sending a logical link control (LLC) poll packet before resending it. Adjust this parameter only if NBF will be connecting over slow networks or to slow remote computers (although NBF does adapt).
t2 Units: millisec Range: 50 - 65535 Default: 200		DefaultT2Timeout Units: 100-nanoseconds Range:  -  Default: 1500000 (1.5 secs)		Specifies the initial value for the T2 time-out. T2 controls the time that NBF can wait after receiving an LLC poll packet before responding. It must be much less than T1; one-half or less is a good rule of thumb. Adjust this parameter only if NBF will be connecting over slow networks or to slow remote computers.
ti Units: millisec Range: 1000 - 65535 Default: 30000		DefaultTiTimeout Units: 100-nanoseconds Range:  -  Default: 300000000 (30 secs)		Specifies the initial value for the Ti time-out. Ti is the inactivity timer. When it expires, NBF sends an LLC poll packet to ensure that the link is still active. Adjust this parameter only if NBF is connecting over networks with unusual reliability characteristics, or over slow networks, or to slow computers.
TCP/IP Service:
PROTOCOL.INI		Windows NT Registry		Description
bcastaddr Units: address (x.x.x.x) Range: 0.0.0.0 or255.255.255.255 Default: 255.255.255. 255		BroadcastType Units: integer Range: 0 or 1 Default: 1		Determines IP address used to broadcast name requests and name queries.
ipaddress0 Units: address (x.x.x.x) Range: -  Default: No default		IpAddress0 Units: address (x.x.x.x) Range: -  Default: No default		Identifies the internet protocol address, a unique number that identifies the computer to other computers on the network.
scope Units: string Range: -  Default: No default		ScopeID Units: string Range:  -  Default: No default		A character string that specifies the NetBIOS scope. The default is a null scope. ScopeID is found in \SYSTEM\CurrentControlSet\Services\NBT\Parameters.
subnetmask0 Units: address (x.x.x.x) Range:  -  Default: No default		Subnetmask0 Units: address (x.x.x.x) Range:  -  Default: No default		A series of bits used to identify the subnet number portion of an IP address.
defaultgateway Units: gateway Range: -  Default: No default		Defaultgateway Units: gateway Range:  -  Default: No default		The gateway used when the IP address is not known or is not on the local network.
AppleTalk:
PROTOCOL.INI		Windows NT Registry		Description
aarpretries Units: integer Range: 15 - 900 Default: 15		AarpRetries Units: integer Range: 10 - 900 Default: 10		Specifies the maximum number of AppleTalk address-resolution protocol packets to be sent by the AppleTalk protocol. Note that this parameter is global for LAN Manager and port-specific for Windows NT.
global:
enablerouter Units: - Range: yes or no Default: no		EnableRouter Units: - Range: 1 or 0  Default: 0		Tells the AppleTalk protocol whether routing needs to be started on this computer. If routing is started, Macintosh workstations connected to any of the networks that this computer is on should be able to use the file and print servers for Macintosh. 0 = not routed; 1 = routed.
defaultport Units:  - Range:  - Default: -		DefaultPort Units: - Range:  - Default: - DesiredZone Units: zone name Range:  - Default: -		DefaultPort is split into two parameters under Windows NT. DefaultPort specifies whether this port is the server's default port, if protocol is routed.DesiredZone specifies the zone in which the Services for Macintosh service is present. If this value is not set, SFM is present in the default zone for that network.
port-specific:
defaultzone Units:  -  Range:  -  Default:  -		DefaultZone Units:  -  Range:  -  Default:  -		Contains the default zone for this network if routing enabled. Under Windows NT, if the adapter is seeding the network, the default zone is chosen when you configure SFM using the Network icon in Control Panel.
ddpchecksums Units: - Range: yes or no Default: no		DdpCheckSums Units: - Range: 1 or 0 Default: 0		Tells the AppleTalk protocol whether to compute checksums in the DDP layer. If this entry is Yes (or 1), the AppleTalk protocol uses sums in the DDP layer.
networkrange Units: integer or hex Range: 1 - 65,279 or 00x001-0xFEFF Default:  -		NetworkRangeLowerend to NetworkRange UpperEnd Units: integer Range: 1 -  65,279  for both lower and upper  end parameters Default:  -		Specifies the range of network numbers for the network connected to this port. Valid only if routed.
zonelist Units: - Range:  - Default: -		ZoneList Units: - Range:  - Default: -		Specifies the zones associated with the network attached to this port. Valid only if routed.
Comtokr (DLC):
PROTOCOL.INI		Windows NT Registry		Description
t1_tick_one Units: 40 millisec Range: 1 - 255 Default: 5		T1TickOne Units: 40 millisec Range: 1 - 255 Default: 5		Sets the retransmission-timer "short tick" value in units of 40 milliseconds.
t1_tick_two Units: 40 millisec Range: 1 - 255 Default: 25		T1TickTwo Units: 40 millisec Range: 1 - 255 Default: 25		Sets the retransmission-timer "long tick" value in units of 40 milliseconds.
t2_tick_one Units: 40 millisec Range: 1 - 255 Default: 1		T2TickOne Units: 40 millisec Range: 1 - 255 Default: 1		Sets the delayed acknowledgment time "short tick" value in units of 40 milliseconds.
t2_tick_two Units: 40 millisec Range: 1 - 255 Default: 10		T2TickTwo Units: 40 millisec Range: 1 - 255 Default: 10		Sets the delayed acknowledgment time "long tick" value in units of 40 milliseconds.
ti_tick_one Units: 40 millisec Range: 1 - 255 Default: 25		TiTickOne Units: 40 millisec Range: 1 - 255 Default: 25		Sets the inactivity-timer "short tick" value in units of 40 milliseconds.
ti_tick_two Units: 40 millisec Range: 1 - 255D efault: 125		TiTickTwo Units: 40 millisec Range: 1 - 255 Default: 125		Sets the inactivity-timer "long tick" value in units of 40 milliseconds.


Command, Utility, and API Compatibility
Appendix C	1 of 8

Command, Utility, and API Compatibility

This appendix contains the following information:

Windows NT support for LAN Manager network commands

Windows NT support for LAN Manager utilities

LAN Manager API calls from remote clients that are not supported on Windows NT

Support for OS/2 API calls, applications, and commands


LAN Manager Network Commands
Command, Utility, and API Compatibility	2 of 8

LAN Manager Network Commands

The following table lists LAN Manager network commands and their equivalents in Windows NT. The table doesn't show the effects of every option of each command, and only shows those Windows NT commands that have LAN Manager equivalents. For more information about the options of Windows NT Server commands, see the Windows NT online command reference; for information about LAN Manager commands, see the LAN Manager administrative documentation.

LAN Manager command		Windows NT command		Explanation		Change or new procedure in Windows NT
net access		-		Displays the permissions (trustee rights) for a directory.		Use File Manager to set directory permissions.
net account		net account		Displays or sets password and logon requirements of servers in a domain.		Server roles cannot be set for Windows NT and lockout is a function of Windows NT security.
net admin		-		Administration tool for local and remote LAN Manager computers.		Use the Windows NT administrative tools to administer the network.
net audit		-		Displays or clears audit-trail entries.		Use Event Viewer to track network resource use and clear audit entries. Use User Manager to set audit policies and File Manager to audit file and directory use.
net comm		-		Controls information about communication-device queues.		Communication devices are not currently supported.
net config		net config		Displays configurable services that are running, and displays and changes settings for a service.		Use Services option in Control Panel to display and control service activity.
net config peer		-		Displays or changes settings for the Peer service.		Peer functionality is an inherent part of Windows NT and no longer requires separate commands.
net config server		net config server		Displays or changes settings for the Server service.		Most network services are self-configuring. Only the switches /autodisconnect, /srvcomment, and /hidden can be configured.
net config workstation		net config workstation		Displays or changes settings for the Workstation service.		Most network services are self-configuring. Only the switches /charcount, /chartime, and /charwait can be configured.
net console		-		Starts the console version of the LAN Manager screen.		Press CTRL+ALT+DEL to lock workstation.
net continue		net continue		Reactivates suspended services when typed at a server and reactivates paused shared printers when typed at a workstation.		Use Print Manager to reactivate printers.
net copy		-		Copies files across the network from a source to a destination without first moving to a local computer.
net device		-		Displays information about shared printers and communication devices, and controls active print jobs.		Use Print Manager to display information about printers.
net error		-		Displays or clears error messages stored in the error log.		Use Event Viewer to view and manage error logs.
net file		net file		Displays the names of all open shared files on a server and the number of file locks, if any, on each file. This command also closes individual shared files and removes file locks.		Functionality is also available through Server option in Control Panel.
net forward		-		Routes incoming messages to another workstation.		You cannot forward network messages.
net group		net group		Adds, displays, or modifies global groups.
net help		net help		Provides a list of network commands and topics you can get help with, or provides help with a specific command or topic.
net helpmsg		net helpmsg		Provides help with a network error message.
net log		-		Controls or displays information about message logging.		Message logging is not supported.
net logoff		-		Logs a username off the network.		Press CTRL+ALT+DEL to log off.
net logon		-		Logs a username on to the network.		Press CTRL+ALT+DEL to log on.
net move		-		Moves files across the network from a source to a destination without moving to the local computer.
net name		net name		Adds, displays, or deletes messaging names (aliases) on a workstation.
net password		-		Changes the password for a user account on a server or in a domain.		Press CTRL+ALT+DEL to change a user password.
net pause		net pause		Pauses the following LAN Manager services: netlogon, netrun, nvalert, peer, server, snmp, workstation.		Pauses the following Windows NT services: Alerter, Browser, Messenger, Netlogon, Remoteboot, Replicator, Server, Telnet, and Workstation. Use Print Manager to pause printers.
net print		net print		Displays the jobs currently in a printer queue. Options of these commands also let you manage the jobs in a queue: delete them, change their printing order, or purge the entire queue.		May be used to view and delete print jobs. Use Print Manager to manage printers.
net run		-		Runs a program remotely on the server while you are working at a workstation.		Windows NT does not currently support remote execution of files.
net send		net send		Sends a broadcast message or file to other computers or users on the network.		Only sends messages (not files) to users or groups. The \broadcast switch is not supported.
net separator		-		Assigns a separator page to a printer.		Use Print Manager to assign separator pages.
net share		net share		Creates, deletes, or displays shared resources.		Use Print Manager to share printers. Communication-devices are not supported in this release.
net session		net session		Displays a list of users currently using the server.
net start		net start		Starts the following service in LAN Manager: alerter, messenger, netlogon, netpopup, netrun, nvalert, peer, remoteboot, replicator, server, snmp, timesource, ups, and workstation.		Services can be configured to start automatically using Control Panel.
net start alerter		net start alerter		Starts and configures the Alerter service.		Alerter service is self-configuring.
net start messenger		net start messenger		Starts and configures the Messenger service.		Messenger service is self-configuring.
net start netlogon		net start "net logon"		Starts and configures Netlogon service.		The Net logon service is self-configuring. Service name is now two words.
net start netpopup		-		Starts Netpopup service.		Messages are processed automatically.
net start netrun		-		Starts the Netrun service. Netrun lets users run programs on a remote computer.		Windows NT does not support remote execution of programs.
net start nvalert		-		Starts the NVAlert service, which reports error and status information to an IBM NetView® network-management host.
net start peer		-		Starts the Peer service, which enables a workstation to perform most server functions.		Peer functionality built in.
net start remoteboot		net start remoteboot		Starts Remoteboot service, which allows workstations to be started remotely.		Remoteboot service is self-configuring.
net start replicator		net start "directory replicator"		Starts and configures Replicator service, which ensures that designated files are identical on specified servers.		Use Server Manager to configure the Directory Replicator service.
net start server		net start server		Starts and configures Server service, which enables resource sharing on the network.		Use Server Manager to configure the Server service.
net start snmp		net start  snmp		Starts the SNMP service, which allows a server to report its current status to a remote management program on a TCP/IP network.		New options permit logging.
net start timesource		-		Starts the Timesource service, which designates a particular server as the time source for the domain.		Functions included in Server service.
net start ups		net start ups		Starts and configures the UPS service. This service is used with a battery to protect a server from data loss during power failure.
net start workstation		net start workstation		Starts and configures the Workstation service, which enables a computer to connect to and use network resources.
net statistics		net statistics workstation or net statistics server		Displays performance statistics for a server or workstation. With LAN Manager, you can use either the net statistics command or the Net Admin interface.		With Windows NT Server, you can use Server Manager. The statistics log cannot be cleared.
net status		net config server or net share		Displays configuration settings and shared resources on the local server.		Incorporated in other commands.
net stop		net stop		Stops the following LAN Manager services: alerter, messenger, netlogon, netpopup, netrun, peer, remoteboot, replicator, server, timesource, ups, and workstation.		Stops the following Windows NT services: Alerter, Browser, Directory Remoteboot, Replicator, Messenger, Net logon, Server, SNMP, and Workstation.¹
net time		net time		Synchronizes the workstation's clock with that of a server or domain, or displays the time for a server or domain.
net use		net use		Connects a workstation to or disconnects a workstation from a shared resource. Displays information about workstation connections.		The /user switch can be used to connect as a different user. The /persistent switch has only yes and no values. The /volume switch connects to NetWare® volumes. Communication-device queues are not supported.
net user		net user		Creates, modifies, and deletes user accounts.		Switches /logonserver, /maxstorage, /operator, and /privilege are not supported.
net version		winver		Displays version of operating system running at local computer.		New command name.
net view		net view		Displays a list of servers or a list of resources being shared by the server.		The /domain switch permits viewing of domains and computers in a specified domain. The /network switch permits viewing of NetWare networks.
net who		-		Displays connections to a server.		Use Server Manager to view server connections.
¹  Windows NT 3.5 Server has many additional services. See the Windows NT Server System Guide for more information.


LAN Manager Utilities
Command, Utility, and API Compatibility	3 of 8

LAN Manager Utilities

The following table lists LAN Manager and OS/2 utilities and, where applicable, their equivalent in Windows NT.

Utilities

LAN Manager utility		Windows NT equivalent utility		Description
addname		Not necessary because of changes in LMHOSTS file.		Lets TCP/IP users access resources of a LAN Manager server on a different TCP/IP network using a network gateway.
at		at		Schedules commands and programs to run on a server at a specified time and date.
backacc		-		Backs up the permissions for high-performance file system 386 (HPFS386) volumes, and backs up the NET.ACC and NET.AUD files.
cache		N/A		Sets up file-system caching for high-performance file system 386 (HPFS386) volumes.
chkstor		-		Checks the amount of storage used for home directories on a server.
errpopup		N/A		Executes a program and displays error messages from the program in a pop-up window.
ftadmin, ftcmd, ftmonit, ftsetup		Use Disk Manager to administer the fault tolerance system.		Utilities to manage the fault tolerance system.
logoff, logon		Not applicable because no local security.		Logs a username off and on a 386 or 486 server with local security, or logs a username off from the network.
nmconfig		Use the Network or Services option in Control Panel.		Reconfigures or removes services such as NVAlert and SNMP.
ndisk, nprep		Replaced by Network Client Administrator.		Utilities for over-the-network installation. For Windows NT, use the Network Client Administrator to install client software.
ping		ping		Verifies a physical connection to a remote computer.
prtsc		-		Flushes the print spooler when an application fails to send an end-of-job signal.
restacc		-		Restores the permissions for high-performance file system 386 (HPFS386) volumes that have been stored with the backacc utility.
rpldsabl, rplenabl, rplinst, rplsetup		rpldsabl, rplenabl, rplcnv		Utilities to manage Remoteboot service.


LAN Manager Network APIs
Command, Utility, and API Compatibility	4 of 8

LAN Manager Network APIs

Windows NT provides support for most remote API calls from down-level clients. The following table shows calls that are not supported when received from a down-level client. In some cases, support exists for a more current version of the API call, such as for NetFileEnum.

For more information on Windows NT equivalents, see the Microsoft Win32 Programmer's Reference.

LAN Manager API calls		Windows NT equivalent, if supported
DosPrintDest		-
DosPrintDriverEnum		-
DosPrintPortEnum		-
DosPrintQProcessorEnum		-
NetAccessCheck		-
NetAlertRaise		-
NetAlertStart		-
NetAlertStop		-
NetAuditClear		-
NetAuditOpen		-
NetAuditRead		-
NetAuditWrite		-
NetConfigGet2		-
NetConfigGetAll2		-
NetConfigSet		-
NetErrorLogClear		-
NetErrorLogOpen		-
NetFileClose		-
NetFileEnum		NetFileEnum2
NetFileGetInfo		-
NetHandleSetInfo		-
NetMessageFileSend		-
NetMessageLogFileGet		-
NetMessageLogFileSet		-
NetMessageNameFwd		-
NetMessageNameUnFwd		-
NetNetBiosEnum		-
NetNetBiosGetInfo		-
NetProfileLoad		-
NetServerAdminCommand		-
NetServerEnum		NetServerEnum2
NetServiceStatus		-
NetStatisticsClear		-
NetStatisticsGet		NetStatisticsGet2
NetUseAdd		-
NetUseDel		-
NetUseEnum		-
NetUseGetInfo		-
NetUserAdd		-
NetUserPasswordSet		-
NetUserSetInfo		-
NetUserValidate2		-
NetWkstaSetUID		NetWkstaSetUID2


OS/2 Applications, APIs, and Commands
Command, Utility, and API Compatibility	5 of 8

OS/2 Applications, APIs, and Commands

The OS/2 subsystem allows OS/2 16-bit character-based applications to run directly under Windows NT with essentially no modification. End-users can launch a character-based or video input/output (VIO) application from the Windows NT command prompt, File Manager, Program Manager, or from invocation within a Windows 32™ or OS/2 application. They can create a single batch file that can launch any combination of MS-DOS, Windows™, or OS/2 programs. Windows NT recognizes an OS/2 application from information stored in the header of the executable file; it then calls the OS/2 subsystem to load the application.


Applications
Command, Utility, and API Compatibility	6 of 8

OS/2 Applications, APIs, and Commands

Applications

If you try to run an application that is not supported (see the list under "Supported Applications," later in this section), you have the following choices:

If this is a bound application (one that can run under both OS/2 and MS-DOS), you can try to run it under the MS-DOS subsystem, where it might succeed. To do so, run forcedos from the command line:

forcedos [/D directory] filename [parameters]

where:

/D directory

Is the current directory for the application to use.

filename

Is the application to start.

parameters

Are the parameters to pass to the application.

If this is not a bound application and you have the source code, you can recompile the source without the unsupported API calls (which are specified in the error message that appears when you try to run the application). If you don't have the source, contact the application's developer.

If you never run an OS/2 application, the subsystem does not use any Windows NT resources. When you run an application, the process OS2SRV is loaded and continues to exist even after the application is finished.

Supported Applications

OS/2 1.X 16-bit applications on x86 computers

Character-based applications

Unsupported Applications

OS/2 2.x applications.

Presentation Manager applications.

AVIO (advanced VIO) applications.

OS/2 applications on RISC machines.

Custom device drivers (those not included with OS/2 itself). These must be rewritten to the Windows NT device driver interface.

Applications that directly access hardware memory or I/O ports at Ring 2 or below. For example, applications that directly access video memory to manipulate text or graphics are not supported. Applications that rely on the statement IOPL=YES in CONFIG.SYS to gain access to Ring 2 I/O privileges are not supported.

Partially Supported Applications

VIO (video input/output) applications. See the following description of API calls for more detail.


APIs
Command, Utility, and API Compatibility	7 of 8

OS/2 Applications, APIs, and Commands

APIs

Supported API Calls

API calls with the following prefixes are supported:

Dos (except DosDevIOCtl and DosDevIOCtl2, which are partially supported)

Kbd (except those that conflict with the security and robustness of Windows NT)

Mou (except those that require PM or AVIO)

Vio (except those that conflict with the security of Windows NT by accessing the physical video hardware and those that require PM or AVIO)

WinQueryProfile and WinWriteProfile

The following LAN Manager Net APIs:

NetAccessAdd

NetAccessGetInfo

NetAccessSetInfo

NetAccessDel

NetBios v3.0

NetBiosClose

NetBiosEnum

NetBiosGetInfo

NetBiosOpen

NetBiosSubmit

NetGetDCName

NetHandleGetInfo

NetMessageBufferSend

NetServerDiskEnum

NetServerEnum2

NetServerGetInfo

NetServiceControl

NetServiceEnum

NetServiceGetInfo

NetServiceInstall

NetShareAdd

NetShareDel

NetShareEnum

NetShareGetInfo

NetUseAdd

NetUseDel

NetUseEnum

NetUseGetInfo

NetUserEnum

NetUserGetInfo

NetWkstaGetInfo

Unsupported API Calls

API calls with the following prefixes are not supported:

Dev

Gpi

Kbd (those that conflict with the security and robustness of Windows NT)

Mou (those that require PM or AVIO)

Vio (those that conflict with the security of Windows NT by accessing the physical video hardware and those that require PM or AVIO)

Win (except WinQueryProfile and WinWriteProfile APIs)

Partially Supported API Calls

The following API calls are partially supported:

DosDevIOCtl, DosDevIOCtl2

VioGetConfig

VioGetMode, VioSetMode

VioGetState, VioSetState


Commands
Command, Utility, and API Compatibility	8 of 8

OS/2 Applications, APIs, and Commands

Commands

Windows NT supports the OS/2 configuration commands shown in the table below. If you use commands that are not supported, Windows NT ignores them.

Command	Function

protshell	Specifies the command interpreter. Only the Windows NT command interpreter is supported.

devicename	Specifies a user-defined Windows NT device driver used by OS/2 applications.

libpath	Specifies the location of OS/2 16-bit dynamic-link libraries.

set	Sets environment variables.

country	Sets a country code that defines country-dependent information such as time, date, and currency conventions.

codepage	Specifies which code pages your system is prepared to use.

devinfo=KBD	Specifies the information the keyboard needs in order to use a particular code page.


The LMBAKENV.DAT File
Appendix D	1 of 2

The LMBAKENV.DAT File

The LMBAKENV.DAT file is created when you back up your LAN Manager environment using the backenv utility. LMBAKENV.DAT contains a record of LAN Manager environment and service settings; the restenv utility uses the information in the LMBAKENV.DAT file during the upgrade.

LMBAKENV.DAT is a text file with labeled sections, similar to LANMAN.INI. The file format is:

[section]

keyword=value list	; Comments

For a complete list of LAN Manager parameters and their equivalents under Windows NT Server, see Appendix B, "LAN Manager and Windows NT: Comparison of Network Parameters."

For more information on the restenv utility, see Chapter 8, "Upgrade Utilities Reference."


Sample File Listing
The LMBAKENV.DAT File	2 of 2

Sample File Listing

The following is a list of possible LMBAKENV.DAT entries. If an entry transfers to Windows NT Server, the equivalent Registry entry appears as a comment.

The restenv utility does not port hardware settings because there is no guarantee that you are upgrading to equivalent hardware. Remember that the upgrade does not transfer printer queue information, network interface card information, or protocol settings if Windows NT applies them on a per network card basis. Instead, it compares protocol settings before and after the upgrade and notes discrepancies in the RESTENV.LOG file.

;C:\UPGRADE\lmbakenv.dat
[floppyisk1]
disktype=
[floppydisk2]
disktype=
[fixed disk volume1]
disktype=
cylinders=
heads=
sectors per track=
freebytes=
totalbytes=
filesystem=
mirror=
[disk controller1]
controllertype=
[disk controller2]
controllertype=
[networks]
net1=
net2=
[workstation]	;Workstation parameters are written to Registry location: HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services \LanmanWorkstation
computername=
domain=
othdomains=	;OtherDomains
charcount=	;MaxCollectionCount
chartime=	;CollectionTime
charwait=	;CharWait
keepapis=
keepconn=	;KeepConn
keepsearch=
mailslots=
maxcmds=
maxerrorlog=
maxthreads=	;MaxCmds
maxwrkcache=
numalerts=
numcharbuf=
numdgrambuf=
numservices=
numworkbuf=
sesstimeout=	;SessTimeout
sizcharbuf=	;SizCharBuf
sizerror=
sizworkbuf=
wrkheuristics=	;0, 5, 11, and 19 transfer to: UseOpportunisticLocking, UseLockReadUnlock, UseRawRead, UseRawWrite, Use512ByteMaxTransfer
wrknets=
wrkservices=	;Restenv configures listed services to start automatically under Windows NT
[messenger]	;Settings not applicable under Windows NT
logfile=
sizmessbuf=
[netshell]	;Service not applicable under Windows NT
refresh=
remote=
username=
[version]
Services_For_Macintosh=
lan_manager=
[server]	;Server parameters are written to Registry location: HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\LanmanServer \Parameters.
accessalert=
alertsched=	;AlertSched
alertnames=	;AlertNames (written to \Services\Alerter\Parameters)
auditing=	;If yes, upgrade starts Auditing Service
autodisconnect=	;Disc
autoprofile=
autopath=
diskalert=
erroralert=	;ErrorThreshold
guestacct=
logonalert=
maxauditlog=
maxchdevjob=
maxchdevq=
maxchdevs=
maxconnections=
maxlocks=
maxnetbios=
maxopens=
maxsearches=
maxsessopens=
maxsessreqs=
maxsessvcs=
maxshares=
maxusers=
netioalert=
noauditing=
numadmin=
numbigbuf=
numfiletasks=
numreqbuf=
security=
srvcomment=	;Comment
sizreqbuf=
srvanndelta=	;AnnDelta
srvannounce=	;Announce
srvheuristics=	;5, 6, and 10 transfer as EnableFCBOpens, ThreadPriority, and ScavTimeout
srvhidden=	;Hidden
srvnets=
srvservices=	;Restenv configures services listed to start automatically under Windows NT. If timesource service is present, restenv configures Windows NT Server to be a time source
userpath=
[alerter]
sizalertbuf=
[netrun]	;Service not applicable to Windows NT.
maxruns=
netpath=
[replicator]	;Replicator parameters are written to Registry location: HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\Replicator \Parameters
exportpath=	;ExportPath
exportlist=	;ExportList
extent=
guardtime=	;Guardtime
importlist=	;ImportList
importpath=	;ImportPath
integrity=
interval=	;Interval
logon=
password=
pulse=	;PulseInterval
random=	;Random
replicate=	;Replicate
tryuser=
[ups]	;UPS parameters are written to Registry location: HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\UPS\Parameters
batterytime=	;BatteryLife
messdelay=	;FirstMessageDelay
messtime=	;MessageInterval
recharge=	;RechargeRate
signals=	;Options
voltlevels=	;Options
cmdfile=	;CommandFile
port=	;Port:
[netlogon]	;Netlogon parameters are written to Registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\Netlogon\Parameters
pulse=	;Pulse
randomize=	;Randomize
scripts=	;Scripts
update=	;Update
[remoteaccess]	;RAS parameters are written to Registry location: HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\RemoteAccess \Parameters and \Parameters\NetBIOSGateway
audit=	;EnableAudit
authenticateretries=	;AuthenticateRetries
authenticatetime=	;AuthenticateTime
autodisconnect=	;Autodisconnect (x 60)
enablebroadcast=	;EnableBroadcast
maxdynmem=
maxnames=	;MaxNames
maxsessions=	;MaxSessions
multicastforwardrate=	;MulticastForwardRate
numworkbufs=
raslannets=
remotelisten=	;RemoteListen
sizworkbufs=	;SizWorkBufs
[remoteboot]	;Remoteboot
rpl=
rpldir=
maxthreads=
forcedefaultboot=
rpllogonkbd=
rplfiles=
binfiles=
tmpfiles=
xnssap=
[snmp]	;Snmp parameters are written to Registry location: HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\Snmp\Parameters
authtrap=	;EnableAuthenticationTraps
communitynames=	;ValidCommunities
hostmasks=
version=
trapdestinations=	;TrapConfiguration (under community key)
trapcommunity=	;TrapConfiguration (under community\trap destination key)
[tcpip_node]	;Service not applicable under Windows NT
Hub=
HubIPAddr=
Domains=
DoUAS=
DoView=
DoLogon=
DoWho=no
DoSend=no
DoRepl=
DoUser1=no
DoUser2=no
DoUser3=no
UserMailSlot1=
UserMailSlot2=
UserMailSlot3=
[services]
snmp=
workstation=
server=
messenger=
netpopup=
alerter=
netrun=
replicator=
ups=
netlogon=
remoteboot=
timesource=
remoteaccess=
MacFile=
MacPrint=
[MacFile]	;No equivalents under Windows NT
afpinfoineas=
auditloggin=
auditsessions=
gedirinterval=
gediraudit=
macguest=
maxaspclients=
[AppleTalk]	;Where noted, parameter values are compared to AppleTalk equivalent settings in Registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\adapter_name#\Parameters \AppleTalk, where adapter_name# indicates a networkadapter card name
aarpretries=	;AarpRetries
bindings=
drivername=
enablerouter=	; EnableRouter
selectors=
port=
defaultport=	; DefaultPort
defaultzone=	; DefaultZone
ddpchecksums=	; DdpCheckSums
zone=
networkrange=	; NetworkRangeLowerEnd to NetworkRangeUpperEnd
porttype=
recvbugs=
xferbufs=
xmitbufs=
zonelist=	; ZoneList
errorfreq=
warningfreq=
[MacPrint]	;Settings not transferred
auditlogging=
ppdfiledirectory=
sharecheckinterval=
[MacQueues]	;Not transferred to Windows NT. Settings written to ADVISORY.TXT. Use this information to set up Macintosh printers.
pscript=
apple1=
[AppleTalkPrinters]	;Settings not transferred
LWRITER=
[uses]	;If drive letters are available, equivalent uses are restored under Windows NT
driveletter=
[protocol 1]	;Written to Registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\Nbf\Parameters
transport=netbeui
bindings=
dlcretries=	;LlcRetries
localring=	;QueryWithoutSourceRouting
netbiosretries=	;AddNameRetries, GeneralRetries, AddNameQueryRetries
netbiostimeout=	;AddTimeout;GeneralTimeout; AddNameQueryTimeout
t1=	;DefaultT1Timeout
t2=	;DefaultT2Timeout
ti=	;DefaultTiTimeout
[protocol2]	;Where noted, parameter values are compared to TCP/IP equivalent settings in Registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\Tcpip\Parameters\adapter name
transport=TCP/IP
bindings=
bcastaddr=	; BroadcastType
defaultgateway0=	; DefaultGateway
ipaddress0=	; IpAddress0
nbsessions=
numncbs=
scopeid=	; ScopeID
subnetmask0=	; SubnetMask0
tcpsegmentsize=
tcpwindowsize=
[protocol3]	;Where noted, parameter values are compared to DLC equivalent settings in Registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\DLC\Parameters\adapter name
transport=comtokr
bindings=
syspath=
t1_tick_one=	; T1TickOne
t1_tick_two=	; T1TickTwo
t2_tick_one=	; T2TickOne
t2_tick_two=	; T2TickTwo
ti_tick_one=	; TiTickOne
ti_tick_two=	; TiTickTwo
[protocol4]
transport=ras
Binding1=
BindingInstance1=
[share]	; Equivalent shares are set up under Windows NT if no conflicts exist.
IPC$=
ADMIN$=
A$=
B$=
C$=
USERS=
NETLOGON=
PUBLIC=
CDRIVE=
DDRIVE=
SCRIPTS=
[share perm]	;Share permissions are not transferred
IPC$=
ADMIN$=
A$=
B$=
C$=
USERS=
NETLOGON=
PUBLIC=
CDRIVE=
DDRIVE=
SCRIPTS=
[share passwords]	;Not applicable under Windows NT
IPC$=
ADMIN$=
A$=
B$=
C$=
USERS=
NETLOGON=
PUBLIC=
CDRIVE=
DDRIVE=
SCRIPTS=
[share remarks]	;Share remarks are transferred to Windows NT
IPC$=
ADMIN$=
A$=
B$=
C$=
USERS=
NETLOGON=
PUBLIC=
CDRIVE=
DDRIVE=
SCRIPTS=
[printshare]	;Not transferred to Windows NT
printsharename=
[comshare]	;Not applicable under Windows NT
comsharename=
[printerqueue1]	;Not transferred to Windows NT. All settings written to ADVISORY.TXT. Use this information to install printers under Windows NT
queuename=
description=
printers=
destinations=
priority=
separator file=
activate time=
deactivate time=
[mouse]
mousetype=
port=
[netcard]	; Adapter card parameters are set by Windows NT Setup during installation. Restenv records pre and post upgrade adapter card names in RESTENV.LOG.
drivername=
interrupt=
ioaddress=
mmioaddress=
dmachannel=
transceiver=
netaddress=
[countryinfo]	;Compared with existing Windows NT locale to see if match occurs.
countrycode=
codepage=
[ras setting1]	; Settings written to ADVISORY.TXT. Use this information to install Remote Access Service after completing the upgrade.
Section Header=
MODEM=
MAXBAUD=
DIALIN=
DIALOUT=
[security]	;Not applicable under Windows NT
security=
[lanroot]
lanroot=
[tapedrive1]
tapename=
[cdrom1]
cdromname=


Code Page Support
Appendix E	1 of 1

Code Page Support

The Upgrade Manager supports upgrading from English to another native language - for example, from an English language version of OS/2 to a French language version of Windows NT Server. It also supports upgrading to the same native language, such as Canadian French to Canadian French. You cannot upgrade from a non-English language to a different non-English language.

Note

Using Sytos Plus to back up data under one language version and Windows NT Backup to restore the data under another language version is not supported.

To detect a change from one language version to another, the Windows NT Upgrade Manager compares OS/2 code page information with the OEM code page under Windows NT Server. Code pages determine the character correspondence tables used to set up foreign language versions of software. For purposes of the upgrade, code pages indicate how a utility should transfer various extended characters that can appear in usernames, account descriptions, and so on.

If the code pages differ, the Upgrade Manager modifies the Upgrade Tool Schedule so that the command lines of various upgrade utilities include a /codepage option (for example, portuas /codepage:<OS/2 code page number>). The /codepage option is necessary only if changing languages is part of the upgrade.

The backenv utility determines LAN Manager code page information by:

Checking CONFIG.SYS.

Calling the DosGetCtryInfo( ) API.

Using the default code page for the current country code (from CONFIG.SYS).

If a code page is located, backenv writes the information to the LMBAKENV.DAT and ADVISORY.TXT files. If no code page is found, nothing is written.

Next, the Windows NT Server Upgrade Manager reads the code page from LMBAKENV.DAT. If it differs from the existing Windows NT Server code page, the Upgrade Manager edits the Express Upgrade Tool Schedule by appending a "/codepage:<code page number>" option to the command line for the following utilities: restenv, portuas, userconv, aclconv, sfmconv, and aclcomp. If no code page exists, the OEM code page is assumed to be valid.

Note that the Custom Upgrade Schedule always includes a /codepage:<code page number> option for restenv, portuas, userconv, aclconv, sfmconv, and aclcomp. Delete this option if you are not changing language versions.

If you are creating a Custom Upgrade Schedule and also changing language versions:

1.	Check the ADVISORY.TXT for OS/2 code page information.

2.	Specify this information for each utility you run under Windows NT Server. For example, if the code page is 863 (for Canadian French language support), the command line for restenv should be restenv /codepage:863, instead of restenv /codepage:###.

If you are changing language versions, these procedures also apply if you run restenv, portuas, userconv, aclconv, sfmconv, or aclcomp from the command line.


Editing Configuration Files
Appendix F	1 of 2

Editing Configuration Files

When you run Express or Custom Upgrade, the Upgrade Manager examines configuration files (WNTUPMGR.EXP for Express and WNTUPMGR.INI for Custom Upgrade) to determine available tools and command line options.

You can create your own Express or Custom Upgrade schedule by modifying these configuration files with a text editor such as Notepad.

Note

Prior to editing the files, make sure you understand their content and purpose, as described in the rest of this section.


The WNTUPMGR.EXP File
Editing Configuration Files	2 of 2

The WNTUPMGR.EXP File

WNTUPMGR.EXP tells the Upgrade Manager which tools are available and which files to look for to schedule upgrade tasks. After determining appropriate upgrade tasks, the Upgrade Manager creates a run file version of the upgrade schedule, which it stores in memory. If a reboot is scheduled after an Express Upgrade task, the Upgrade Manager saves the run version of the schedule (WNTUPMGR.RUN) to disk prior to rebooting and then deletes it after the system restarts.

Editing WNTUPMGR.EXP is only appropriate if you decide to add a new upgrade tool and want it included in the Express Upgrade schedule. If you use the same tools and command line options to perform all upgrades, create a custom configuration file using the Upgrade Manager or edit WNTUPMGR.INI.

To use a modified version of WNTUPMGR.EXP, you must overwrite the original file. If you edit the file, keep a copy of the original version under a different name.

WNTUPMGR.EXP is organized into sections, each of which corresponds to an upgrade utility. For example, the first section of WNTUPMGR.EXP starts the convert utility, the second starts the restenv utility, and so on. Each section contains nine predefined lines.

The following table explains the meaning of each section line.

Explanation of Lines in WNTUPMR.EXP

Line number		Example		Meaning
1		&Convert partition		Application description. Always preceded by "&".
2		Convert ?: partition to NTFS		Text description of command. "?" to be replaced based on scope specification (see line 7).
3		convert ?: /fs:ntfs		Command line. "?" to be replaced based on scope specification (see line 7).
4		aclbak?.acl		Specifies trigger file. If no trigger file, "none" is specified.
5		Converting this disk partition may require that you reboot the system for correct operation. You will be unable to undo the file system conversion once complete. Are you sure you want to do this?		Warning string. If no warning, "none" is specified.
6		pause		"pause" or "nopause" specified to indicate whether the Upgrade Manager should pause after execution.
7		drive		Specifies scope, which is either "drive" or "system." The command line is based on this parameter. If a command is run only once, its scope is "system." If a command is typically run more than once, it has a replaceable parameter (the ? in lines 2 and 3), which is a drive specification.
8		window		Specifies execution type. Can be "window" or "detached."
9		last		Specifies whether reboot should occur after utility has run. Can be "never," "always," or "last." "Last" directs program to reboot after the last invocation of a command.
WNTUPMGR.INI

Unless you specify the name of another file, the Upgrade Manager uses the WNTUPMGR.INI configuration file to create a Custom Upgrade schedule.

WNTUPMGR.INI is similar to WNTUPMGR.EXP except that it contains five-line sections which correspond to WNTUPMGR.EXP lines 1, 3, 6, 8, and 9 (see the earlier table "Explanation of Lines in WNTUPMGR.EXP"). Note that line 5 of each section of WNTUPMGR.INI can only be "reboot" or "noreboot."

Editing WNTUPMGR.INI is appropriate if you want to create a Custom Upgrade schedule using an ASCII text editor rather than the Upgrade Manager user interface. After editing the file, save it under a different name and then run it by typing wntupmgr <filename.ext> from the command line. Replace all variables (?) in the file with appropriate command syntax.

Following is a sample WNTUPMGR.INI file.

&Convert ?:  partition to NTFS

convert ?:  /fs:ntfspause

window

noreboot

&Restore environment

restenv

pause

window

noreboot

&Restore user accounts

portuas -v -f netacc.bkp

pause

system

window

noreboot

&Restore permissions for partition ?:

aclconv /data:aclbak?.acl /log:aclbak?.log

pause

console

noreboot

&Restore scheduled commands

cmd /c restat.cmd

pause

window

noreboot

&Convert Macintosh(tm) volumes

sfmconv /v /log:sfmconv.log /script:sfmconv.run

pause

ndow

noreboot

&Verify permissions for partition ?:

aclcomp /a /dat:acllist?.dat /log:aclcomp?.log

pause

window

noreboot