Migrating Novell Rights (trustees) to Microsoft Rights (acl)

I’m in the middle of a big migration project from Novell to Microsoft.
When it comes to transferring the security rights from then Novell File system, trustees, to the Microsoft File system, I decided to NOT use a Quest tool, but rather some freely available tools, and some smarts.
The first thing I did was to copy all the data from the Netware server to the Windows server. I won’t go into the details in this entry, but I’ll tell you I used “beyond compare” which has saved me many times…

The process goes like this:
1. Backup the Novell rights to a file.
2. Translate the rights into Microsoft ‘speak’
3. Apply the rights using a batch file.

So here we go….
1. I used the TRUSTEE.NLM tool (free from novell) to backup the rights. At the novell server, I typed the following:
TRUSTEE /ET /D SAVE VOL1: sys:\vol1-trustee.csv
This backed up all rights on volume vol1: to a file called vol1-trustee.csv, saved to the root of the sys volume.
The /ET switch backs up only trustee entries only, not ownership.
The /D switch backs up only directories, not files.

The output file looks like this (i’ll show only 2 lines)

2. To translate the rights I used Excel and notepad. I’ll show you the end result, then explain it.
SetACL.exe -on “E:\GROUPS\500STAFF” -ot file -actn ace -ace “n:swtc\500STAFF;p:change” -log “c:\temp\log.txt”
SetACL.exe -on “E:\GROUPS\500STAFF” -ot file -actn ace -ace “n:swtc\600STAFF;p:read”

Let’s look at one line of each. I color coded the stuff that’s the same in red, and the stuff to translate in blue.
SetACL.exe -on E:\GROUPS\500STAFF-ot file -actn ace -ace “n:swtc\500STAFF;p:change” -log “c:\temp\log.txt”

So from here
I replaced “TRUSTEE” with SetACL.exe -on
replace vol1: with E:
replace LONG with -ot file -actn ace -ace “n:swtc\
replace RWCEMF with ;p:change -log c:\temp\log.txt”
In places where there was only RF rights, I replaced them with ;p:read -log c:\temp\log.txt

I had to do some cleanup too, like removing the context of the group or user, in the example above, I replaced .Staff.SXYZ with nothing.

Then I saved it as csv file, used notepad to remove and unnecessary commas, and ran the batch file.
I used the SetACL.exe utility found here: setacl.sourceforge.net
This worked great!!!

For home folders, I did the same thing, and then i modified the batch file by replacing the -ot file -actn ace -ace to -ot file -actn setowner -ownr , this sets the owner of the home folder to the owner of the user. This allows me to turn on user quota’s if i want and get an accurate reporting.

When i am ready to perform the cutover, I rem out the Novell Login script, and turn ON the Microsoft logon script.


Migrating Printers made easy, Lesson #5

Moving printers from one server to another can be a long tedious process if you do it manually.

If you use Print Migrator 3.1, it’s easy. Download the file from the link, it’s the actual program. No install needed. Yep, it’s only 211k.

Step 1: image

Backup the current printers.

It dumps everything to a cab file you specify, i just called my printers.cab



Then it runs and runs and runs, scrolling files pass your eyes…..


Finally, you have a cab file.

In my case I had 12 printers, that made a 95 Meg file.


Then you copy that cab file and the print migration file from the source server (old) to the target server (new)


(i just put it all on the desktop for easy moving)

On the target server, you rerun the application, but choose restore. Pick the cab file you copied over, and fill in the field at the bottom of the box with the new server’s name. “\\newserver”

Then click open. It restores everything identical… it creates the necessary tcp/ip ports, drivers, names, shared name, everything….


This tool would be a good mechanism for disaster recovery of a server. I’m not sure if the system state restores all the printers and drivers this nicely. I don’t think it does.

So having this cab file backed up would be an ace in your pocket if you ever had to restore the server.

Moving the printers at the client side, Lesson #6


There is a vb script I found on the Internets, it’s very handy.

You run this against your users, upon logon, and you can run it multiple times (after the first time it doesn’t change anything). It looks in the registry on the workstation and finds the mapped printers, parses it, and changes the old name to the new name. It’s important when migrating printers to not change the name of the shared printer, otherwise this won’t work.  It’s a silent script, no popups.

I called my file pmigrate.vbs, and you can run it from group policy login script, or from a batch file with this line“cscript.exe \\domain.local\netlogon\pmigrate.vbs” Hint: Use the FQDN of active directory, and copy the vb script into the netlogon share.

I found other scripts, some that remove and reinstall printers, but that takes a long time. What is nice about this script is that it runs silent and it works flawlessly. After a while, a couple of day, you disable the running of it.

Option Explicit
Dim from_sv, to_sv, PrinterPath, PrinterName, DefaultPrinterName, DefaultPrinter
Dim DefaultPrinterServer, SetDefault, key
Dim spoint, Loop_Counter
Dim WshNet, WshShell
Dim WS_Printers
DefaultPrinterName = ""
spoint = 0
SetDefault = 0
set WshShell = CreateObject("WScript.shell")

from_sv = \\old ‘This should be the name of the old server.
to_sv = \\new ‘This should be the name of your new server.

‘Just incase their are no printers and therefore no default printer set
‘ this will prevent the script form erroring out.
On Error Resume Next
key = "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Device"
DefaultPrinter = LCase(WshShell.RegRead (key))
If Err.Number <> 0 Then
DefaultPrinterName = ""
‘If the registry read was successful then parse out the printer name so we can
‘ compare it with each printer later and reset the correct default printer
‘ if one of them matches this one read from the registry.
spoint = instr(3,DefaultPrinter,"\")+1
DefaultPrinterServer = left(DefaultPrinter,spoint-2)
if DefaultPrinterServer = from_sv then
DefaultPrinterName = mid(DefaultPrinter,spoint,len(DefaultPrinter)-spoint+1)
end if
end if
Set WshNet = CreateObject("WScript.Network")
Set WS_Printers = WshNet.EnumPrinterConnections
‘You have to step by 2 because only the even numbers will be the print queue’s
‘ server and share name. The odd numbers are the printer names.
For Loop_Counter = 0 To WS_Printers.Count – 1 Step 2
‘Remember the + 1 is to get the full path ie.. \\your_server\your_printer.
PrinterPath = lcase(WS_Printers(Loop_Counter + 1))
‘We only want to work with the network printers that are mapped to the original
‘ server, so we check for "\\Your_server".
if LEFT(PrinterPath,len(from_sv)) = from_sv then
‘Now we need to parse the PrinterPath to get rhe Printer Name.
spoint = instr(3,PrinterPath,"\")+1
PrinterName = mid(PrinterPath,spoint,len(PrinterPath)-spoint+1)
‘Now remove the old printer connection.
WshNet.RemovePrinterConnection from_sv+"\"+PrinterName
‘and then create the new connection.
WshNet.AddWindowsPrinterConnection to_sv+"\"+PrinterName
‘If this printer matches the default printer that we got from the registry then
‘ set it to be the default printer.
if DefaultPrinterName = PrinterName then
WshNet.SetDefaultPrinter to_sv+"\"+PrinterName
end if
end if
Set WS_Printers = Nothing
Set WshNet = Nothing
Set WshShell = Nothing

Migrating users to new Shared Folders, Lesson #4

It is important to understand that migrating the data and moving the users is broken down into three major steps:

1) Move the data initially, verify security rights moved over, test applications moved the new drive letter.
2) The night of cutover, perform a delta move. This means moving just the files that have changed or have been created on old production side. Beyond Compare is excellent for this (and many other things)
3) Change drive mappings (logon scripts) and remove the old shares. I insist on removing old shares so that users can’t get to the old data. You never ever want to find yourself with most users migrated, but some users still updating info on the old server.

In this lesson, we identify the logon scripts used by the end users, and change the drive mappings from the old server share to the new server share.

Some logon scripts are assigned on the user account. This is the old NT 4.0 way before group policy existed, and is seen on the Profile Tab of the user.


If the path is not specified, like in the above example, it implies the NETLOGON share on any domain controller. This entry is typically populated with a batch file (.bat)


To provide more flexibility, you can use group policy to assign logon scripts to users. In fact, you can assign logout scripts too, but it seems rare to be used. Group policy also allows you to assign “logon” scripts to computer ojbects. These are called Startup and Shutdown scripts, and as you probably guessed, they run on startup of the workstation before anyone logs on, and when the workstation shuts down.

This is where you should use the Group Policy Management utility to browse group policy objects and look for scripts that might be assigned. I have found that most people (admins) drop the scripts in the NETLOGON share and point to them in group policy.

The one thing nice about group policy is that it supports .vbs, .exe, and a wide range of other extensions.

For this client example, looking inside the default small business server logon script (SBS_LOGIN_SCRIPT.bat) reveals the following code:

cscript.exe \\activedirectorydomain.local\netlogon\logon.vbs

Interesting… in this case, the batch file runs a vb script.

Take note here that the unc path does not reference server but instead uses the active directory domain name. That way the client uses the current domain controller that it’s authenticating off of, not a specific one.

Inside the logon.vbs file we see this snipit of code:

    DriveMapper "H:","\\s1\home\" & fuser
    DriveMapper "P:","\\s1\GroupShare"

It should be obvious that you change the “s1” from the old server’s name to the new server’s  name. This is not the place to endulge in all the ways to map drives, and make logon scripts. We can cover that in another lesson.

The BIGGEST problem you are going to run into is PERSISTANT Drive mappings. A persistant drive mapping is one that is tied to the profile, when you map a drive and check the “Reconnect at logon” using explorer as seen here:



If the logon script was just a batch file that used the command: net use k: \\server\share, the user would get a popup saying something to the effect “Do you want to map to the new server, you have this drive mapped to the old server”. Most people say no to such changes, but that would be incorrect. Now the users is screwed, the old shares are removed, but the user said “no” to re-mapping the drive letters, so now the user has no drive mappings. Uggg..

If you modify the batch file and perform a net use k: /delete for each drive letter, then the user won’t get questions like that. Again, this problem only exists when users have persistent drive mappings.

Moving Shared Folders and Data, Lesson #3

Copy the data, copy the rights (shared and NTFS), change the scripts.
Sounds simple, and this part is, especially if you use the right tools.

I copied some of the files using the "Microsoft File Server Migration Wizard", google FSMigrate.msi, and you’ll find it. I’m using verions 1.0. It does exactly what you want. It replicates all the shares, their permissions, and ntfs file and folder permissions from one server to another. You run the program on the new server (the target server). The old server would be called the source server.


There are three other options.

1- Robocopy.exe, a ms utility that is command line based. It works ok, but its hard to tell what is going on.
2- Use BackupExec to backup and restore the files, it works nicely since you can specify an alternate location for files.
3- Use BeyondCompare to copy the files over. There is a setting you have to turn on to copy over NTFS permissions.



I forgot to turn on the "Copy NFTS file permissions" when I used BeyondCompare to copy all the files over…. So then I used robocopy.exe to copy over just the security rights.
robocopy /COPY:ATSOU

/COPY:copyflag[s] :: what to COPY (default is /COPY:DAT).
                     (copyflags : D=Data, A=Attributes, T=Timestamps).
                     (S=Security=NTFS ACLs, O=Owner info, U=aUditing info).

This copies everything BUT the data itself. I have to say from experience, it’s fast and it sets the rights correctly, but not the owner.

To be sure it is identical, even the owner of the file, I used Backup Exec to restore just the file trustees….It has this handy feature to restore only the permissions.


This image appears in the restore options. I have to say, it’s pretty slow to restore all the security info, almost as slow as restoring the actual files too.


In summary, Beyond Compare is the fastest, and if you turn on the NTFS permissions to copy, well, even the owner comes across fine.
Backup / restore is a slow method.
Robocopy is not gui, so it’s hard to tell what you have and how far you are along in copying.

The MS File Server Migration wizard is cool, but it doesn’t like to be interrupted, and if the target server already has the folder and files (from using robocopy or beyond compare), it errors out and fails.

Next time? I think I will use the MS File Server Migration wizard for the first major copy, then use Beyond Compare for the delta, just before I cut over. Beyond Compare is really good for delta copy. The wizard even sets up the shares for you and sets identical share permissions… how cool is that?

Upgrading to new servers, Lesson #1

Our client is using SBS 2003, single server.
It’s the domain controller, exchange server, file share, and print server.

We are upgrading them to two new server.
First a new domain controller / file share / print share server
Second, a new Exchange 2007 server.

The existing server is Windows 2003 with sp2, with Exchange 2003 with sp2.
The new servers are Windows 2003 R2 with sp2 and Exchange 2007 sp1.

Key Points of this project are:

1) Migration of shared resources (shares and printers) will occur from one server to another
2) Workstations will need these resources seamlessly moved over (drive mappings and printers) to the new server.
3) A second domain controller will be added and the original removed.
4) Exchange mailboxes will be moved to a new server.
5) Exchange 2007 is installed and 2003 removed.

It’s important to know the project gant chart. What parts are dependent on other, and what can be done during the day and what must be done at off hours.

We will use automation whenever possible. So Let’s begin.