Test lab

I’m currently working on moving my Hyper-V VMs to an iSCSI target in order to better be able to test Hyper-V Live Migration in 2012. Tehre are alot of new features facilitating added functionality in SMB 3.0. In order to do that I of course have to move roughly 270GB of data from my local storage to the iSCSI target, and I just wanted to upload this screenshot from my test lab showing the more than decent speed the transfer is progressing with.

The transfer speed is stable between 90-110MB per second and utilizing in excess of 700Mbps of bandwidth. My NAS is a Thecus 4200pro with 4 disks in a RAID5 configuration.

Techtip: Reassociating an orphaned user after Database move

Every database on a Microsoft SQL Server instance maintains its own Access Control List (ACL) with a list of the users which have rights on the database, and what rights they have. This ACL however, doesn’t contains only contain user names, but also the Security Identifier (SID) of the user. This means that when moving a database, you can’t simply create a user on the instance you’re moving the database to and expect it to have the same rights. It won’t, because the SID of that user will be different, even if the user name is the same.

Microsoft has hedged against this, and allows you to update the ACL on the database by associating the user name in the ACL with the SID of the user with the same name on the instance to which the database has been moved. By doing this, you don’t have to manually delete the user permissions from the database security tab and set them up again. You can simply run a stored procedure.

To check whether or not there are any orphaned users in your database ACL, run this command on the database:

This will list any orphaned users with rights on the database.

To reassociate the users with a valid SID and keep it’s ACL entries on the database, run the following query:

After running the last command, your user rights will be correct for that user. You can test by running the first command again. No entry for that user should show up.

NB. The square brackets <> can be removed.

Installing Active Directory Domain Services using Powershell

This is going to be a short post, simply because it turned out to be ridiculously easy!

Traditionally when installing Active Directory Domain Services (ADDS) you’ve had to use DCPromo to initiate the install. Through this gui-based installation you could configure the name of your domain and your forest, your domain and forest level and whether or not to install a DNS-server along with your Domain Controller (DC).

You can easily do this using Powershell and it requires on two simple one line commands.

First you need to install the ADDS role on your server. Run this command:

Second, configure your ADDS role and decide whether or not to install DNS:

Voila, you’ve just installed a new domain called LAB in a new forest.

Techtip: Connecting to iSCSI targets via Powershell

Imagine wanting to set up two or more nodes in a file cluster and wanting to avoid configuration mismatches creating a troubleshooting nightmare even before putting your solution into production! How would you best go about doing that? Script it, and run the script throughout your nodes!

In this article I’d like to focus only on a very simple iSCSI target scenario. Two commands letting you create a persistent connection to an iSCSI target using Powershell. This in turn will let you do the exact same on every server you’d like to remain identical. You could even run it in a foreach loop letting you execute the same command set across a number of nodes without even having to log into them, and I’ll get to that in a later article.

First, connect to your iSCSI server:

Second you need to find your iSCSI target and connect to it. If there’s only one target on your server then you’ve got an easy time, but in case there are several, you should filter by it’s name, like this:

Replace fileshare1 with the name of your iSCSI target. You might want to test your filter before running the command and if so, simply omit the “Connect…” command after the pipe above and make sure the result set only contains the targets you’d like to connect to.

Of course there’s more, and if you’d like to delve deeper, please check out this blog:

Printer Redirection and Easy Print

Easy Print is a feature implemented in Windows Server 2008, and developed further for Remote Desktop Services in Windows Server 2008 R2.  It eliminates the need of specific print drivers for most redirected printers on Terminal Servers.

Easy Print is implemented through Group Policy, or Local Group Policy (gpedit.msc) and is found in “Computer Policy->Administrative Templates->Windows Components->Remote Desktop Services->Remote Desktop Session Host->Printer Rediction”. The setting is called “Use Remote Desktop services printer driver first”. There is no configuration involved in enabling this setting.

In my case, Easy Print may have eliminated issues resulting in printer redirection not working on a Windows 2008R2 RDS server serving as home office solution. The issue was specifically users not getting their local printers redirected to the server, thus not being able to print locally.

Several errors with Event ID 1103 was present in the Event Log on the TS server. The error message was: “An internal communication error occurred. Redirected printing will no longer function for a single user session.“.

More information on Event ID 1103 here: http://technet.microsoft.com/en-us/library/cc727392%28v=ws.10%29.aspx

More information on Easy Print here: http://blogs.msdn.com/b/rds/archive/2009/09/28/using-remote-desktop-easy-print-in-windows-7-and-windows-server-2008-r2.aspx