Assigning Netware rights via the command line


Here at the office we have a group in charge of assigning and maintain user and group rights and permissions to our various systems.  It’s nice not having to worry about that aspect of server administration. 

But I have an urgent need to have some eDirectoy group rights assigned to a specific directory on every Netware server in our Enterprise.  The group that controls user access is saying that they can’t meet my timeframe for getting these rights assigned, so I had to come up with my own solution.

My solution was to use Wolfgang Schreiber’s  lrights.exe utility to script assigning the rights command line style.  The syntax is:

LRights <path> <rights> /name=<trustee>

For example, to assign read and file scan rights to the .mygroup.OU.O user:

lrights \\server\volume\directory R F /Name=.mygroup.OU.O

This utility was written to support long path/file names, unlike Novell’s rights.exe utility.

Troubleshooting Exchange 2007 ESE Event 491


My Exchange 2007 SP1 server started reporting Event 491 in the Application Log.

Source: ESE Event ID: 491

edgetransport (3488) Transport Mail Database: An attempt to determine the minimum I/O block size for the volume “D:\” containing “D:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\” failed with system error 5 (0x00000005): “Access is denied. “. The operation will fail with error -1032 (0xfffffbf8).

The Microsoft Exchange Transport service was not automatically starting as well. A few posts I found mentioned excluding the Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue directory from anti-virus scanning. I played around with all sorts of exceptions, but that didn’t resolve my problem. I even disabled the real-time A-V scanner and rebooted the server, but the problems persisted.

After hours of searching I came across this post, which pointed at permissions as the root of the problem. I had removed the default permissions on the Exchange installation drive, and Network Service was missing on the list of permissions. I tried to assign the fewest permissions as possible, but in the end here is what I assigned.

  • NETWORK SERVICE has all rights *except* Full Control and Modify on the TransportRoles folder, and inheritance is turned on. This full path is D:\Program Files\Microsoft\Exchange Server\TransportRoles\ on my server, yours may vary.
  • NETWORK SERVICE has Full Control on the D:\Program Files\Microsoft\Exchange Server\TransportRoles\data\ folder, and inheritance is turned on.
  • NETWORK SERVICE has Read & Execute, List Folder Contents, and Read on the D:\Program Files\Microsoft\Exchange Server\ folder.
  • NETWORK SERVICE has Read & Execute, List Folder Contents, and Read on the root installation folder, which is D:\ for me. I did everything I could to avoid this, but couldn’t make it work without assigning this permission.

After making these changes, reboot your server and you should find Event 491 gone and your Microsoft Exchange Transport service automatically starting once again.

Howto: Disable Windows Simple File Sharing via the Registry and Local Security Policy


Microsoft KB 307874 describes how to disable Windows XP Professional’s simple file sharing. Why would you want to disable simple file sharing on your workstation? The KB explains:

By default, simple file sharing is enabled on a Microsoft Windows XP-based computer if the computer is not a member of a domain. With simple file sharing, you can share folders with everyone on your workgroup or network and make folders in your user profile private. However, if simple file sharing is enabled, you cannot prevent specific users and groups from accessing your shared folders. If you turn off simple file sharing, you can permit specific users and groups to access a shared folder. Those users must be logged on with the credentials of user accounts that you have granted access to your shared folder.

In a nutshell, if your machine is not a member of a domain, and you want to specify non-default ntfs or share permissions, you’ll need to disable simple file sharing.

To disable simple file sharing as explained in KB 304040, follow these steps:

1. Click Start – My Computer

2. On the Tools menu, click Folder Options – View

3. In the Advanced Settings section, clear the Use simple file sharing (Recommended) check box – OK

This method works just fine, but I wanted to disable simple file sharing on machines that had already been deployed, without any end user interaction. I figured the easiest way to do this was to edit the registry on the remote machines. KB 290403 explains that the registry value that needs to be changed to disable simple file sharing is:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ForceGuest

Change the value from 1 (simple file sharing enabled) to 0 (simple file sharing disabled)

You can also disable simple file sharing by changing the following Local Security Policy:

Security Settings – Local Policies – Security Options – Network Access: Sharing and Security Model for local accounts

Change Guest Only – local users authenticate as guest to Classic – local users authenticate as themselves, then run gpupdate /force from a command prompt.

Please note that if you are running Windows XP Home, you will not have the option to disable simple file sharing through Windows Explorer unless you boot to safe mode.

Howto: Migrate file shares, permissions, and user profiles paths in a Windows 2003 domain


I’m in the process of migrating from serv1, a Windows 2003 Domain Controller (DC) to serv2, a new Windows 2003 DC.  Serv1 has approximately 185 student accounts and 5 staff accounts.  Each user has their own shared folder on the server which is defined in Active Directory Users and Computers (ADU&C) user account profile path.  There are a handfull of other shares that need to be migrated as well. 

I decided on the following requirements and stipulations for my migration solution in this particular scenario:

1)  Make an effort to use only freeware or shareware tools whenever possible.

2)  The user home directories (defined by the user profile path) needed to be copied to the new server, but the data inside their home directories was not to be retained on the new server.

3)  I was not going to reshare each folder once it was migrated, so I needed some other method of redefinng the shares on serv2.  I needed the share permissions migrated as well

4)  Existing NTFS  permissions for user home directories needed to applied on serv2.

5)  The user profile path had to be updated in ACU&C from \\serv1\users\%username% to \\serv2\users\%username%

6)  The drive letter location of all the user’s home directories was being changed from c:\users\%username% (on serv1) to e:\users\%username% (on serv2).

I took the time to come up with this methodology since I have to do this type of server migration all the time.  This should also work for migrating from Windows 2000 to Windows 2003.  Here’s my solution:

I initially planned on using the Microsoft File Server Migration Toolkit to migrate from serv1 to serv2, but I found it to be very clunky and not very configurable.  It kind of seemed like it was a migration tool for dummies without any advanced options that would confuse Joe Admin.  I played around with it for about an hour before detrmining it was not the solution for me.

The next path I wandered down was to use Robocopy (with the optional GUI) to copy my \\serv1\users directory to \\serv2\users.  Robocopy is a part of the Windows 2003 Resource Kit Tools, and Robocopy GUI is available from the Technet Magazine November 2006 Utility Spotlight.

Robocopy has a ton of options available, which is why the GUI comes in handy.  I originally planned to copy the \\serv1\users data to \\serv2\users using the syntax found in KB323275, but it never behaved quite as expected.

I tried to execute Robocopy in the following manner (type on all one line), expecting the directory tree structure to copy one folder down (LEV:1) from \\serv1\users, but it only copied the files located in \\serv1\users, but no directories. 

robocopy.exe \\serv1\users \\serv2\users /COPYALL /LEV:1 /ZB /V /FP /W:5 /R:5 /LOG:copy.log

So I changed /LEV:1 to /LEV:2, and it copied the directory structure \\serv1\users\%username%, plus the data in the %username% folder, which was not what I wanted (again, type as one line)

robocopy.exe \\serv1\users \\serv2\users /COPYALL /LEV:2 /ZB /V /FP /W:5 /R:5 /LOG:copy.log

Robocopy frustrated the hell out of me, so I moved on to try xxcopy.exe, which is very similar to Robocopy.  I briefly perused the author’s web site and saw “freeware version”, so I started working with it.  Not until I received error messages about copying between remote shares did I notice the freeware version of xxcopy.exe was for personal property use only – since I don’t own this network, I was not allowed to use the free version per their licensing agreement – so I needed a new direction once again.

I finally resorted to using the good ole Windows xcopy.exe (see KB 289483 and KB 323007 for usage and options) to copy my directory structure from within the source users directory to the destination users directory:

xcopy *.* /T y:\users

This worked too well – it copied all subdirectories, which is definitely not what we wanted.

I was frustrated with my lack of progress, so I went back to my second robocopy, which copied the correct directory structure, but also copied the files within the directories.

robocopy.exe \\serv1\users \\serv2\users /COPYALL /LEV:2 /ZB /V /FP /W:5 /R:5 /LOG:copy.log

Next I used del.exe from within the \\serv2\users in order to delete all the files (but not folders) within the \\serv2\users\%username% structure:

del.exe *.* /f /s /q

This worked great, but did not remove hidden files.  In order to remove the hidden files, I had to do the following:

del.exe *.* /f /s /q /ah

Now I finally had the correct directory structure on \\serv2\users.  I could move on to copying the share permissions, since Robocopy.exe had copied the folder permissions for me when I used the  /copyall option.

Microsoft’s official method of migrating shares from one server to another is documented in KB125996, which requires a export of the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Shares from \\serv1, and the importing of that resultant .reg file into \\serv2.

That process works great as long as the same drive letters are used on both servers.  In my case, c:\users was the source on \\serv1, which e:\users would be the share location on the destination \\serv2.  If you look at the exported .reg file, it’s not in a human readable format, its a bunch of hex numbers.  I hoped I could do a find and replace using a hex editor to change c:\users to e:\users in my exported .reg file, but that was another huge waste of time.

Finally I came across jv16 Powertools 2007, which I installed on \\serv2.  I imported the .reg file from \\serv1 into \\serv2, then ran the Registry Find and Replace utility, and replaced all instances of c:\users\ with e:\users\.  I rebooted \\serv2, and my 190 (or so) shared folders magically appeared!  Finally, I was making progress!

(As a side note, I recommend supporting the developer of this utility, and will be purchasing the $59 commercial license.  Personal licenses are $29.95.  I will gladly pay the $59 rather than have to recreate each share on \\serv2 by hand.)

Finally, I needed to change each of the user’s profile paths in Active Directory Users and Computers from  \\serv1\users\%username% to \\serv2\users\%username%.  I had no desire to edit each account by hand, so I searched for a solution and came up with ADModify.net, which I was faintly familiar with as an Exchange tool.

ADModify is very intuitive to use.  You’ll need to select the domain and source DC, then make sure the “show only users” check box is selected and “show containers only” in de-selected.  Click the green arrow box and expand your domain, and the list of OUs are displayed.  Expand the OU your users reside in and highlight the users whose profile path you’d like to modify.  The only slight roadblock I came acrosss using this utility was that I had to select my users once again from the right most pane before I could press next.

Once you press next, the familiar ADU&C interface appears.  I went to the Profiles tab, and selected the Profile Path check box, then entered \\serv2\users\%username% as the path to the profile.  I pressed the Go button, and all of my user’s profile paths were changed!  My migration was finally complete.

[update 11-09-2007]

KB 310316 describes a registry modification that can be made to modify how Windows Explorer handles permissions when objects are copied or moved to another NTFS volume. When you copy or move an object to another volume, the object inherits the permissions of its new folder. If you want to modify this behavior to preserve the original permissions, follow the instructions to modify the registry.

KB 174273 describes how to use scopy.exe to copy NTFS files or directory structures while maintaining NTFS permissions and restoring Share Level permissions. This method includes copying between partitions, hard drives, or computers.  It also briefly mentions using PermCopy.exe, a command-line utility that copies share-level permissions (access control lists [ACLs]) from one share to another.

If you’re using scopy to copy local group permissions to other domains, read KB 168470 regarding potential access problems with the trusting domain.

If you use some other solution to copy your data to it’s new location but still want to copy NTFS file system access control lists (ACLs), check out KB 323275 for how to do this with Robocopy.