1 <?xml version="1.0" encoding="iso-8859-1"?>
2 <!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
4 <chapter id="NetCommand">
9 <pubdate>May 9, 2005</pubdate>
12 <title>Remote and Local Management &smbmdash; The Net Command</title>
15 The <command>net</command> command is one of the new features of Samba-3 and is an attempt to provide a useful
16 tool into which the majority of remote management operations necessary for common tasks. The
17 <command>net</command> tool is flexible by design and is intended for command line use as well as for scripted
22 Originally introduced with the intent to mimick the Microsoft Windows command that has the same name, the
23 <command>net</command> command has morphed into a very powerful instrument that has become an essential part
24 of the Samba network administrator's toolbox. The Samba Team have introduced tools, such as
25 <command>smbgroupedit, rpcclient</command> from which really useful have been integrated into the
26 <command>net</command>. The <command>smbgroupedit</command> command was absorbed entirely into the
27 <command>net</command>, while only some features of the <command>rpcclient</command> command have been
28 ported to it. Anyone who finds older references to these utilities and to the functionality they provided
29 should look at the <command>net</command> command before searching elsewhere.
33 A Samba-3 administrator can not afford to gloss over this chapter because to do so will almost certainly cause
34 the infliction of self induced pain, agony and desperation. Be warned, this is an important chapter.
38 <title>Overview</title>
41 The tasks that follow the installation of a Samba-3 server, whether Stand-Alone, Domain Member, of a
42 Domain Controller (PDC or BDC) begins with the need to create administrative rights. Of course, the
43 creation of user and group accounts is essential for both a Stand-Alone server as well as for a PDC.
44 In the case of a BDC or a Domain Member server (DMS) Domain user and group accounts are obtained from
45 the central domain authentication backend.
49 Regardless of the type of server being installed, local UNIX groups must be mapped to the Windows
50 networking domain global group accounts. Do you ask, why? Because Samba always limits its access to
51 the resources of the host server by way of traditional UNIX UID/GID controls. This means that local
52 groups must be mapped to domain global groups so that domain users who are members of the domain
53 global groups can be given access rights based on UIDs and GIDs local to the server that is hosting
54 Samba. Such mappings are implemented using the <command>net</command> command.
58 UNIX systems that are hosting a Samba-3 server that is running as a member (PDC, BDC, or DMS) must have
59 a machine security account in the domain authentication database (or directory). The creation of such
60 security (or trust) accounts is also handled using the <command>net</command> command.
64 The establishment of interdomain trusts is achieved using the <command>net</command> command also, as
65 may a plethora of typical administrative duties such as: user management, group management, share and
66 printer management, file and printer migration, security identifier management, and so on.
70 The over-all picture should be clear now, the <command>net</command> command plays a central role
71 on the Samba-3 stage. This role will continue to be developed. The inclusion of this chapter is
72 evidence of its importance, one that has grown in complexity to the point that it is no longer considered
73 prudent to cover its use fully in the on-line UNIX man pages.
79 <title>Administrative Tasks And Methods</title>
82 The basic operations of the <command>net</command> command are documented here. This documentation is not
83 exhaustive, and thus it is incomplete. Since the primary focus is on migration from Windows servers to
84 a Samba server the emphasis is on the use of the DCE RPC mode of operation. When used against a server
85 that is a member of an Active Directory domain it is preferable (and often necessary) to use ADS mode
86 operations. The <command>net</command> command supports both, but not for every operation. Please refer
87 to the man page for a more comprehensive overview of the capabilities of this utility.
93 <title>UNIX and Windows Group Management</title>
96 In repetition of what has been said, the focus in most of this chapter is on use of the <command>net
97 rpc</command> family of operations that are supported by Samba. Most of them are supported by the
98 <command>net ads</command> mode when used in connection with MS Active Directory. The <command>net
99 rap</command> operating mode is also supported for some of these operations. RAP protocols are used
100 by IBM OS/2 and by several earlier SMB servers.
104 Sambas' <command>net</command> tool implements sufficient capability to permit all common adminstrative
105 tasks to be completed from the command line. In this section each of the essential user and group management
106 facilities are explored.
110 Samba-3 recognizes two types of groups: <emphasis>domain groups</emphasis> and <emphasis>local
111 groups</emphasis>. Domain groups can contain (have as members) only domain user accounts. Local groups
112 can contain local users, domain users, and domain groups as members.
116 The purpose of a local group is to permit file permission to be set for a group account that, like the
117 usual UNIX/Linux group, is persistent across redeployment of a Windows file server.
121 <title>Adding, Renaming, or Deletion of Group Accounts</title>
124 <title>Adding or Creating a New Group</title>
127 Before attempting to add a Windows group account the currently available groups can be listed as shown
130 &rootprompt; net rpc group list -Uroot%not24get
141 A Windows group account called <quote>SupportEngrs</quote> can be added by executing the following
144 &rootprompt; net rpc group add "SupportEngrs" -Uroot%not24get
146 The addition will result in immediate availability of the new group account as validated by executing the
149 &rootprompt; net rpc group list -Uroot%not24get
164 The following demonstrates that the POSIX (UNIX/Linux system account) group has been created by calling
165 the <smbconfoption name="add group script">/opt/IDEALX/sbin/smbldap-groupadd -p "%g"</smbconfoption> interface
168 &rootprompt; getent group
170 Domain Admins:x:512:root
171 Domain Users:x:513:jht,lct,ajt,met
173 Print Operators:x:550:
174 Backup Operators:x:551:
176 Domain Computers:x:553:
180 The following demonstrates that the use of the <command>net</command> command to add a group account
181 results in immediate mapping of the POSIX group that has been created to the Windows group account as whown
184 merlin:~ # net groupmap list
185 Domain Admins (S-1-5-21-72630-4128915-11681869-512) -> Domain Admins
186 Domain Users (S-1-5-21-72630-4128915-11681869-513) -> Domain Users
187 Domain Guests (S-1-5-21-72630-4128915-11681869-514) -> Domain Guests
188 Print Operators (S-1-5-21-72630-4128915-11681869-550) -> Print Operators
189 Backup Operators (S-1-5-21-72630-4128915-11681869-551) -> Backup Operators
190 Replicator (S-1-5-21-72630-4128915-11681869-552) -> Replicator
191 Domain Computers (S-1-5-21-72630-4128915-11681869-553) -> Domain Computers
192 Engineers (S-1-5-21-72630-4128915-11681869-3005) -> Engineers
193 SupportEngrs (S-1-5-21-72630-4128915-11681869-3007) -> SupportEngrs
200 <title>Mapping Windows Groups to UNIX Groups</title>
203 Windows groups must be mapped to UNIX system (POSIX) groups so that file system access controls
204 can be asserted in a manner that is consistent with the methods appropriate to the operating
205 system that is hosting the Samba server.
209 All file system (file and directory) access controls, within the file system of a UNIX/Linux server that is
210 hosting a Samba server, is implemented using a UID/GID identity tuple. Samba does not in any way over-ride
211 or replace UNIX file system semantics. Thus it is necessary that all Windows networking operations that
212 access the file system must provide a mechanism that maps a Windows user to a particular UNIX/Linux group
213 account. The user account must also map to a locally known UID.
217 Samba depends on default mappings for the <constant>Domain Admins, Domain Users</constant> and
218 <constant>Domain Guests</constant> global groups. Additional groups may be added as shown in the
219 examples just given. There are times when it is necessary to map an existing UNIX group account
220 to a Windows group. This operation, in effect, creates a Windows group account as a consequence
221 of creation of the mapping.
225 The operations that are permitted includes: <constant>add, modify, delete</constant>. An example
226 of each operation is shown here.
230 An existing UNIX group may be mapped to an existing Windows group by this example:
232 &rootprompt; net groupmap modify ntgroup="Domain Users" unixgroup=users
234 An existing UNIX group may be mapped to a new Windows group as shown here:
236 &rootprompt; net groupmap add ntgroup="EliteEngrs" unixgroup=Engineers type=d
238 A Windows group may be deleted, and then a new Windows group can be mapped to the UNIX group by
239 executing these commands:
241 &rootprompt; net groupmap delete ntgroup=Engineers
242 &rootprompt; net groupmap add ntgroup=EngineDrivers unixgroup=Engineers type=d
247 Two types of Windows groups can be created: <constant>domain (global),</constant> and <constant>local</constant>.
248 In the above examples the Windows groups created were of type <constant>domain</constant>, or global. The
249 following command will create a Windows group of type <constant>local</constant>.
251 &rootprompt; net groupmap add ntgroup=Pixies unixgroup=pixies type=l
253 Local groups can be used with Samba to enable multiple nested group support.
259 <title>Deleting a Group Account</title>
262 A group account may be deleted by executing the following command:
264 &rootprompt; net rpc group delete SupportEngineers -Uroot%not24get
269 Validation of the deletion is advisable. The same commands may be executed as shown above.
275 <title>Rename Group Accounts</title>
278 This command is not documented in the man pages, it is implemented in the source code, but it does not
279 work. The example given documents (from the source code) how it should work. Watch the release notes
280 of a future release to see when this may have been be fixed.
284 Sometimes it is necessary to rename a group account. Good administrators know how painful some managers
285 demands can be if this simple request is ignored. The following command demonstrates how the Windows group
286 <quote>SupportEngrs</quote> can be renamed to <quote>CustomerSupport</quote>:
288 &rootprompt; net rpc group rename SupportEngrs \
289 CustomerSupport -Uroot%not24get
298 <title>Manipulating Group Memberships</title>
301 Three operations can be performed in respect of group membership. It is possible to (1) add Windows users
302 to Windows group, to (2) delete Windows users from Windows groups, and to (3) list the Windows users that are
303 members of a Windows group.
307 So as to avoid confusion, it makes sense to check group membership before attempting to make and changes.
308 The <command>getent group</command> will list UNIX/Linux group membership. UNIX/Linux group members are
309 seen also as members of a Windows group that has been mapped using the <command>net groupmap</command>
310 command (see <link linkend="groupmapping"/>). The following list of UNIX/Linux group membership shows
311 that the user <constant>ajt</constant> is a member of the UNIX/Linux group <constant>Engineers</constant>.
313 &rootprompt; getent group
315 Domain Admins:x:512:root
316 Domain Users:x:513:jht,lct,ajt,met,vlendecke
318 Print Operators:x:550:
319 Backup Operators:x:551:
321 Domain Computers:x:553:
322 Engineers:x:1000:jht,ajt
324 The UNIX/Linux groups have been mapped to Windows groups, as is shown here:
326 &rootprompt; net groupmap list
327 Domain Admins (S-1-5-21-72630-412605-116429-512) -> Domain Admins
328 Domain Users (S-1-5-21-72630-412605-116429-513) -> Domain Users
329 Domain Guests (S-1-5-21-72630-412605-116429-514) -> Domain Guests
330 Print Operators (S-1-5-21-72630-412605-116429-550) -> Print Operators
331 Backup Operators (S-1-5-21-72630-412605-116429-551) -> Backup Operators
332 Replicator (S-1-5-21-72630-412605-116429-552) -> Replicator
333 Domain Computers (S-1-5-21-72630-412605-116429-553) -> Domain Computers
334 Engineers (S-1-5-21-72630-412605-116429-3001) -> Engineers
339 Given that the user <constant>ajt</constant> is already a member of the UNIX/Linux group, and via the
340 group mapping, a member of the Windows group, an attempt to add this account again should fail. This is
343 merlin:~ # net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24get
344 Could not add ajt to MIDEARTH\Engineers: NT_STATUS_MEMBER_IN_GROUP
346 This showns that the group mapping between UNIX/Linux groups and Windows groups is effective and
351 To permit the user <constant>ajt</constant> to be added using the <command>net rpc group</command> utility
352 this account must first be removed. The removal, and confirmation of its effect is shown here:
354 &rootprompt; net rpc group delmem "MIDEARTH\Engineers" ajt -Uroot%not24get
355 &rootprompt; getent group Engineers
357 &rootprompt; net rpc group members Engineers -Uroot%not24get
360 In this example both at the UNIX/Linux system level, the group no longer has the <constant>ajt</constant>
361 as a member. The above also shows this to be the case for Windows group membership.
365 The account is now added again, using the <command>net rpc group</command> utility:
367 &rootprompt; net rpc group addmem "MIDEARTH\Engineers" ajt -Uroot%not24get
368 &rootprompt; getent group Engineers
369 Engineers:x:1000:jht,ajt
370 &rootprompt; net rpc group members Engineers -Uroot%not24get
377 In this example the members of the Windows <constant>Domain Users</constant> account is validated using
378 the <command>net rpc group</command> utility. Note that this contents of the UNIX/Linux group was shown
379 4 paragraphs earlier. The Windows (domain) group membership is shown here:
381 &rootprompt; net rpc group members "Domain Users" -Uroot%not24get
388 The example shown here is an express example that Windows group names are treated by Samba (as with
389 MS Windows) in a case insensitive manner:
391 &rootprompt; net rpc group members "DomAiN USerS" -Uroot%not24get
401 An attempt to specify the group name as <constant>MIDEARTH\Domain Users</constant> in place of
402 just simply <constant>Domain Users</constant> will fail. The default behavior of the net rpc group
403 is to direct the command at the local machine. The Windows group is treated as being local to the machine.
404 If it is necessary to query another machine, its name can be specified using the <constant>-S
405 servername</constant> parameter to the <command>net</command> command.
411 <title>Nested Group Support</title>
414 It is possible in Windows (and now in Samba also) to great a local group that has members (contains)
415 domain users and domain global groups. Creation of the local group <constant>demo</constant> is
416 achieved by executing:
418 &rootprompt; net rpc group add demo -L -Uroot%not24get
420 The -L switch means create a local group. Use the -S argument to direct the operation to a particular
421 server. The parameters to the -U argument should be for a user who has appropriate administrative right
422 and privileges on the machine.
426 Addition and removal of group members can be achieved using the <constant>addmem</constant> and
427 <constant>delmem</constant> subcommands of <command>net rpc group</command> command. For example,
428 addition of <quote>DOM\Domain Users</quote> to the local group <constant>demo</constant> would be
431 &rootprompt; net rpc group addmem demo "DOM\Domain Users" -Uroot%not24get
436 The members of a nested group can be listed by executing the following:
438 &rootprompt; net rpc group members demo -Uroot%not24get
447 Nested group members can be removed (deleted) as shown here:
449 &rootprompt; net rpc group delmem demo "DOM\jht" -Uroot%not24get
458 <title>UNIX and Windows User Management</title>
461 Every Windows network user account must be translated to a UNIX/Linux user account. In actual fact,
462 the only account information the UNIX/Linux Samba server needs is a UID. The UID is available either
463 from a system (POSIX) account, or from a pool (range) of UID numbers that is set aside for the purpose
464 of being allocated for use by Windows user accounts. In the case of the UID pool, the UID for a
465 particular user will be allocated by <command>windbindd</command>.
469 Although this is not the appropriate place to discuss the <smbconfoption name="username map"/> facility,
470 this interface is an important method of mapping a Windows user account to a UNIX account that has a
471 different name. Refer to the man page for the &smb.conf; file for more information regarding this
472 facility. User name mappings can not be managed usinf the <command>net<command> utility.
476 <title>Adding User Accounts</title>
484 <title>Deletion of User Accounts</title>
492 <title>Modification of User Accounts</title>
500 <title>User Mapping</title>
510 <title>Administering User Rights and Privileges</title>
514 &rootprompt; net rpc rights list accounts -U root%not24get
515 BUILTIN\Print Operators
516 No privileges assigned
518 BUILTIN\Account Operators
519 No privileges assigned
521 BUILTIN\Backup Operators
522 No privileges assigned
524 BUILTIN\Server Operators
525 No privileges assigned
527 BUILTIN\Administrators
528 No privileges assigned
531 No privileges assigned
533 &rootprompt; net rpc rights list -U root%not24get
534 SeMachineAccountPrivilege Add machines to domain
535 SePrintOperatorPrivilege Manage printers
536 SeAddUsersPrivilege Add users and groups to the domain
537 SeRemoteShutdownPrivilege Force shutdown from a remote system
538 SeDiskOperatorPrivilege Manage disk shares
540 &rootprompt; net rpc rights grant "MIDEARTH\Domain Admins" \
541 SeMachineAccountPrivilege SePrintOperatorPrivilege \
542 SeAddUsersPrivilege SeRemoteShutdownPrivilege \
543 SeDiskOperatorPrivilege -U root%not24get
544 Successfully granted rights.
546 &rootprompt; net rpc rights grant "MIDEARTH\jht" \
547 SeMachineAccountPrivilege SePrintOperatorPrivilege \
548 SeAddUsersPrivilege SeDiskOperatorPrivilege \
550 Successfully granted rights.
552 &rootprompt; net rpc rights list accounts -U root%not24get
554 SeMachineAccountPrivilege
555 SePrintOperatorPrivilege
557 SeDiskOperatorPrivilege
559 BUILTIN\Print Operators
560 No privileges assigned
562 BUILTIN\Account Operators
563 No privileges assigned
565 BUILTIN\Backup Operators
566 No privileges assigned
568 BUILTIN\Server Operators
569 No privileges assigned
571 BUILTIN\Administrators
572 No privileges assigned
575 No privileges assigned
577 MIDEARTH\Domain Admins
578 SeMachineAccountPrivilege
579 SePrintOperatorPrivilege
581 SeRemoteShutdownPrivilege
582 SeDiskOperatorPrivilege
589 <title>Managing Trust Relationships</title>
592 Document how to set up trusts here!!!!!!!!!!!
596 <title>Machine Trust Accounts</title>
600 &rootprompt; net rpc testjoin
601 Join to 'MIDEARTH' is OK
608 <title>Inter-Domain Trusts</title>
611 Document how to set up trusts here!!!!!!!!!!!
619 <title>Managing Security Identifiers (SIDS)</title>
622 Document how to set up trusts here!!!!!!!!!!!
628 <title>Share Management</title>
631 Document how to set up trusts here!!!!!!!!!!!
635 <title>Creating, Editing, and Removing Shares</title>
638 A share can be added using the <command>net rpc share</command> command capabilities.
639 The target machine may be local or remote and is specified by the -S option. It must be noted
640 that the addition and deletion of shares using this tool depends on the availability of a suitable
641 interface script. The interface scripts Samba's <command>smbd</command> uses are called:
642 <smbconfoption name="add share script"/> and <smbconfoption name="delete share script"/>.
643 A set of example scripts are provided in the Samba source code tarball in the directory
644 <filename>~samba/examples/scripts</filename>.
648 The following steps demonstrate the use of the share management capabilities of the <command>net</command>
649 utility. In the first step a share called <constant>Bulge</constant> is added. The share-point within the
650 file system is the directory <filename>/data</filename>. The command that can be executed to perform the
651 addition of this share is shown here:
653 &rootprompt; net rpc share add Bulge=/data -S merlin -Uroot%not24get
655 Validation is an important process, and by executing the command <command>net rpc share</command>
656 with no other operators a listing of available shares is shown here:
658 &rootprompt; net rpc share -S merlin -Uroot%not24get
661 Bulge <--- This one was added
672 Often times it is desirable also to permit a share to be removed using a command-line tool.
673 The following step permits the share that was previously added to be removed:
675 &rootprompt; net rpc share delete Bulge -S merlin -Uroot%not24get
677 A simple validation shown here demonstrates that the share has been removed:
679 &rootprompt; net rpc share -S merlin -Uroot%not24get
694 <title>Creating and Changing Share ACLs</title>
702 <title>Share, Directory and File Migration</title>
705 Shares and files can be migrated in the same manner as user, machine and group accounts.
706 It is possible to preserve access control settings (ACLs) as well as security settings
707 throughout the migration process. The <command>net rpc vampire</command> facility is used
708 to migrate accounts from a Windows NT4 (or later) domain to a Samba server. This process
709 preserves passwords and account security settings and is a precursor to the migration
714 The <command>net rpc share</command> command may be used to migrate shares, directories
715 files, printers, and all relevant data from a Windows server to a Samba server.
719 A set of command-line switches permit the creation of almost direct clones of Windows file
720 servers. For example, when migrating a file-server, file ACLs and DOS file attributes from
721 the Windows server can be included in the migration process and will reappear, almost identicaly
722 on the Samba server when the migration has been completed.
726 The migration process can be completed only with the Samba server already being fully operational.
727 This means that the user and group accounts must be migrated before attempting to migrate data
728 share, files, and printers. The migration of files and printer configurations involves the use
729 of both SMB and MS DCE RPC services. The benefit of the manner in which the migration process has
730 been implemented, the possibility now exists to use a Samba server as a man-in-middle migration
731 service that affects a transfer of data from one server to another. For example, if the Samba
732 server is called MESSER, the source Windows NT4 server is called PEPPY, and the target Samba
733 server is called GONZALES, the machien MESSER can be used to affect the migration of all data
734 (files and shares) from PEPPY to GONZALES. If the target machine is not specified, the local
735 server is assumed by default.
739 The success of server migration requires a firm understanding of the structure of ther source
740 server (or domain) as well as the processes on which the migration is critically dependant.
744 There are two known limitations to the migration process:
749 The <command>net</command> command requires that the user credentials provided exist both
750 on the migration source and the migration target.
754 Printer settings may not be fully or incorrectly migrated. This might in particular happen
755 when migrating a Windows 2003 print server to Samba.
760 <title>Share Migration</title>
763 The <command>net rpc share migrate</command> command operation permits the migration of plain
764 share stanzas. A stanza contains the parameters within which a file or print share are defined.
765 The use of this migration method will create share stanzas that have as parameters the file
766 system directory path, an optional description, and simple security settings that permit write
767 access to files. One of the first steps necessary following migration is to review the share
768 stanzas to ensure that the settings are suitable for use.
772 The shares are created on-the-fly as part of the migration process. The <command>smbd</command>
773 application does this by calling on the operating system to execute the script specified by the
774 &smb.conf; parameter <parameter>add share command</parameter>.
778 There is a suitable example script for the <parameter>add share command</parameter> in the
779 <filename>$SAMBA_SOURCES/examples/scripts</filename> directory. It should be noted that
780 the account that is used to drive the migration must, of necessity, have appropriate file system
781 access privileges and have the right to create shares and to set ACLs on them. Such rights are
782 conferred by these rights: <parameter>SeAddUsersPrivilege, SeDiskOperatorPrivilege</parameter>.
783 For more information regarding rights and privileges please refer to <link linkend="rights"/>.
787 The syntax of the share migration command is shown here:
789 net rpc share MIGRATE SHARES <sharename> -S <source>
790 [--destination=localhost] [--exclude=share1,share2] [-v]
792 When the parameter <sharename> is ommited, all shares will be migrated. The potentially
793 large list of available shares on the system that is being migrated can be limited using the
794 <parameter>--exclude</parameter> switch. For example:
796 &rootprompt; net rpc share migrate shares myshare\
797 -S win2k -U administrator%secret"
799 This will migrate the share <constant>myshare</constant> from the server <constant>win2k</constant>
800 to the Samba Server using the permissions that are tied to the account <constant>administrator</constant>
801 with the password <constant>secret</constant>. The account that is used must be the same on both the
802 migration source server, as well as on the target Samba server. The use of the <command>net rpc
803 vampire</command>, prior to attempting the migration of shares, will ensure that accounts will be
804 identical on both systems. One precaution worth taking before commencement of migration of shares is
805 to validate that the migrated accounts (on the Samba server) have the needed rights and privileges.
806 This can be done as shown here:
808 &rootprompt; net rpc right list accounts -Uroot%not24get
810 The steps taken so far performs only the migration of shares. Directories and directory contents
811 are not migrated by the steps covered up to this point.
817 <title>File and Directory Migration</title>
820 Everything covered to this point has been done in preparation for the migration of file and directory
821 data. For many people preparation is potentially boring and the real excitement only begins when file
822 data can be used. The next steps demonstrates the techniques that can be used to transfer (migrate)
823 data files using the <command>net</command> command.
827 Transfer of files from one server to another has always been a challenge for Microsoft Windows
828 administrators because Windows NT and 200X servers do not include the tools needed. The
829 <command>xcopy</command> is not capable of preserving file and directory ACLs. Microsoft do provide a
830 utility that can copy ACLs (security settings) called <command>scopy</command>, but it is provided only
831 as part of the Windows NT or 200X Server Resource Kit.
835 There are several tools, both commercial and freeware, that can be used from Windows server to copy files
836 and directories with full preservation of security settings. One of the best known of the free tools is
837 called <command>robocopy</command>.
841 The <command>net</command> utility can be used to copy files and directories with full preservation of
842 ACLs as well as DOS file attributes. Note that including ACLs makes sense only where the destination
843 system will operate within the same security context as the source system. This applies to both a domain
844 member server (DMS) as well as for domain controllers (DCs) that result from a vampired domain.
845 Before file and directory migration all shares must already exist.
849 The syntax for the migration commands is shown here:
851 net rpc share MIGRATE FILES <sharename> -S <source>
852 [--destination=localhost] [--exclude=share1,share2]
853 [--acls] [--attrs] [--timestamps] [-v]
855 If the <sharename> parameter is ommited, all shares will be migrated. The potentially large
856 list of shares on the source system can be restricted using the <parameter>--exclude</parameter> command
861 Where it is necessary to preserve all file ACLs, the <parameter>--acls</parameter> switch should be added
862 to the above command line. Original file time stamps can be preserved by specifying the
863 <parameter>--timestamps</parameter> switch, and the DOS file attributs (i.e.: hidden, archive, etc.) cab
864 be preserved by specifying the <parameter>--attrs</parameter> switch.
868 The ability to preserve ACLs depends on appropriate support for ACLs, as well as the general file system
869 semantics of the host operating system on the target server. A migration from one Windows file server to
870 another will perfectly preserve all file attributes. Because of the difficulty of mapping Windows ACLs
871 onto a POSIX ACLs supporting system, there can be no perfect migration of Windows ACLs to a Samba server.
875 The ACLs that result on a Samba server will most probably not match the originating ACLs. Windows support
876 the possibility of files that are owned only by a group. Group-alone file ownership is not possible under
877 UNIX/Linux. Errors in migrating group-owned files can be avoided by using the &smb.conf; file
878 <smbconfoption name="force unknown acl user">yes</smbconfoption> parameter. This facility will
879 automatically convert group-owned files into correctly user-owned files on the Samba server.
883 An example for migration of files from a machine called <constant>nt4box</constant> to the Samba server
884 from which the process will be handled is shown here:
886 &rootprompt; net rpc share migrate files -S nt4box --acls \
887 --attrs -U administrator%secret
892 The above command will migrate all files and directories from all file shares on the Windows server called
893 <constant>nt4box</constant> to the Samba server from which migration is initiated. Files that are group-owned
894 will be owned by the user account <constant>administrator</constant>.
900 <title>Simultaneous Share and File Migration</title>
903 This operating mode shown here is just a combination of the two above. It first migrates
904 share-definitions and then all shared files and directories afterwards:
906 net rpc share MIGRATE ALL <sharename> -S <source>
907 [--exclude=share1, share2] [--acls] [--attrs] [--timestamps] [-v]
912 An example of simultaneous migration is shown here:
914 &rootprompt; net rpc share migrate all -S w2k3server -U administrator%secret
916 This will generate a complete server clone of the <parameter>w2k3server</parameter> server.
924 <title>Printer Migration</title>
927 The installation of a new server, as with the migration to a new network environment, often has similarity
928 to the building of a house; progress is very rapid from the laying of foundations up to the stage at which
929 the the house can be locked-up, but the finishing off appears to take longer and longer as building
930 approaches completion.
934 Printing needs vary greatly depending on the network environment, and may be very simple or complex. If
935 the need is very simple the best solution to the implementation of printing support may well be to
936 re-install everything from a clean slate instead of migrating older configurations. On the other hand,
937 a complex network that is integrated with many international offices and a multiplexity of local branch
938 offices, each of which form an inter-twined maze of printing possibilities, the ability to migrate all
939 printer configurations is decidedly beneficial. To manually re-establish a complex printing network
940 will take much time and frustration. Often-times it will not be possible to find driver files that are
941 currently in use thus necessitating the installation of newer drivers. Newer drivers often implement
942 printing features that will necessitate a change in the printer usage. Additionally, with very complex
943 printer configurations it becomes almost impossible to re-create the same environment - not matter
944 how extensivly it has been documented.
948 The migration of an existing printing architecture involves the following:
952 <listitem><para>Establishment of print queues.</para></listitem>
954 <listitem><para>Installation of printer drivers (both for the print server and for Windows clients.</para></listitem>
956 <listitem><para>Configuration of printing forms.</para></listitem>
958 <listitem><para>Implementation of security settings.</para></listitem>
960 <listitem><para>Configuration of printer settings.</para></listitem>
964 The Samba <command>net</command> utility permits printer migration from one Windows print server
965 to another. When this tool is used to migrate printers to a Samba server <command>smbd</command>,
966 the application the receives the network requests to create the necessary services, must call-out
967 to the operating system in order to create the underlying printers. The call-out is implemented
968 by way of an interface script that can be specified by the &smb.conf; file parameter
969 <smbconfoption id="add printer script"/>. This script is essential to the migration process.
970 A suitable example script may be obtained from the <filename>$SAMBA_SOURCES/examples/scripts</filename>
971 directory. Take note that this script must be customized to suit the operating system environment
972 and may use its tools to create a print queue.
976 Each of the components listed above can be completed separately, or they can be completed as part of an
977 automated operation. Many network administrators prefer to deal with migration issues in a manner that
978 gives them the most control, particularly when things go wrong. The syntax for each operation will now
979 be briefly described.
983 Printer migration from a Windows print server (NT4 or 200X) is shown. This instruction causes the
984 printer share to be created together with the underlying print queue:
986 net rpc printer MIGRATE PRINTERS [printer] [misc. options] [targets]
988 Printer drivers can be migrated from the Windows print server to the Samba server using this
989 command line instruction:
991 net rpc printer MIGRATE DRIVERS [printer] [misc. options] [targets]
993 Printer forms can be migrated with the following operation:
995 net rpc printer MIGRATE FORMS [printer] [misc. options] [targets]
997 Printer security settings (ACLs) can be migrated from the Windows server to the Samba server using this command:
999 net rpc printer MIGRATE SECURITY [printer] [misc. options] [targets]
1001 Printer configuration settings include factors such as paper size, default paper orientation, etc.
1002 These can be migrated from the Windows print server to the Samba server with this command:
1004 net rpc printer MIGRATE SETTINGS [printer] [misc. options] [targets]
1009 Migration of printers including all the above mentioned sets of information may be completed
1010 with a single command using this syntax:
1012 net rpc printer MIGRATE ALL [printer] [misc. options] [targets]
1021 <title>Controlling Open Files</title>
1024 Document how to set up trusts here!!!!!!!!!!!
1030 <title>Session and Connection Management</title>
1033 Document how to set up trusts here!!!!!!!!!!!
1039 <title>Printers and ADS</title>
1042 Document how to set up trusts here!!!!!!!!!!!
1048 <title>Manipulating the Samba Cache</title>
1051 Document how to set up trusts here!!!!!!!!!!!
1057 <title>Other Miscellaneous Operations</title>
1061 &rootprompt; net rpc info
1062 Domain Name: MIDEARTH
1063 Domain SID: S-1-5-21-726309263-4128913605-1168186429
1064 Sequence number: 1115878548
1066 Num domain groups: 8