Archive for the ‘Microsoft’ Category

Jul 14

Just a quick note today, I know, it’s been a while since I posted anything on here, but I’ve been extremely busy!!

I came across the need to change the “ComputerNameString” of a VM in SCVMM 2012. A VM had been created from a template, and the admin used the NetBIOS domain name for AD to add it to the domain. When the admin then tried to RDP to the server from the SCVMM console an error occurred, stating that “machinename.NetBIOSDomain” couldn’t be contacted.

Quite quickly, I got a call.

Here’s the simple answer:

Right click on the machine, and choose “Refresh”.

This setting is set when the VM is created, but will update from a refresh as long as guest services are installed. Once the refresh is completed, the “Connect via RDP” option should function again.

Hi Again! Time for part 3 of the series walking you through setting up a 2012 R2 Preview Hyper-V Cluster.

Part 1 was the prep, available here.

Part 2 setup the cluster, and that’s available here.

This time, we’re setting up some VM’s, and enabling live migration, so that we can test the cluster features.

To start, make sure the 3 VM’s we’ve configured so far are running. That’s the domain controller, and the two Hyper-V hosts. On the domain controller, copy over the 2012 R2 Preview ISO file, and copy it onto the cluster storage so that both Hyper-V hosts can access it. Then, open up Failover Cluster Manager. When adding clustered VM’s, you need to add them via Failover Cluster Manager, otherwise, they’ll be non-clustered VM’s. To add a VM, do the following:

1. In Failover Cluster Manager, right click on “Roles” and then choose “Virtual Machines” followed by “New Virtual Machine”.
2. Choose a node to create the VM on and click OK.
3. Click Next on the first screen, then give your VM a name on the second.
4. Make sure you change the location of the VM to be on your cluster storage. This will be in “C:\Cluster Storage\Volume1\”
5. If you want a backwards compatible machine, choose “Generation 1″. To see and test all the new features, choose “Generation 2″ and then click next.
6. Give the machine some RAM, and then choose whether or not to enable Dynamic Memory. Click Next.
7. Choose your external switch (or any other switch you’ve created) for it’s networking, and then click Next.
8. Create a hard disk, making sure it’s disk is less than the size of your iSCSI volume!
9. Now you can choose to install an OS later (at which point you can choose how at boot time), or to mount a CD now, or to let the machine know you’ll be booting from a network based install method. Choose the bootable image option, click Browse, locate your 2012 R2 Preview ISO file and click next.
10. Click Next.
11. Click Finish.

Now, you can boot your machine, it’ll boot from the CD and you can install the OS.

Once that’s done, you can start playing with Failover. Try switching off one of the hosts (power it off the harsh way even) and see what happens… Use the live migrate option to move the machines around.

Hi Folks,
So over in Step 1, we created our lab systems, and installed the roles we needed onto each server. We also configured the domain and joined our Hyper-V and SCOM hosts to it.

Now we’re going to create the iSCSI target on the domain controller, and create the cluster on the Hyper-V hosts.

Firstly, we need to start by configuring the iSCSI target. I’d use a dedicated hard disk for this, so add a second disk to your VM (of at least 60GB), once that’s done, open Server Manager on the DC.

Navigate through “File and Storage Services” then “Disks” under “Volumes”. You should have a disk with ID 1, which has an unknown partition, or may not even be initialised. Create a new volume on the disk, which will mark the disk with the GPT info and create a partition. Once complete, click Close.

On the left of Server Manager, now click “iSCSI”. You should see something similar to this:


Click on “To Create an iSCSI virtual disk, start the New iSCSI Virtual Disk Wizard”. Choose your newly created volume:


Give your iSCSI disk a name, this will be used for the Hyper-V cluster, for any quorum requirements. Make it a 5GB disk, and if you want to save some disk space, choose “Dynamically Expanding”. You’ll need to create a new iSCSI target, so choose this option and click next. GIve your target a name (mine’s “iSCSI-Target”) and click next. You’ll need to add some initiators, so click Add, and add them by IP. These IP’s will be those you added to your Hyper-V hosts. You do this by choosing “Enter a value for the selected type” and choosing “IP Address”:


Enable CHAP auth if you want to, but I won’t be, it’s only for a lab. Once complete, click Tasks, then “New iSCSI Virtual Disk”. Run through the wizard again, this time making a 50GB disk. This will be used to store your VM’s. This time, you can choose the existing iSCSI target. You’ll end up with something like this:


This gets us to the point of iSCSI configuration completed. It’s time to setup the cluster…

We’ll need to add the Failover Clustering feature to the Hyper-V hosts, and the management tools to the DC. If you add the two Hyper-V hosts into Server Manager on the DC, then you can do all of this from one place… much easier!

Under “All Servers” right click on one of your Hyper-V hosts, and choose “Add Roles or Features”. Click next until you reach the features page. Check the box for “Failover Clustering” and click next, keep going and start the install.  Do the same for the second Hyper-V host. Because I want my Hyper-V hosts to be “Server Core” at the end, I’m also going to install the Failover Cluster feature tools onto the DC. This can be done in the same way, but choosing the tools under “Remote Server Admin Tools” then “Feature Admin Tools” in the “Add Roles and Features” wizard.

On one of the servers, open the Failover Cluster Manager tool (in the tools menu in Server Manager). Choose “Create Cluster”. Add the two Hyper-V hosts into the cluster wizard:


Allow the tool to run the cluster tests… if any failures appear, resolve them first. After that you’ll need to enter a Cluster Name and IP Address. The name needs to be less than 15 characters for NetBIOS purposes. Do that and click next to create the cluster.

Next, configure your iSCSI initiator, and use the quick connect option, specifying the IP of the DC. It should connect, and present the 2 disks. Do this on both of the Hyper-V hosts. Mark them both as online in Server Manager, make a volume on this disk as “Q:” (for Quorum).  Next, you need to add this as a clustered volume.

Open up Failover Cluster Manager, and navigate to the Storage->Disks section. Click “Add Disk” and choose the 5GB drive. Once that’s done we need to setup the Quorum witness. Right click on your cluster, choose “More Actions” then “Configure Cluster Quorum Settings”. Click Next, then choose “Select the Quorum Witness”, and click next again. Choose “Configure a Disk Witness” and click next. Choose the 5GB disk, and click next. At the confirmation screen, check over the settings, and click next, then click finish. You should see the disk as “Disk Witness in Quorum” like this:

Now we can add the 50GB disk as a cluster shared volume. Back in Server Manager, create a volume on the larger disk. I’ll be using V: for mine, as it’s for my VM’s. Go back to Failover Cluster Manager and choose “Add Disk” again. Choose the 50GB disk. Once that’s added, right click the disk and choose “Add to Cluster Shared Volumes”. This enables the disk for cluster use.

Enabling Live Migration… Still within Faillover Cluster Manager, choose the “Networks” node. Click “Live Migration Settings” and choose the LAN connection for Live Migration to use. I segregated this with my iSCSI traffic (by using a second network card purely for iSCSI) and wanted to make sure that Live Migration and iSCSI didn’t co-exist on the same LAN segment.

Next we need to add an external switch to each of the Hyper-V hosts. These need to have the same name. Open up Hyper-V Manager, and choose “Virtual Switch Manager”. Click to add a new virtual switch, and choose an external switch. Make sure you choose the NIC of the LAN NIC, and ensure you choose to “Allow management operating system to share this network adapter”. Click OK, and then click Yes to the warning. Complete the exact same actions on the second host, remembering to give them the exact same name.

That’s it! Cluster is built, Hyper-V is ready to run a VM…

Last piece of Part 2 then… removing the GUI from the Hyper-V hosts. This is something new to 2012 Server, and can be done via Powershell, or via the “Remove Roles and Features” wizard in Server Manager. Run through the wizard, selecting the host until you find the Features page. Uncheck “Graphical Management Tools and Infrastructure” and “Server Graphical Shell”. Removing just the latter will still give you a minimal graphical interface, with no Internet Explorer, or File Explorer amongst other items. Removing the first will put the server back to “Server Core” mode. NOTE: Removing the first will remove any additional RSAT tools you’ve installed (such as Hyper-V Manager and Failover Cluster Manager). It will NOT stop these items from working, just removes the consoles for local admin of those roles. It will also remove the Windows PowerShell ISE tool.

Over to part 3 for adding a VM and testing failover… and then part 4 will contain the installation for System Center 2012 R2… both coming soon!

NOTE: This post has been updated, please see the update near the bottom.

Hello out there!

This may seem like an odd post for my blog, considering I’m a VMware VCP, and this blog has had most posts written about VMware, but there’s going to be a lot more Hyper-V related posts coming… so watch this space!

As always, starting a lab is a long winded project. Machines need to be built, re-named, addressed, domains need to be created, members added and all of those server roles, apps and updates have to be installed and configured.

Well, this lab is going to have a lot going on… The overview here is that I’m taking a look at the Windows Server 2012 R2 technologies, based on the preview version available from Microsoft. Mostly this will be Hyper-V 2012 R2, mixed with System Center 2012 R2, Virtual Machine Manager and Operations Manager. I may, or may not for now, add the Windows Azure Pack, which is looking like a self-service portal, and part of Microsoft’s “Cloud OS” strategy.

So, here’s the overview of what’s going to be created:

1 x Windows Server 2012 R2 Preview Domain Controller also running the iSCSI target service.
2 x Windows Server 2012 R2 Preview Hyper-V hosts (eventually running Server Core mode).
1 x Windows Server 2012 R2 Preview host, running System Center 2012 R2 for Operations Manager and Virtual Machine Manager.

This will all be running from my Lenovo ThinkPad W530 laptop (16GB RAM, Intel i7 Quad core CPU and 250GB SSD)… with Windows 8, and the built in Hyper-V feature. If you don’t have that feature installed, it can be added using the features options under “Programs and Features” in the Control Panel. Just check the top level box, run the install and reboot a couple of times.

That’s the first, easy step done :)

Next, we need to download Windows Server 2012 R2 (just search for the preview download in your favourite engine). Sign up, and download the VHD copy with a GUI (to make life easier to start with). Once you’ve got that, extract it to a memorable location. Do the same for System Center 2012 R2 Preview.

Now we need to create a virtual switch… Open up Hyper-V manager, and click “Virtual Switch Manager”. Choose “Internal” and click “Create Virtual Switch”. Give your switch a name, and click OK. If you don’t know already, an internal switch won’t allow your VM’s to use the actual network. You’d need an “External” switch for that. Because I like to keep my lab environments separate, I chose an Internal switch.

In Hyper-V Manager, right click on your computer name. Create a new machine, with the spec you want (using the switch you just created) and using one of the VHD files for it’s first disk. Perform any global changes you want to make to all of your machines, for example, run Windows Update, change the admin password (it’s “R2Preview!” by the way), etc. etc.

Now, shut down the VM, and copy it’s VHD three times. Make 3 more VM’s via Hyper-V manager, each using a copy of the first VM’s disk. The 4 in total will make up the lab environment.

Once you’ve got your 4 machines, boot the first. This will be the 2012 domain controller. RUN SYSPREP! Make sure you choose the “generalize” option and reboot. Give it a decent name, and a static IP address. In the same way you do in Server 2012 R1, install AD Domain Services, DNS Server and the iSCSI target roles & features, go ahead and install the Hyper-V management tools at the same time. Configure AD at the end of the installer, and reboot as necessary.

Now, boot up your first Hyper-V host and run sysprep again. Give it a static IP address, and join it to the domain. Install the Hyper-V role, and reboot, DO NOT create a virtual switch. This will be setup for the child VM’s whilst we configure Hyper-V clustering. Do the same with your second Hyper-V host.

Lastly, perform the same actions with the last machine (ensure sysprep is run!), but power it off when it’s rebooted… it’ll be a while before we use this machine.

That’s the prep work done, you’ve a working AD environment, and two Hyper-V hosts. You’ve also prepared a system ready for the System Center 2012 R2 installation.

UPDATE: Seems I was pre-emptive in my plan here… you can’t run Hyper-V in a Hyper-V’d VM and get a VM to boot… so I’ve had to revert back to using VMware Workstation to create the first level of VM’s, which meant removing Hyper-V from my laptop. It’s a shame really, and something I hope Microsoft resolve in the future (maybe with Windows 8.1?), as creating this sort of lab environment is very common, and it would be nice not to have to run a 3rd party hypervisor on my laptop!

I’ll see you over at Part 2… (coming soon).

Hello again, it’s been a while, but this little nugget of information couldn’t wait, I want to keep it somewhere I can get to it quickly again!

Having performed many migrations between servers operating systems over the years, DHCP has always been a pain. When moving between differing versions of Windows, the backup/restore process doesn’t work, especially when you add in the change between x86 and x64. Well, there is an easier way which I’ve stumbled across today:

Install the DHCP Server role on the new 2012 Server, but don’t Authorize it.
On the Windows 2003 DHCP Server, open a command prompt and type: netsh dhcp server export C:\dhcp.txt all
Copy the file to the new 2012 Server.
On the new 2012 server, open a command prompt and type: netsh dhcp server import C:\dhcp.txt all
Open the DHCP console on the new server and authorize the server with Active Directory.
Stop the DHCP service on the old server, and disable it.

Now that’s much easier than manually re-creating a DHCP scope right?!

Apr 19

UPDATE: Checked with Exchange 2010, and this also resolves the issue.

Today I was dealing with a customer who was receiving errors in Outlook for autodiscover each time they opened Outlook. This was all after they’d changed their domain name.

I’d run a script I use to alter all of the host names, to check that they were all correct and then spent considerable time hunting around Exchange for this incorrect setting, and eventually found it.

It’s in the OutlookAnywhere settings, rather than in all of the other URL’s my other script alters. Usually, this URL doesn’t change, and so I’d missed it, but as they’d changed their domain name, this also needed alteration.

So, if you get SSL mismatch errors, and you think you’ve changed all of the necessary URL’s, check this one:

get-outlookanywhere | select Identity, ExternalHostName

if the External Host Name is incorrect, then adjust it with this:

get-outlookanywhere | set-outlookanywhere -externalhostname ""

This certainly works with Exchange 2007, I’ve not yet checked it on Exchange 2010, but believe it’s the same cmdlets.

I’ll write up a full blog post this weekend with a list of all of the places that need to be changed, so that it’s all in one place.

Apr 18

A short post today, just to find all MS Exchange certificates which have expired, filtered by domain name, and remove them from your exchange server. This should work with Microsoft Exchange 2007 and 2010.

$Domain = read-host "Enter Domain Name to Search for (e.g. webmail.domain.tld)"

Get-ExchangeCertificate | where {$_.NotAfter -lt (get-date) -and $_.Subject -like "*$Domain*"} | Remove-ExchangeCertificate -confirm: $false

I’ve had a need to reset password’s for accounts on an automated basis more so recently than before, so not knowing where to start, I took a look around the internet and found some pieces of code here and there that would start to fulfill my needs.

Basically, I was setting up an 802.11x authenticated wireless network, and had a requirement to automate the password change of a RADIUS authenticated Guest account that was sat in a locked down OU in the domain. This then needed to be random, secure and e-mailed to a public folder so that the employees could give their guests access to the guest network. The script just needs to be added to a scheduled task to run monthly. So I eventually ended up with this:

import-module activedirectory

[int] $len = 12
[string] $chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"
$bytes = new-object "System.Byte[]" $len
$rng = new-object System.Security.Cryptography.RNGCryptoServiceProvider
$result = ""
for( $i=0; $i -lt $len; $i++ )
$result += $chars[ $bytes[$i] % $chars.Length ] 

$securestring = ConvertTo-securestring $result -asplaintext -force

get-aduser "GuestUserName" | set-adaccountpassword -newpassword $securestring

$month= get-date -format MMMM

###Sets the mail values
$FromAddress = ""
$ToAddress = ""
$MessageSubject = "New Wireless Guest Details for $month"
$MessageBody = "Username: GuestUserName          Password: $result"
$SendingServer = ""

###Create the mail message and add the statistics text file as an attachment
$SMTPMessage = New-Object System.Net.Mail.MailMessage $FromAddress, $ToAddress, $MessageSubject, $MessageBody

###Send the message
$SMTPClient = New-Object System.Net.Mail.SMTPClient $SendingServer

In short:

Line 3: Specifies the number of characters in the generated password.
Line 4: The characters that can be used to generate the password.
Line 17: Reset’s the password on the AD account.
Line 19: Generates the month in long format to add to the e-mail Subject.
Line 22-26: Variables used for sending the e-mail.
Line 29: Generates the e-mail.
Lines 32 & 33: Sends the e-mail.

This morning I’ve been troubleshooting an Exchange public folder related issue that had me baffled for a little while.

Users could send e-mails to a public folder internally, but any external e-mails wouldn’t arrive in the folder. After running through message tracking I found the following error in the tracking logs:

550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange Information Store service reported an error. The following information should help identify the cause of this error: “MapiExceptionNotAuthorized:”…

Knowing that internal users could e-mail the public folder, and knowing that the e-mails were reaching the Exchange server meant that I had to be dealing with a permissions based issue. When I looked at the public folder’s MAPI permissions using Powershell (get-publicfolderclientpermission is the cmdlet for that one) I could see that the folder was set to “Anonymous: None”. This means that anonymous senders don’t have rights to create a new item in the public folder, and so the 550 5.2.0 message is logged.

To get around this issue, you need to add at least the “CreateItems” access right for the Anonymous user. You can do this within Outlook looking at the permissions, or, in PowerShell as follows:

add-publicfolderclientpermission -identity "\PathTo\PublicFolder" -accessright createitems

To check this afterwards you can perform the following script:

get-publicfolderclientpermission -identity "\PathTo\PublicFolder" | where {$_.User -match "Anonymous"} | fl

Having some sites recently migrating from older SBS platforms to the latest 2011 release I found a need for a script to alter the login script settings for all users.

Whilst these days I’m primarily setting login scripts via Group Policy Objects there’s still a need to clean-up and remove the login script path from the user objects in Active Directory.

All of the below scripts need you to run this either on your Domain Controller, or via a machine with the Remote Server Admin Tools (RSAT) installed.

This little 2 liner will remove the currently configured script path for all users:

import-module activedirectory
get-aduser -filter * | set-aduser -scriptpath $null

This one will remove it dependant on user name (which you’ll input within PowerShell):

$username = read-host
import-module activedirectory
get-aduser $username | set-aduser -scriptpath $null

Finally, if you want to change the login script path, you’ll need to replace $null on the last line as per this example:

$username = read-host
import-module activedirectory
get-aduser $username | set-aduser -scriptpath '\\ServerName\Netlogon\script.vbs'

%d bloggers like this: