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

Techtip: Change name using Powershell

In Windows Server 2012, you can do most, if not all administrative tasks using Powershell. There are roughly 2400 comdlets letting you manipulate the system in every unholy way imaginable! One of those ways is to change the computer name.

To change the computer name, simply run the following two lines:

You can for example use this code to script renaming multiple computers in bulk, or just to avoid cluttering up your screen with a GUI.

 

 

Change LastWriteTime (Date Modified) on files

So here’s a little nugget that might help you at the end of backup sessions, or in my case, to adjust for the time zone difference on my vacation after forgetting to check my cameras clock for the entire 2 week duration. Despite it’s simplicity, this script is in fact quite powerful, and if used towards the wrong folder, or with the wrong scope (Get-Childitem -recurse) it can cause a bit of damage.

A fun thing about this script is that by changing the time parameter, you can actually put the Date Modified field into the future without changing the clock on your computer.

 

 

 

 

 

Autodeploy one or more servers without System Center

I use this script to deploy one or more identical servers in Hyper-V. The script handles both the use of a Golden Image template .VHDX file, or a clean installation using an ISO install image and will provide you with a question by question gathering of the most common installation parameters.

Prerequisites:

  • Windows Server 2012 release candidate or above
  • Powershell 3.0
  • Hyper-V role installed on the server
  • Hyper-V Powershell module installed on the server
  • A template VHDX file for each operating system you’d like to be able to deploy
  • ISO-files for each operating system you’d like to be able to deploy

Access the Powershell community

Today, when I for once checked my spambox I came across this hot little number from Microsoft.

http://www.microsoft.com/downloads/details.aspx?FamilyID=d46b370b-d272-46b1-ad4e-7ead4e4f701f&prod=zWSz&tech=zScrCz&type=zDLz&displaylang=en

In short, this is a community Powershell script browser. It allows you to search one or more sources for script examples and preview them directly in the application. It even allows you to create you own file repository and make it a searchable location through this app. I’ve just barely begun to scratch the surface, but I really love the easy at which you can use this to find out what’s out there!

Powershell: Share size reporting

A security admin came to me the other day and asked me if I could measure the size of each individual share on the system. I asked him if this wasn’t something most easily done by using Explorer, but since he wanted every single share on all file servers, it would a lot of “right click->Properties”, so I took pitty on him and got to work πŸ˜‰

I created a script where you’re asked the name of the file server. The script then lists out the shares and writes out their individual size to a text file.

Here’s the script:

This script takes a long time to complete in large environments. If anyone has tips on how to streamline the code for better performance, please add a comment πŸ™‚

Automating best pratice for security groups in Active Directory

In order to maintain best practices in a multi domain forest, we occasionally have to create file and application access groups to secure sensitive resources we manage. Creating a 3 groups to do this is a lot of hassle, but it needs to be done, however you don’t need to do it manually.

I created a script to take care of this day to day task for me. The script basically does 3 thing:

  1. It checks if a security group with that name already exists and if so it aborts.
  2. It creates 3 security groups: a “Domain Local” group for rights assignment, a “Global” group to put my users in, and a “Universal” group to link the Global and Domain Local groups, as well as to link groups from other domains in our forest.
  3. It asks the user what folder to add rights to and what rights to add (Read, Write and/or Modify) and then sets those rights on the appropriate folder.

The script uses Quest Active Roles AD Management snapin for Powershell (available here)

I’ve added logging using the transcript functionality, and if you check out line 19 and 114 you see that I’m starting and stopping logging to a specific file using the “Start-Transcript” and “Stop-Transcript” cmdlets. This means that the script will throw and error in ISE since it doesn’t support transcripting, but running it in a normal powershell windows will ensure that everything happing between line 15 to 113 get’s logged!

Without further ado, heres the script:

 

I still consider myself a novice at Powershell, however and advanced one at that, and I’d love to get feedback on better approaches to my scripting, both in the sense of optimizing the script for performance, and simplifying the script itself. I’d also be happy to answer any questions regarding the script πŸ™‚

Updating KMS server settings

I encountered a weird problem with our Key Management Server (KMS) and client licensing recently. The client I’m working with has 3 domains whereas there is a full two way trust between two of them, and limited trust towards the third.

For some reason our Vista client (yes, Vista) we’re trying to update the license towards a KMS service on a domain controller in the third domain with limited trust. It also seems KMS has been deactivated on this server, but that wasn’t the challenge.

To update the KMS server address you need to run the Visual Basic (VB) script c:windowssystem32slmgr.vbs. You can add argument to view the current configuration (-dli), manually set the KMS server (-skms) or do an autodiscover of the KMS server address (-ato).

In this case I ran the following command to see the current config:

I saw that the KMS server was not the one I expected for clients in this domain, so I ran this command to do an auto discover:

This generated an error:
Error code and message: 0xC004F039 The computer could not be activated. The Key Management Service could not be reached.

The cause for this error in our case was that the Vista client tried to update the license towards the last server it updated against. There is no error handling routine in slmgr.vbs that tells the client to do an auto discover of possible KMS servers elsewhere if it fails towards the server it last updated against.

To resolve this I had to clear the name of the KMS server the client already knew in order to force it to discover the actual KMS server on the intranet. I ran the following command to clear the name and run the auto discover:

 

NB. If this had failed, there would have been one last solution. You can update the name of the KMS server manually, thus bypassing the entire auto discovery and eliminating that as an error source. This requires you to know the name and port (usually port 1688) of the KMS server, and is done with the “-skms” switch like this: