Robocopy File Server with share/NTFS permissions intact.

| Posted in , , | Posted on 3/19/2009

0

Last week I had to convert a rather large File/Print server from a physical box to a virtual box. No doubt most will say that P2V is the only way to go and I would be hard pressed to disagree. However, given the amount of data needing to be moved, upgrades I wanted to perform (Server 2003 to Server 2003 R2), and reclamation of space I chose to start with a fresh install. Thus I needed a solution that would allow me to move the shares with both share level and NTFS permissions intact. As we are a 24 hour shop down time is hard to come by so the process needed to be as transparent to the user as possible. Lastly, it needed to be free.

In walk Robocopy. If you have never used this tool you need to check it out. It's available as a part of the Windows Server 2003 Resource Kit . If your comfortable with the command line you should have no problem diving right in. For those of you that are a bit more timid, here's a good resource for the different switches available. Of course, there is also a GUI available.

I started the process by building a bare bones virtual machine (we are a VMware shop). I installed server 2003 R2, patched it up, and then installed the following services:

  • File Server Management

  • DFS Management

  • File Server Resource Manager

  • Print Management

Once everything was up and stable I started to add the additional hard disks I would need to mirror the data from the source server. It's important to note that the drive letters you assign must match the drive letters on the source file server. In this case mine looks as follows:

Source Drive Letters: C - E - H

Target Drive Letters: C - E - H

The drive lettering is like this because I eliminated the A, F, and G drives. No need for a floppy on a VM(A) and with drives F and G I moved the data to drives E and H. Two more steps to perform before we start copying data. We need to export the following registry key from the source server and import it to the destination server:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares

Microsoft has a good knowledge base article on saving and restoring existing Windows shares. Next, if you have printers that need to be migrated, grab the Windows Print Migrator (v3.1). Once this has been completed your ready to start moving data. I setup a simple batch file that would copy all the data from the source to the target sequentially. It looked similar to the following:

robocopy "source drive letter\source folder 1" "file://target_server/drive%20admin%20share/source%20folder%201" /COPYALL /MIR

robocopy "source drive letter\source folder 2" "file://target%20server/drive%20admin%20share/source%20folder%202" /COPYALL /MIR

Should look like this: robocopy "e:\test" "file://target/e$/test" /COPYALL /MIR



So what does this do? The /COPYALL switch copies data, attributes, timestamps, security, ownership info, and auditing info. The /MIR switch mirrors the directory tree (purging directories if necessary) and copies all subdirectories (including empty ones). The first time you run this command it will take some time for the data to be moved as it has to copy evrything. Once it has completed it's first run, subsequent runs of these commands will only copy over new and changed data.


I ran this script daily for a few days. Once I was ready to cutover, I ran one last synch, shutdown the source server, and deleted it's account from Active Directory. I then changed the IP address of the new file/print server to that of the old one, renamed it to the same name of the old file/print server and rebooted. Presto, new file server up and running with maybe a 10 minute outage at most.

Force users Web session into SSL/TLS

| Posted in , , , | Posted on 3/19/2009

0

You need to force a users sessions into Secure Sockets/Transport Layer Security. If your like me, you administer the server and not the actual application. Thus, I am not going to add any code/scripting into the application administrators web pages. The easiest approch I have found to redirecting a web page (without using a script) to port 443 (SSL/TLS) is to create a second site within IIS using the same host header as the site you are wanting to force into SSL/TLS. The steps are as follows:

1. Ensure the primary site is requiring SSL (Image 1).












2. Staying on the primary site, click the web site tab, then click advanced.
3. Here you modify the identity of the web site using host headers. Change the TCP port to anything other than 80 (81 is probably a good choice.).





4. Click OK and OK to accept the new settings.

What you just did was set the site to only accept secure connections (step 1) and changed TCP port 80 to 81. At this point if you were to attempt to access the site using the appropriate URL and port 81 (example: http://localhost:81/) a 403.4 error should be displayed saying https is required. Now we can create the secondary site that will force the SSL redirect.

1. In IIS Manager right-click Web Sites and select New - Web Site.
2. Give the site a descriptive name, such as your site ssl redirect.
3. Right-click the site and select properties.
4. Under Web Site click advanced and add a new host header value. This value must match the Host Header value (yoursite.yourdomain.com) of the site you want redirected to SSL.
5. Select OK.
6. Select the home directory tab.
7. Choose "A redirection to a URL".
8. In the Redirect to: box enter the URL (https://yoursite.yourdomain.com/).












Test.

The site you just created should accept connections on port 80 (unsecure) and redirect the same URL (host header) to the primary site on port 443 (SSL/TLS).