Home » Windows Server 2012 R2

Category Archives: Windows Server 2012 R2

Server Core on VMware

When I was a Virtual Technical Evangelist for Microsoft Canada I spent a lot of time telling you why you should use Server Core… especially if you were on Hyper-V.  Why?  You save resources.

It is now over two years since I turned in my Purple Badge, and I still think Server Core rocks.  In fact, when Windows Server 2016 comes out I will probably spend a lot of time telling you about the new Nano Server option that they are including in that version.  More on that to come.

Of course, I still like Hyper-V, but as an independent consultant I recognize (as I did quietly when I was with the Big Blue Machine) that the vast majority of the world is still running VMware for their enterprise-level server virtualization needs.  That does not change my opinion of Server Core… it still rocks, even on VMware.

Of course, in order to get the full benefits of the virtualized environment, a VMware machine requires the installation of the VMware Tools (as Hyper-V requires the installation of Integration Services).  With a Server with a GUI that is easy to do… but since Server Core is missing many of the hooks of the GUI, it has to be done from the command line.  Here’s how:

1. As you would with any other server, click Install VMware Tools

image

2. Connect to and log on to the virtual machine.  You will have to do this with Administrator credentials.

3. navigate to the mounted ISO (if you only have a single hard drive attached it will usually be D:)

4. type in the following command line: setup64.exe /S /v “/qn reboot=Y”

image

Once you have done this, the VMware tools will install, and your server will reboot.  Nothing to it!

How To Cheat With PowerShell

Admit it… you are a crappy coder.  You may be a pretty fair IT Professional, but you cannot script your way out of a paper bag.  There’s a support group for you.

Hi, my name is Mitch, and I’m a lousy scripter. 

Admittedly I have never been to an AA or NA meeting; I have never really done well with support groups, and the only addiction I ever had I kicked without anyone’s help.  However I’ve seen plenty of AA meetings on TV and in movies, and that’s how they usually start.

4214_Powershell%20blore-logo_png-550x0Recently I wrote an article called iSCSI Virtual Disks: If you have to make a bunch… Use PowerShell! Thanks to one of my loyal readers (who despite or because of their loyalty are always quick to point out when I make a mistake) I realized that despite saying that it did, the script did not actually connect the virtual disks to the iSCSI Target… and I had to find a way to do that before looking stupid for too long.

Here’s the problem… I’m not really a PowerShell guru, just a regular IT guy who realizes the amazing power of the tool.  And as was written in an article that went live this week (guest-written by a colleague and friend), while using Google to find samples of scripts is great, there are two spectacular tools to help you on your way. 

The first such tool is called Get-Help.  You can type that in PowerShell to find out about any cmdlet.  Cool!

However what do you do if you know there is probably a cmdlet, but you don’t know what it is?  Well, the second one is the Integrated Scripting Environment (ISE).  PowerShell’s ISE is the easiest way to build your scripts, whether they are simple, single-line cmdlets, or large, vast, flowing scripts that take up pages and pages.

Step 1: Run PowerShell ISE.  This is pretty easy, and if you haven’t figured it out, just click on the Start menu and type ISE.

Step 2: Select your Module.

image

The PowerShell ISE window is generally divided into three parts: A live PowerShell window, a scripting window, and the Commands list.  The Commands section is literally a list of every command and cmdlet in PowerShell… thousands of them.  However let’s say you know the command you are looking for has to do with iSCSI Targeting… select that Module from the drop-down list, and all of a sudden your thousands of commands turn to twenty-six.

What I want to do is to map a previously created iSCSI Virtual Disk to an iSCSI Virtual Target… so the top target (Add-IscsiVirtualDiskTargetMapping) sounds pretty spot-on. I’ll click on it, and if this is the first time clicking on a command for this module, I will get the following message:

To import the “iSCSITarget” module and its cmdlets, including “Add-IscsiVirtualDiskTargetMapping”, click Show Details.

SNAGHTML37e7dde

When I click Show Details, I am presented with several options.  These will differ for every cmdlet, and they will correspond to the optional (and required) command-line switches that I might need.

The Path is going to be the full name and path of the previously created iSCSI Virtual Disk.  In my case I created several, but they all look like q:\iSCSIVirtualDisks\Disk1.vhdxThat is what I am going to enter there.

The TargetName is the name of the target I created… in this case it might look like Target1.

It is important that you pay attention to the ComputerName box because as you saw in my previous article, I might name the iSCSI Virtual Disks (my VHDX files) the same thing on each host.  When I enter the ComputerName TargetServer1 PowerShell knows to look for Target1 on that server.  If you do not enter a ComputerName then it will assume that it should look on the local server… and that could be disastrous, especially if those VHDX files are already otherwise mapped and in use.

The Credential box is exactly what it sounds like… If your user account does not have credentials to execute a command on a remote system, you can use this box to specify alternate credentials.

The Lun box allows you to set the LUN (Logical Unit Number) of the virtual disk.  If you are not concerned by this, the default is for the lowest available LUN number to be assigned automatically.

If you want more help, notice that there is a blue circle with a ? right in the window.  Click on that, and you get a much more detailed Help dialog than you would get by typing Get-Help Add-IscsiVirtualDiskTargetMapping in the PowerShell window will pop up for you.  If you don’t believe me, try them both Smile

image

imageSee? I told you!

So let’s go ahead and populate those fields the way I said:

image

Once you populate them, there are three buttons at the bottom of the Commands console that you can use:

Run does exactly what you would think… it runs the command with the appropriate switches.

Insert puts the command and switches into your PowerShell (blue) window, but does not execute the command.

Copy is also pretty self-explanatory… it copies it to the clipboard for you to put in the scripting (white) window… or anywhere else you might want to insert it with a Ctrl-V.

So I don’t really know how to script, but I know what I want to accomplish… PowerShell ISE takes me from base-camp to the goal like a Sherpa guiding me on Everest.  Yet another way to love PowerShell… and get to know it better!

iSCSI Virtual Disks: If you have to make a bunch… Use PowerShell!

I don’t mean to sound like a broken record but when you have to do things over and over again, it simply doesn’t make sense to do it manually.  Sure, the GUI (Graphical User Interface) in Windows is great… but if you have to click through the same wizard ten times to create ten of something… well, I guess all I am saying is that PowerShell makes a lot more sense.

Last month I went through a relatively time-consuming exercise to create three LUNs on each of three Software SANs on Windows Server 2012R2.  Ok great… but I then discovered that for my project I couldn’t use three LUNs of 1.5TB each… rather I needed to create nine LUNs of 500GB each.  What a royal pain!  By the way, seeing as I have to do this on three separate servers, my workload just tripled from doing it 9 times to doing it 27 times!  This does not sound like fun.

Fortunately, I can do it all in PowerShell, which means I can save a whole lot of clicking.  We are going to do this all on three different servers, named   Let’s look at how:

Parameters

a) We are going to create three iSCSI Target Servers called TargetServer1, TargetServer2, and TargetServer3.

b) We are going to present the targets to five servers called InitServer1, InitServer2, InitServer3, InitServer4, and InitServer5.

c) We are going to create 9 500GB drives on each server, plus three 1GB drive on each server.  In case you can’t tell, these drives will be used for nine different Failover Clusters, and the 1GB drive will be the witnesses.

d) We are going to attach all of the iSCSI Virtual Disks to the appropriate Targets.

Let’s Go!

1) Before we do anything, we want to create a session that will repeat the same tasks on each computer.

PS C:\> $session=New-PSSession –ComputerName Server1,Server2,Server3

That will save us having do do a few things over again, even though we could have done it with a simple ‘'<Up-Arrow> <Backspace>” or two.

2) We have to install the iSCSI Target Role Feature on all of these server. So:

PS C:\> Invoke-Command –Session $session {Install-WindowsFeature –Name iSCSI-TargetServer

2) The next thing we are going to do is actually create the iSCSI Targets on the three servers.  By doing this with the $session that we created we will end up with three targets with the same name.  I trust you will go back and fix that by hand later on.  If you prefer to avoid that step though, we could bypass the $session and use the manual-PowerShell way Smile

PS C:\> Invoke-Command –session $session {New-IscsiServerTarget –TargetName Target1 –Credential InitServer1,InitServer2,InitServer3,InitServer4,InitServer5

or…

PS C:\> New-IscsiServerTarget –ComputerName TargetServer1 –TargetName Target1 –Credential InitServer1,InitServer2,InitServer3,InitServer4,InitServer5

PS C:\> New-IscsiServerTarget –ComputerName TargetServer2 –TargetName Target2 –Credential InitServer1,InitServer2,InitServer3,InitServer4,InitServer5

PS C:\> New-IscsiServerTarget –ComputerName TargetServer3 –TargetName Target3 –Credential InitServer1,InitServer2,InitServer3,InitServer4,InitServer5

PS C:\> New-IscsiServerTarget –ComputerName TargetServer4 –TargetName Target4 –Credential InitServer1,InitServer2,InitServer3,InitServer4,InitServer5

PS C:\> New-IscsiServerTarget –ComputerName TargetServer5 –TargetName Target5 –Credential InitServer1,InitServer2,InitServer3,InitServer4,InitServer5

3) Now that we have created the Targets, we have to create the disks.  Unlike the Targets (whose names will be used outside of their own servers), I don’t mind if the names of the actual disks on each server.

Invoke-Command –session $session {

New-IscsiVirtualDisk –Path q:\iSCSIVirtualDisks\Disk1.vhdx –SizeBytes (500GB) –UseFixed

New-IscsiVirtualDisk –Path q:\iSCSIVirtualDisks\Disk2.vhdx –SizeBytes (500GB) –UseFixed

New-IscsiVirtualDisk –Path q:\iSCSIVirtualDisks\Disk3.vhdx –SizeBytes (500GB) –UseFixed

New-IscsiVirtualDisk –Path q:\iSCSIVirtualDisks\Disk4.vhdx –SizeBytes (500GB) –UseFixed

New-IscsiVirtualDisk –Path q:\iSCSIVirtualDisks\Disk5.vhdx –SizeBytes (500GB) –UseFixed

New-IscsiVirtualDisk –Path q:\iSCSIVirtualDisks\Disk6.vhdx –SizeBytes (500GB) –UseFixed

New-IscsiVirtualDisk –Path q:\iSCSIVirtualDisks\Disk7.vhdx –SizeBytes (500GB) –UseFixed

New-IscsiVirtualDisk –Path q:\iSCSIVirtualDisks\Disk8.vhdx –SizeBytes (500GB) –UseFixed

New-IscsiVirtualDisk –Path q:\iSCSIVirtualDisks\Disk9.vhdx –SizeBytes (500GB) –UseFixed

New-IscsiVirtualDisk –Path q:\iSCSIVirtualDisks\Disk1W.vhdx –SizeBytes (1GB) –UseFixed

New-IscsiVirtualDisk –Path q:\iSCSIVirtualDisks\Disk2W.vhdx –SizeBytes (1GB) –UseFixed

New-IscsiVirtualDisk –Path q:\iSCSIVirtualDisks\Disk3W.vhdx –SizeBytes (1GB) –UseFixed}

Warning: This script is going to take a ridiculously long time.  That is because when creating the virtual disks, PowerShell is zeroing out all of the bits.  This is the safer way to do things if you are re-using your disks.  If they are brand new clean disks, then you can add the switch DoNotClearData to your statements.  However unless you are in a real hurry, I would take the extra time.

4) Our disks have been created, but we have to attach them to the Targets.  So:

Invoke-Command –session $session {

Add-IscsiVirtualDiskTargetMapping –Path q:\ISCSIVirtualDisks\Disk1.vhdx –TargetName Target1

Add-IscsiVirtualDiskTargetMapping –Path q:\ISCSIVirtualDisks\Disk2.vhdx –TargetName Target1

Add-IscsiVirtualDiskTargetMapping –Path q:\ISCSIVirtualDisks\Disk3.vhdx –TargetName Target1

Add-IscsiVirtualDiskTargetMapping –Path q:\ISCSIVirtualDisks\Disk4.vhdx –TargetName Target1

Add-IscsiVirtualDiskTargetMapping –Path q:\ISCSIVirtualDisks\Disk5.vhdx –TargetName Target1

Add-IscsiVirtualDiskTargetMapping –Path q:\ISCSIVirtualDisks\Disk6.vhdx –TargetName Target1

Add-IscsiVirtualDiskTargetMapping –Path q:\ISCSIVirtualDisks\Disk7.vhdx –TargetName Target1

Add-IscsiVirtualDiskTargetMapping –Path q:\ISCSIVirtualDisks\Disk8.vhdx –TargetName Target1

Add-IscsiVirtualDiskTargetMapping –Path q:\ISCSIVirtualDisks\Disk9.vhdx –TargetName Target1

Add-IscsiVirtualDiskTargetMapping –Path q:\ISCSIVirtualDisks\Disk1W.vhdx –TargetName Target1

Add-IscsiVirtualDiskTargetMapping –Path q:\ISCSIVirtualDisks\Disk2W.vhdx –TargetName Target1

Add-IscsiVirtualDiskTargetMapping –Path q:\ISCSIVirtualDisks\Disk3W.vhdx –TargetName Target1}

So if we did it properly, we should now have three software SANs (Targets) with nine virtual disks each, that are each connected to three iSCSI targets, which are in turn each presented to five iSCSI initiators.  Additionally, we have three ‘Quorum Disks’ on each Target. 

In my next article, I will show you what needs to be done on the initiator side to get these all going for your Failover Clusters.  Until then… Happy scripting!

Server Core: Every bit the Full Server as the GUI is!

Microsoft introduced Server Core with Windows Server 2008, which means that it was the same kernel as Windows Vista.  Now, nobody is going to stand up and sing the praises of Vista, but Server 2008 was a very solid OS.

You may (or may not) remember that there was a campaign around Vista called ‘The WOW starts NOW!’ Catchy, huh?  Well, because Server Core was literally taking the ‘bling’ out of Windows Server, there was an internal joke at the time that ‘The Wow STOPS Now.’

While Server Core never looked very exciting for end users, for IT Admins, and especially those who were building virtualized environments, Server Core was a godsend. Let’s go through this one more time to demonstrate why:

  • The Windows Graphical User Interface (GUI), which is the difference between Server Core and not, takes resources.  How much?  Well, depending on the server it might be as much as 3-4GB on the hard drive and as much as 350MB of RAM.  Neither of these is a big deal in a world where servers have 128GB of RAM and terabytes of storage on them, right?  Well on a virtualization host that may have on average 100 virtual machines running simultaneously, that translates to 400GB of storage and a ridiculous 35GB of RAM… Ouch.
  • Every component that is installed in Windows has to be patched from time to time.  The fewer components you have installed, the less patching that has to be done.
  • The more you have installed in Windows the larger your attach surface.  By removing components, you can minimize this, making your computer more secure.

servercore01In Windows Server 2008 here’s what we saw when we initiated the installation… a menu with all three editions (Standard, Enterprise, Datacenter) Full Installation, and the three editions with Server Core Installation.

I have been singing the praises of Server Core for as long as it has been available, but often to deaf ears.  I always assumed this was because most IT Admins liked the GUI.  Recently I was in a presentation given by Jeffrey Snover, who gave me another perspective on it… the terminology in Server 2008 was part of it.  You see, people look at the options ‘Full Server’ versus ‘Server Core’ and they immediately think ‘power & performance.’ A Full Server must do more than a server core server… why?  It is FULL!

Of course, in Server 2008 it didn’t help that Server Core actually was a hobbled version of Server… there were a few roles that worked on it, but not too many.

As with so many Microsoft products, that got better in 2008 R2, and even better in Server 2012 and 2012 R2.  Today you would be amazed at what can run on Server Core… in fact, nearly everything that you do on a server can run on Server Core.  So there is little wonder that Microsoft made a change to the terms…

servercore02No longer is it a question of FULL versus CORE… Now our options are Server Core Installation and Server with a GUI.

There are two differences to notice in this screen shot… the first is that there are only four options because Microsoft eliminated the Enterprise SKU.  The second is that the default option (a la next – next – next installations) is Server Core.  While some admins might say ‘Yeah I wasn’t paying attention so I ended up with Server Core and had to reinstall,’ the reality is that most of us, once we understand the benefits and the manageability options, will want to install Server Core instead of the GUI servers.

Of course, there are admins who will still be afraid of the command line… but because most of the ongoing administration of our servers (the things we usually do with MMC consoles) Server Core, or at the very least MinShell will make our lives easier.  MinShell removes most of the GUI, but leaves the MMC consoles.

But what if I wanted to use the GUI to configure the system, and then get rid of it completely?  We can definitely do that.  One method of doing it is to use the Server Manager’s Remove Roles and Features option.  (The GUI is a feature, and is listed under User Interfaces and Infrastructure – Server Graphical Shell)  This will uninstall the components and save the RAM… but it will not free up your hard disk space.  To do that, use the following PowerShell cmdlet:

Uninstall-WindowsFeature –Name Server-Gui-Mgmt-Infra,Server-Gui-Shell –ComputerName <Name> -Remove -Restart

The -ComputerName option allows you to do this to remote computers, and the -Remove option actually removes the bits from the hard drive.

What can you do with Server Core? I won’t say everything… but nearly so.  It is no longer just your Hyper-V hosts… it is your domain controllers, SQL Servers, Web Servers, and so much more.  As long as you are able to learn a little bit of PowerShell… and how to enable remote management on your servers.

Now go forward and save your resources!

Where am I? HELP!

My colleague created a virtual machine for me in our datacentre a few weeks ago.  (Thanks Michael!)  Earlier this week I needed to create a second virtual machine to cluster with it, and I felt that the best way to maximize my resources completely would be to create another virtual machine identical to the first.  Okay, all I had to do was pop open the Settings window for the virtual machine and copy it.

We have 25 physical host servers in the lab environment in question, and no Virtual Machine Manager.  Crap.

I could, if I had to, connect to each host one by one looking for the virtual machine in question, but that would be a waste of time… not to mention that as a one-off solution it could work, but it is a bad habit to get into.  I needed a better solution.

If you ever find yourself in the position, here’s a tip: As long as you have the Integration Services installed, there is a registry key in the virtual machine that gives me my answer.  So open Regedit and navigate to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters

See? There it is, right there in black and white.  In fact, it’s there three times – under HostName, PhysicalHostName, and PhysicalHostNameFullyQualified.   I no longer need a map, I no longer need to go looking by hand.

But Mitch, isn’t there a way to do this in PowerShell?

I’m glad you asked.  Sure, here it is:

(Get-ItemProperty –path “HKLM:\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters”).PhysicalHostName

Of course, if you are a stickler about it, you can change the last bit to PhysicalHostNameFullyQualified, but that’s up to you.

Now that you know where you are… keep going!

Let’s Spread the Action Around… With NLB! (Part 1)

**AUTHOR’S NOTE: I have written hundreds of articles on this blog over the past decade.  Until recently I spent a lot of time taking screen shots of GUI consoles for my how-to articles.  For the time being, as I try to force myself into the habit, I will be using Windows PowerShell as much as possible, and thus will not be taking screen shots, but instead giving you the cmdlets that I use.  I hope this helps you as much as it is helping me! –MDG

I have written at length about Failover Clusters for Active-Passive services.  Let’s move away from that for a moment to discuss Network Load Balancing (NLB) – the tool that we can use to create Active-Active clusters for web sites (and other static-information services).

While NLB does, after a fact, cluster services, it is not a failover service… and is in fact a completely different service.  For my use case, it is usually installed on a server running IIS.  Start by installing it:

PS C:\> Install-WindowsFeature NLB –ComputerName Server1

Of course, having a single server NLB cluster is like juggling one ball… not very impressive at all.  So we are going to perform the same function for at least a couple of hosts…

PS C:\> Install-WindowsFeature NLB –ComputerName Server1,Server2,Server3

By the way, notice that I am referring to the servers as hosts, and not nodes.  Even the terminology is different from Failover Clusters.  This is going to get confusing at a certain point, because some of the PowerShell cmdlets and switches will refer to nodes.

Now that the feature is installed on all of our servers, we are almost ready to create our NLB Cluster.  Before we do, we have to determine the following:

  • Ethernet Adapter name
  • Static IP Address to be assigned to the Cluster

You are on your own for the IP address… it is up to you to pick one and to make sure it doesn’t conflict with another server or DHCP Server.

However with regard to the Ethernet Adapter name, there’s a cmdlet for that:

PS C:\> Invoke-Command –ComputerName Server1 –ScriptBlock {Get-NlbClusterNodeNetworkInterface}

Notice that I am only doing this, for the time being, against one server.  That is because I am going to create the cluster on a single server, then add my hosts to it afterward.

So now that we have the information we need, let’s go ahead and create an NLB Cluster named WebCluster, on Server1, with the Interface named Ethernet 2, and with an IP Address of 172.16.10.199:

PS C:\> New-NlbCluster –HostName Server1 –InterfaceName “Ethernet 2” –ClusterName WebCluster –ClusterPrimaryIP 172.16.10.199 –OperationMode Multicast

It will only take a minute, and you will get a response table listing the name, IP Address, Subnet Mask, and Mode of your cluster.

Now that we’ve done that, we can add another host to the NLB Cluster.  We’ll start by checking the NIC name on the second server, then we will add that server to the NLB Cluster:

PS C:\> Invoke-Command –ComputerName Server2 –ScriptBlock {Get-NlbClusterNodeNetworkInterface}

PS C:\> Get-NlbCluster –HostName Server1 | Add-NlbClusterNode –NewNodeName Server2 –NewNodeInterface “Ethernet”

Notice that in the first part of the script we are getting the NLB Cluster Name from the Host Name, and not the Cluster Name.

This part may take a few minutes… Don’t worry, it will work.  When it is done you will get a response table listing the name, State, and Interface name of the second host.

You can repeat this across as many hosts as you like… For the sake of this series, I will stick to two.

In the next article of the series, we will figure out how to publish our web sites to the NLB Cluster.

Help! My Servers Aren’t Being Monitored!

SNAGHTML6643d4fThis isn’t right… I have System Center Operations Manager monitoring all of my servers for me, but this morning I noticed that several of my servers are in a warning state, but they are greyed out (which implies that they aren’t reporting in properly).  What do I do?

This is not uncommon, especially in smaller organizations where you may have a single IT Professional running everything.  While it is not a good practice, some IT Pros will use their own credentials (which are obviously going to be Domain or Enterprise Admin accounts) to make things work.  Here’s the problem… you set up your credentials in System Center Operations Manager as a Run As account… and then at some later date you changed your password.

It is never a good idea to use an individual’s credentials as a Run As account.  It is also never a good idea to provide Domain Admin credentials to a program, but that is another issue that I will tackle later on.  What you should do, when configuring System Center Operations Manager, is create action (or Service) accounts in Active Directory.  Use ridiculously long and impossible to guess passwords (Jean MacDonald Kennedy was the 23rd Queen of Tahiti) and change them on a less frequent basis… say, when you change the batteries in your smoke detectors.

So now we have a bunch of computers that are being monitored… oh wait, no they aren’t.  They only look like they are being monitored.  We’d better fix that, and pronto!

We have to figure out what servers this account applies to.  We cannot simply delete the RunAs account, because it is going to be associated with a profile.  So let’s start by figuring out what profile that is.

1) In the Administration workspace navigate to Run As Configuration – Accounts and locate the errant account in the list of action accounts.  Right-click on it, and click Properties.

2) In the Properties window click on Where is this credential used?For the sake of this article, the only profile listed is Default Action Account.  Close Account Usage and Run As Account Properties.

3) Navigate to Run As Configuration – Accounts and locate the profile.  Right-click on it and click Properties.

4) In the Run As Profile Wizard navigate to Run As Accounts.

5) In the list of Run As accounts find all instances where the user account is listed.

image

6) One by one, click Edit… In the Add a Run As Account window change the account to your Service Account.  Click OK.

SNAGHTML6821e2c 

7) When you have done this for all instances (remember, you may need to scroll down) click Save.

** IMPORTANT NOTE: If you get error messages preventing you from saving the profile, you can either break your back trying to troubleshoot the SQL errors… or if there aren’t too many systems using the offending account, you can delete those servers from SCOM, and when you have resolved the issue, go back and re-discover them.

Once this is done, you can now delete the Run As account:

8) Navigate to Run As Configuration – Accounts

9) Right-click on the offending account and click Delete. (Accept any warning).

That should do it!  Go forth and manage, and remember… an unmanaged server can work great and save you all sorts of time… until it stops working and you have no idea why, or even that it did stop working.

%d bloggers like this: