Recently we migrated our Printserver from Windows 2003 R2 (yes, it was time…) to Windows 2012R2 and needed a smart and easy way to migrate existing printer mappings from the old to the new server. While migrating the printerserver itself was a very easy and straighforward task using Printbrm (took only about 10 mins!), the question how to migrate the mappings remained open. Doing some research on the net showed that it seemed to be best practice to do this using a logon script. A little bit of more searching brought up a very helpfull and handy PowerShell script which should to the trick. Since all our clients are at least Windows 7, PowerShell was available on clients and we were able to go on with this.

The script was good, but needed some minor tweaks to work well in our environment. For exmaple the script lacked to set the default printer. If you remove the old printer and add a new one you have to set the default printer again, this has been fixed in the version below.

It was also not possible to have 2 different names for the printserver so e.g. some users may have user FQDN (prinserver.domain.com) and some only the simple Name (printserver). To catch all this cases you can now specify more than one name for a print server and all printers will be replaced.

 

To run the script, simple copy the source code to a file on your PC and change the following lines to your need.

 

If you want a quite handy logfile where you can see how your migration is making progress. Change the following line to a path where all users can write.

 

Remove <# and #> from the following lines and run the Script once, to create the logfile with a header line. After the file has been created, add <# and #> again to avoid overwriting the file each time the script is running.

 

Here you can find the complete source code:

 

We wanted to migrate our current backup from a tape solution (LTO-3) to Microsoft Azure.  As we have an initial amount of ~1,5 TB of data to transfer to the Microsoft data center we decided to use the Azure Import/Export service (offline backup) and send it via snake mail to the Microsoft data center. Uploading it to Azure with our current connection will would have required ~1week of constant uploading and blocking the Internet connection.

I don’t want to deep dive into the process here as it is describe quite well (and updated) in this article Offline-backup workflow in Azure Backup . I’d rather like to give some hints to avoid the pitfalls we stumbled over.

disk space

You’ll need some temporary disk space in the size of your backup the use this service. When setting up the backup job you need to have a staging device ready where the Azure Backup Agent can store the data you’ll later copy to the disk you send to the data center. It’s recommended to have the space your backup will consume available although the backup will be compressed by the backup agent. So in reality you won’t need as much space as your original data consumes. The backup volume can be an internal disk, an network share or an USB attached device (but not the drive you want to send to the Azure data center).

Hardware

As stated in the Microsoft documentation the device you send to Microsoft must be an 2,5” or 3,5” internal SATA II or III device. Microsoft will not accept any other devices!

To bring your data onto the to be shipped disk you’ll need to connect this disk to a Computer or the server where you are running the backup. You can either use a USB-to-SATA adapter or connect the disk to an internal port in you PC. When you use a internal Port you should be fine but you’ll at least need Windows 7 Enterprise (as Bitlocker is required) as Operating system to copy the data to your HDD.

Using a USB connector makes things a bit more flexible since you can directly attach the device to your copying computer and also to you virtual servers. But using USB connectors seems not to be as easy as it looks at first glance. As I had to learn while trying to use my existing ICY-Box to connect the disk, not all USB connectors seem to be supported by WAImportExport.exe

If you receive the following error from the WAImportExport tools you most likely have an incompatible device:

[Error] Command failed with exception: AzImportDll.AzImportException: Could not read serial number or signature for the drive. This is a critical error an the command cannot run. This may be due to certain USB adapter or disk drivers that are not fully compatible with the operating system.

I haven’t found any official list naming compatible devices. But while searching the net for the reason for this error I stumbled over this article naming some devices which should be working.

Luckily, I just had ordered another USB connector for a different private project which worked, so I had not to fumble around with this. But to avoid trouble you should order one of the listed to devices.

compatible devices

incompatible devices

 

Storage Account

Azure Import/Export service does currently only classic storage accounts . If you read the documentation carefully you’ll notice it but as it’s not as clear as it should be, I’d like to mention it here.

 

Running WAImportExport.exe

When running WAImport make sure your current path in the shell is inside the directory where the tool is located. Do not call it while being in a different directory as this will result in an error. Not knowing this has cost me about days because I had to run the tool 3 times until I found the problem. At the end of the copy operation the tool is looking for a file in the current directory rather then using an absolute path pointing the directory where it put the file. If this fails you have to do all copying again.