Favoritevmguy

SRM Testing…What do I do with my Domain Controllers? Part 2

Posted on July 9, 2014 | 2 comments

Now that you have successfully prepared for the script…here it is. This script will power down the previous clone if there is one, delete the old clone, create a new clone, change the network, and then power on the clone. Please make sure you test this in first in a test environment before deploying to production.

######################################################################### Clone DC VM and set network to Test Bubble (clonedc.ps1)
#
# This script is used to clone a DC and then set the network port group # to the #Test Bubble group.
# The purpose of this script is to have a replica of our primary DC for # use #when testing an SRM failover. This will remove the previous clone # before #creating a new one.
#
# Created By: Matt Jones, 2014
#
# Variables: $newVMName – Name of the new clone made from the original VM
# $sourceVMName – Name of the target DC VM that will be cloned
# $VM — Name of VM that was cloned earlier
# $DestGroup — This is the port group that the network will be changed to.
#
# Usage: ./clonedc.ps1
#
#######################################################

add-pssnapin VMware.VimAutomation.Core
Connect-viserver (Your vCenter Server)

#Clone Script#
$newVMName = “DCClone”
$sourceVMName = “SourceDC”

Get-VM $newVMName | Stop-VM -Confirm:$false
Start-Sleep -s 5
Get-VM -Name $newVMName | Remove-VM -DeletePermanently -Confirm:$false
Start-Sleep -s 10
New-VM -Name $newVMName -VM $sourceVMName -Location Foldernamecreatedearlier -vmhost hostname
Start-Sleep -s 120

#Set Test Network#
$VM = get-vm “DCClone”
$DestGroup = “Test Bubble”
$VM | get-networkadapter | set-networkadapter -NetworkName $DestGroup -confirm:$false
Start-Sleep -s 30
$VM | Start-VM

taskkill /F /IM powershell.exe

#######################################################

Once you have created the clonedc.ps1 script we need to get it set up as a scheduled task on the physical machine. Log in using the script AD account that you created earlier, then go to Control Panel –> System and Security –> Administrative Tools –> Task Scheduler. Click Create Task.

Under the General Tab Name your new task, change this to Run whether user is logged on or not, and check the box Run with highest privileges. Click the Triggers tab

Click New and then choose the frequency that you would like this to run. Make sure to check the Stop task if it runs longer than box and then set it for 30 minutes. This makes sure that the script stops and doesn’t continually run. Make sure you check the Enabled box or the script won’t run automatically! Click the Actions Tab.

Click New and then from the drop down menu choose Start a program. In the Program/Script box type C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe and in the Add arguments (optional) box type -psc “C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\vim.psc1” -noe -c “. \”C:\scripts\clonedc.ps1\””. Click the Settings Tab.

If you want to allow this to run on demand then check the Allow task to be run on demand box. Check the Stop the task if it runs longer than box and choose 1 hour from the drop down. Check the box If the running task does not end when requested, force it to stop. Click OK. You will be prompted to enter the credentials for the account running the task and then click OK.

You might have to do a refresh for your new task to appear. I am guessing this might be a bug. Manually run your task and monitor the VIC to make sure it is working properly.

That should be it. Now you can run an SRM test fail over and have a DC available. Make sure that you have removed all of your DCs from SRM if you had them in there.

2 Comments

Posted in Uncategorized

SRM Testing…What do I do with my Domain Controllers? Part 1

Posted on July 8, 2014 | Leave a comment

For the most part I love SRM for providing a relatively simple way to back up and recover our VMware environment. The problem that I have with SRM is that when it comes to testing failover, what do you do with your domain controllers? According to VMware’s documentation found here, you should never use SRM to backup your domain controllers because you should already be using Active Directory replication to handle recovery situations.

When testing in the past I have added the DCs to my test recovery plan. The problem was that most of the time the cloned DCs (in a test bubble) took forever to come up, and because of this, testing would take way longer than it should. What is the solution?

The solution I have developed is to use scheduled powercli task that will clone my primary DC on a daily basis, change the network port group to a test bubble, and then power it on. Doing this gives me a domain controller in my test bubble that should be ready to use whenever I want to test SRM. I am still deciding whether or not I need to power down the primary DC first before cloning. For now, I am cloning live. I have a feeling I will hear from you guys on this one…:)

Preparation:

1. The first thing I have is an old physical desktop to run my scripts. You could run your scripts through a VM, however, I will be running my UPS Emergency shutdown script through this machine as well.

2. I created a service account in AD that has very specific rights within vCenter. Give this AD account admin rights on the physical machine that you will run your scripts from.

3. Install PowerCLI on the machine using the AD account you created earlier. Some good installation instructions can be found here. Make sure that your set the execution policy to remotesigned. While you still have PowerCLI open, add the credentials of the AD account to the PowerCLI credential store. Information on this can be found here. In our example in PowerCLI you would type New-VICredentialStoreItem -Host <vcenter server name/ip> -User <AD Script Account> -Password <Password for the script account>. This will store the credentials within the user profile directory and it is encrypted! This way there is no username and password in clear text going over the wire. Note that if you try to test the script right now it will not work because there are no rights for the account in vCenter.

4. I am going to be good and use the Web VIC to configure the permissions, sometimes I feel like this though…

Now that I have gotten that out of my system, log into the Web VIC as an administrator and click Administration –> Roles. Click to create a new role. Name this role something like “clone” or cloneandchangenetwork”. Check the following boxes:

Datastore –> Allocate Space
Network –> Assign Network
Network –> Configure
Resource –> Assign Virtual Machine to Resource Pool
Virtual Machine –> Configuration –> Add New Disk
Virtual Machine –> Configuration –> Add or Remove Device
Virtual Machine –> Configuration –> Modify Device Settings
Virtual Machine –> Interaction –> Power On
Virtual Machine –> Interaction –> Power Off
Virtual Machine –> Inventory –> Create from existing
Virtual Machine –> Inventory –> Create New
Virtual Machine –> Inventory –> Register
Virtual Machine –> Inventory –> Remove
Virtual Machine –> Provisioning –> Clone Virtual Machine

Now that our role was created, we need to assign it to the locations that we want this role to have rights. To keep this simple, but not very secure, you could assign the role to the vCenter Server level. The rights will propagate down the entire tree across any datacenters that you might set up. Most people don’t want this because it would allow the cloning of any server, so we are going to assign rights exactly where they need to go. But first we need to create a new folder where our cloned VM will eventually live.

Folder Rights
Click Home –> VMs and Templates. Using the arrows, expand the list on the left pane. Right click Discovered virtual machine –> New Folder and then name your new folder something like DCClone. Click Manage –> Permissions. Click and then from the drop down menu select the role that you created earlier and then click Add. Choose your domain from the Domain drop down and then find the user that we created earlier in the list. Click OK. You should now see the AD user and the assigned role. Now uncheck the Propagate to children box and then Click OK.

Cluster Rights
Click Home –> Hosts and Clusters. Then click on the Cluster where the DC resides that you will be cloning. Click Manage –> Permissions. Click and then from the drop down menu select the role that you created earlier and then click Add. Choose your domain from the Domain drop down and then find the user that we created earlier in the list. Click OK. You should now see the AD user and the assigned role. Now uncheck the Propagate to children box and then Click OK. This keeps the script account from having rights down the tree.

DC Rights
Click Home –> Hosts and Clusters. Then click on the DC that needs to be cloned. Click Manage –> Permissions. Click and then from the drop down menu select the role that you created earlier and then click Add. Choose your domain from the Domain drop down and then find the user that we created earlier in the list. Click OK. You should now see the AD user and the assigned role. Click OK.

Datastore Rights
Now we need to set the role for the host that will house the cloned VM. Click Home –> Storage, and then on the left hand side click the datastore that the will be home to the clone. Click the Manage –> Permissions. Click and then from the drop down menu select the role that you created earlier and then click Add. Choose your domain from the Domain drop down and then find the user that we created earlier in the list. Click OK. You should now see the AD user and the assigned role. Click OK.

Host Rights
Now we need to set the role for the host that we are going to clone to. Click the Home –> Hosts and Clusters, and then on the left hand pane click the host that the will be home to the clone. Click the Manage –> Permissions. Click and then from the drop down menu select the role that you created earlier and then click Add. Choose your domain from the Domain drop down and then find the user that we created earlier in the list. Click OK. You should now see the AD user and the assigned role. Now uncheck the Propagate to children box and then Click OK. This keeps the script account from having rights down the host.

Network Rights
Finally, we are going to set the role for the network. Click Home –> Networking. On the left pane select the test network that you have in your environment. Mine is called Test Bubble. Click the Manage –> Permissions. Click and then from the drop down menu select the role that you created earlier and then click Add. Choose your domain from the Domain drop down and then find the user that we created earlier in the list. Click OK. You should now see the AD user and the assigned role. Click OK.

By the time you are done, your script service account should have rights in vCenter for the Cluster (no propagate), host where the clone will live (no propagate), the Datastore, Network, Folder, and DC that will be cloned.

WAY TO GO!! Are you ready for part 2?

No more free phone with Google Voice and Obi…but there is a solution!

Posted on May 6, 2014 | 15 comments

**UPDATE**

Interesting Email from Obihai:

The Google Voice Service is Still Working on My OBi! How come?

At the end of last year, Google Inc. announced that the open and documented XMPP communication protocol would be abandoned in favor of a new, proprietary way to do real-time voice, video and instant messaging communications. The time-line for the migration to this new way was not stated. At about the same time, but separately, Google stated third-party applications should stop supporting XMPP by May 15^th 2014. Now that this date has passed, like you, we have observed Google services using XMPP are still connected and working, e.g. you can still place and receive calls using a Gmail account configured on your Obi device. It is important to note, this does not change the previous statements from Obihai that we no longer support direct connections to Google Voice on OBi devices. We strongly recommend all OBi owners using the Google Voice service obtain a new service to ensure continued, uninterrupted calling from the phone connected to the OBi. Fortunately, there are several OBiTALK Approved Service Provider (ASP) choices available to all OBi device owners for Internet VoIP phone services. These services are easy to sign-up for and configure automatically on an OBi device. They also come at a great price – with all fees and taxes included.

**END UPDATE**

This post will deviate from my normal VMware posts, but I think there are many that this might help.

I have been using Google Voice with my Obi 100 for about a year now. Aside from the E911 service through Anveo.com I pay nothing for my home phone service. The E911 only cost me something like $12 for the year. Everything was going fine until the announcement that Google Voice would no longer work with Obi because Google was eliminating XMPP Support. I don’t have the details of why this won’t work anymore, I just know it wont. If you want details about XMPP, read about it here.

The question that Obi users face is, “What do I do now?”. The good news is that there is a pretty good list of alternative providers, but the bad news is that they are not free. It would seem like the best time to get into a contract is right now though because many of the providers are offering cheaper plans until 5/14/2014 at which time the XMPP ends. The plan I am going for is 2 years for $50 which gets me 500 minutes per month along with E911. This comes to just over $2 a month for phone service!

The provider that I decided on is called Vestalink. I don’t want to port my number out of Google Voice, so after the nifty Vestalink video I will show you how I accomplished this.

**Please use my links for signing up for Vestalink as I can earn a referral; note that I am NOT paid or sponsored by Vestalink** First go to here and sign up for a free 30 day or 60 minutes of talk time trial. You don’t have much time though if you are going to get one of the deals before 5/14/2014.Click the Sign Up Free link.

Enter the appropriate information for your internet details as well as your login details. Click Continue.

Enter the Zip code closest to where you would like your number. This pulls up a list of cities nearby. Click the one you are interested in and then click Continue. Make sure you note your new phone number…we will need it later

Enter your address for E911. This is important so please make sure the information is correct. Click Continue.

Now to select your device. I had the Obi, so I clicked on the “Bring your own device / Softphone / Smartphone / Tablet / OBi Adapter – Click Here” link. To continue you then have to click on Click Here.

The last thing to do is to verify the information is all correct. You must check the consent box and then enter a phone number that they can verify that you really want to sign up. The phone number cannot be a VOIP number.

If it didn’t take you into the Vestalink Dashboard, then go to www.vestalink.com and then click Login. Enter your email and password and then login.

We need to get Vestalink talking to your OBi device. Click Devices and then Click Softphone/BYOD. You need the IP address of your OBi and you can get this by following the directions here or by logging into your router and finding the IP from the DHCP list. My guess is that if you are here setting this up, then you probably should be able to find this information. Enter the IP address and then click Send Configuration. You might be asked for the OBi password and which by default is admin/admin. Your OBi device is magically configured for use with Vestalink.

Time to forward my Google Voice number to my new Vestalink number. Go to Google Voice and click the little settings gear at the top right and then click Settings. On the Settings page under the Phones tab click the Add another phone link at the bottom of the page. Type a new name…I used OBi and then put the Versalink phone number that your wrote down earlier…right…:) Click Save. Google will require that you verify the number by Google Voice calling the number and requiring that you enter a 2 digit code. After verifying the forwarding number go back to the Vestalink Dashboard.

We need to Spoof our Google Voice number when we call out, so instead of using the new Versalink number on the caller ID of who you are calling…it will look like your old Google Voice. Click on Numbers and then click Spoof Caller ID. Put your Google Voice number in the “Set to” box and then click the Verify Ownership box. Versalink will call your Google Voice number now and ask you to enter a code.

That is is…when someone calls your Google Voice number it will forward it to your new Vestalink number (and now you have caller ID). When you make a new call out it will use the new Vestalink number, however the number will be spoofed with your old Google Voice number; so it looks like you are calling with Google Voice but you are not.

15 Comments

Posted in Google Voice, OBi, Off Topic

Tagged Google Voice, OBi, Phones, Vestalink

Enable Copy and Paste Through the VMware Console

Posted on April 22, 2014 | 3 comments

I was setting up a new host the other day and I received a call from one of my admins letting me know that they could not copy/paste within the console; but they can copy/paste in RDP.

This is a simple fix found in KB1026437. You can make the change on an individual VM, but I think it is best to change it on the host (which applies to all VMs). I really wish the default would have this enabled.

Open a Putty session…if you don’t have putty then get it here.

1. Log into the ESXi host that you want to change.
2. Type vi /etc/vmware/config
3. Arrow down to the last line and type i which stands for “insert”.
4. Add the lines:
vmx.fullpath = “/bin/vmx”
isolation.tools.copy.disable=”FALSE”
isolation.tools.paste.disable=”FALSE”
5. Press the ESC key and then type :wq which stands for “write and quit”.

The next time each VM is power cycled it will enable the copy/paste functionality. Keep in mind that if you ever upgrade this host to a new ESXi version that this setting will go back to the default of disabled and you will have to add this line again.

3 Comments

Posted in Configuration Changes, VMware Vcenter Server, VMware Vsphere 4, VMware Vsphere 5

Tagged Copy/Paste, VI, vSphere 5, vSphere 5.1

Deploying VMware Support Assistant v5.5

Posted on April 7, 2014 | Leave a comment

The other day I set up and configured VMware’s new Support Assistant 5.5. I have used older versions to do things like open tickets and pull log files, but the new version has proactive support built in. You configure when you want your log files sent to VMware and they compare them to know issues. VMware even includes the ability to scrub the files before sending them out.

Here is how to deploy.

Download the .OVA from www.myvmware.com. I am using build 1549662.
Open up your VIC.
Click File and then Deploy OVF Template.
Select the OVA that you downloaded and click Open.
1. Click Next on the Source Location window and then Next again on the details screen.
2. Click Accept and then Next.
3. Name your new support appliance and choose a folder if applicable then click Next.
4. Select the host that the appliance will run on and then click Next.
5. If applicable, choose a resource pool for this appliance and then click Next.
6. Choose the Destination Network and then click Next.
7. Enter in the Gateway, DNS, IP, and Subnet Mask and then click Next.
8. On the Ready to Complete screen check the Power on after deployment box and then click Finish.
9. You should see a progress bar indicating the status of the deployment.
Open a console screen and you should see the appliance boot and eventually tell you to browse to the appliance IP to finish configuring. Open up a browser and go to that address.
Accept the EULA…actually relatively short. Click Next.
The lookup service address is the SSO server. Enter your SSO server and then click Next.
Enter your SSO credentials which will usually be either admin@System-Domain if you installed SSO in 5.1 or administrator@vsphere.local if you upgraded from 5.1 to 5.5. Click Finish.
Add an account that has rights to vCenter and then check the box to Assign log collection permissions for the following vCenter Server instances. Click Next.
Enter your proxy information if needed. This allows the appliance to talk with VMware and send the log files. Click the Test Connectivity button to ensure things are working properly and then click Next.
Add an email address to receive update about your environment then click Finish.
Hopefully you see that the Service is ready…log gathering is disabled though. We will fix that in just a minute, but first let’s not forget to change the root password. Click VA Settings. You will see a place to put in the current password and then a new password. This is for the root account. The default password is vmare and make it something that you will remember. Click Save.
The Support Assistant only works in the new Web VIC. Open a browser and navigate to your vCenter server and login.
You should see a new icon now that looks like a life preserver called vCenter Support Assistant. Double click the icon.
Click the link Configure data collection.
Here you can change when your appliance will upload logs to VMware for analysis. The default is never, but that won’t help us! In the example mine will upload every Monday at 10AM. Click Entity Selection.
Select the vCenter servers (linked mode supported) and hosts that you want logs from that will be sent to VMware. Click Data Scrubbing.
This is great that VMware includes the ability to scrub the log files. Note that if you check these boxes, it will have an effect on the virtual appliance as it looks through and redacts the log files before sending to VMware. Check the boxes that you require and then click OK.
Click the Monitor tab. This tab shows the status of your support uploads. Click the Manage tab.
This gives a summary of your proactive support settings, which you just changed. Click the Support Requests button.
After logging in with your Myvmware.com username and password, you can check the status of open and closed tickets and upload logs if needed.

Proliant DL380 embedded NICs missing after firmware update

Posted on March 26, 2014 | 5 comments

I ran into a very strange issue today when I went to redeploy an old Proliant DL380 G5. The first thing I did was use the most current service pack DVD to update the firmware. The most current is from 2/2014 and has the number 2013.02.0. After installing ESXi 5.1 U1 I noticed that I was only showing 4 NICs and not the 6 I started with.

The two embedded NICs were missing!!

After a quick google search or twelve I stumbled upon an HP discussion with exactly the same problem that I was having. I followed the instructions from the HP discussion and here is what it took to fix (Most of this is copied from user hase3d’s post).

1. Download all necessary tools
– download FreeDOS
– download XDIAG.exe
– download bc08c740.bin
– read all information in setup.txt

2. Prepare the FreeDOS.iso
-After downloading open the iso with a tool like UltraISO. I used Magic ISO.
-Add the XDIAG.exe and the bc08c740.bin to the iso – I these files to the root so that I wouldn’t need to add a path later.
-Save the iso with a new name.
-Burn it or mount it with ilo.

3. Boot from FreeDOS
-Select Install to harddisk
-Press 1
-Select your language and press Enter
-Press ESC
-Select run FreeDOS from CD-ROM

4. Mine booted to f:\freedos. Do a cd\ to get back to the root of f:
5. Run xdiag in engineering mode by typing xdiag -b06eng
6. type device 1
7. nvm fill 0 0x600 0
8. nvm upgrade -bc bc08c740.bin
9. nvm cfg
-Press q
-Type default
-Press q again
-Type 16=10 wich sets the BAR size to 32
-Press q for the third time
-Type save and then exit out to the main menu

10. Type device 2 and repeat steps 7-9, run the command 1=00:00:18:xx:xx:xx <— change the last digit for different mac on device 2.

I did not do anything else from the setup.txt file.

I powered down the host and then when I rebooted I had 6 NICs again!

5 Comments

Posted in VMware Vsphere 5

Tagged HP, NICS, Proliant DL380 G5, vSphere 5.1

The authentication server returned an unexpected error

Posted on March 12, 2014 | Leave a comment

I came in this morning only to be greeted by my web client telling me that I can’t login because it can’t create SAML 2.0. I am not sure that I really want it creating SAML 2.0….I don’t know SAML 1.0. Ok, bad joke. Here was the message…

I found KB2034798 at which point I remoted into my SSO server and checked the imsTrace.log for “NetUserGetLocalGroups”. I didn’t find it…so the KB didn’t apply to me…L

After some more googling I found this blog post that indicated that references KB2043070. The idea is that there is a local identity source within SSO that it is trying to authenticate the users to. You have to login with the admin@system-domain account and password. Hopefully you saved this when setting up your SSO server. The only problem I had was that I didn’t have this local identity source to remove.

I thought to myself, that there might be a stale identity source on the list that it is authenticating to. I was talking to a coworker and they mentioned that there was a domain that was deleted the day before. AHAH!! I clicked on the identity source of the domain that had been removed and then clicked “Test Connection”. There was an error that didn’t tell me much.

I cancelled out and was back at my list of identity sources. I selected the identity source that had been removed from AD and I hit the red X, “Delete Identity Source”. You will get a prompt asking for you to confirm. One thing to note is that the identity source that I deleted was not one of the default domains at the bottom. If you haven’t set a default domain up, I would do that now. I am wondering if there might be a bug that uses the identity source at the top of the list instead of the default at the bottom. After deleting the state Identity Source I was able to login again.

vSphere HA detected that host is in a different network partition than the master

Posted on February 17, 2014 | 16 comments

Target: Host
Previous Status: Green
New Status: Red
Alarm Definition:
([Event alarm expression: vSphere HA agent on a host has an error; Status = Red] OR [Event alarm expression: vSphere HA detected a network isolated host; Status = Red] OR [Event alarm expression: vSphere HA detected a network-partitioned host; Status = Red] OR [Event alarm expression: vSphere HA detected a host failure; Status = Red] OR [Event alarm expression: Host has no port groups enabled for vSphere HA; Status = Red] OR [Event alarm expression: vSphere HA agent is healthy; Status = Green])
Event details:
vSphere HA detected that host (host) is in a different network partition than the master (Cluster) in Datacenter

I had been getting this message randomly over the last couple months on some of my datacenter hosts. These alerts didn’t seem to be causing any problems within the cluster, but I wanted to get to the bottom of this. I opened a ticket with VMware and uploaded the logs from both the host and vCenter, but they didn’t see anything out of the ordinary. On the second webex with VMware I noticed a couple strange things with the management network that might be the cause.

The first thing I noticed was that the NICs were set for “Auto Negotiate”. I originally set up our environment on ESXi 4 before upgrading to ESXi 5.1. When I initially set this up I hard coded (KB1004089) these to 1000GB/Full. I am wondering if at some point during the upgraded that they defaulted back. On our switches it was set at 1000GB/Full so it is important that we set this on the host NICs to 1000GB/Full as well.
The second thing that I noticed that in the Management network that I had the Load Balancing set to “Route based on IP hash”. The problem here is that for this to work correctly you need a port channel configured (I do not have this configured this way). This might be the cause of the HA problem if the traffic is going across these NICs is getting confused because of the Load Balancing configuration. I changed this to “Route based on the originating virtual port ID”, which makes the traffic go out on the port that it came in on. There is a good read found here…http://blogs.vmware.com/kb/2013/03/troubleshooting-network-teaming-problems-with-ip-hash.html.

This case is still ongoing with VMware and I should know in the next couple weeks if this solves my problem; my gut tells me it will.

16 Comments

Posted in Configuration Changes, VMware Vcenter Server, VMware Vsphere 5

Tagged HA, NICS, Teaming, VMware Vcenter Server, vSphere 5.1

Creating a template for Server 2012 R2 – Part 2

Posted on February 12, 2014 | 13 comments

Now that our VM is created, we will install VMware Tools, upgrade the Hardware Version, and make some helpful Windows changes. If you are going to use the BGinfo program, please make sure you go and download that.

Finishing VMware Changes and Configuring the OS

First thing we need to do is upgrade the VMware Tools on the machine. This will install critical drivers for both Network and Video and will make for a better all-around experience. Select your VM and then click “Guest” and then “Install/Upgrade VMware Tools”.
Click “OK” on the window that comes up.
Go back to your console screen for the VM and you should see the D: drive change to “VMware Tools”. Double click this to start the install.
Click “Next” on the tools welcome screen.
I used to do a custom install and removed the shared folders, but from all my reading I don’t think this is needed anymore. Choose the “Typical” radio button and then click “Next”.
To continue with the install click “Install”.
Click “Finish”.
Click “No” when it asks for you to reboot.
Instead we are going to Shut the VM down so that we can update the hardware. Select your VM in VMware then choose “VM” from the menu bar then “Power” and then “Shut Down Guest”.
Once the VM is shut down, right click on it in vCenter Server and then choose “Upgrade Virtual Hardware”. The hardware version for the server will change to 9.
Right click on the VM again and this time click on “Edit Settings”.
Click the CD/DVD drive 1 and change the Device Type to “Client Device”.
Click on the Floppy drive 1 and then click “Remove”.
Click the “Options” tab and then click “Boot Options” check the box for “Force BIOS Setup”. Click “OK”.
Power on the VM again using the “Power On” button.
Arrow down to “Legacy Diskette A:” and hit the + key until is says “disabled”.
Arrow to the right so that “Advanced” is highlighted. Then arrow down 4 times until “I/O Device Configuration” is highlighted and then press “Enter”. Go down the list changing “Serial port A:, Serial port B:, Parallel port:, and Floppy disk controller to “Disabled”.
Press “ESC” twice and then press “Enter” to Exit Saving Changes. Press “Enter” again when it asks for confirmation.
Logon using your administrator password that you created in part 1.
I like to get the time right on the server before I do anything else. Do this by right clicking the time in the lower right corner and choose “Adjust date/time”. Click the “Change time zone” button. Make the appropriate change for your location and then click “OK”, and then “OK” again.
The first thing I like to do is to rename the server and add it to the domain if needed (I try to not add it to the domain if I don’t have to). The Server Manager should open automatically for you. Click “Local Server” on the left side and then click the “Computer Name” Change the name, but you won’t be able to add it to the domain yet because it has not been IPed.
Right click on the Network icon in the task bar and choose “Open Network and Sharing Center”.
Click “Change adapter settings”.
Click “Properties”.
The default lists the following items.
Click “QoS Packet Scheduler” and then click “Uninstall”. Do the same for both “Link-Layer Topology” items. QoS Packet Scheduler is not needed unless you are doing QoS at the Windows layer instead of the L2/L3 switch layer. Please read about Link Layer Topology here and determine if you want/need it in your environment – http://en.wikipedia.org/wiki/Link_Layer_Topology_Discovery
Finally, uncheck “Internet Protocol Version 6 (TCP/IPv6). WARNING – DO NOT uninstall IPv6 as this might cause problems.
The first thing we are going to do with Server Manager is to change its behavior on startup. Open up Server Manager if it is not already done. Click “Manage” and then click “Server Manager Properties”.
Check the “Do not start Server Manager automatically at logon”.
In Server Manager click on the “Internet Explorer Enhanced Security Configuration” and set both Administrators and Users to “Off”.
Now we are going to add some important items to the desktop. From the main Server Manager Dashboard page click “Add roles and features”. Click “Next” on the Before you begin page, leave the radio button on “Role-based or feature based installation” and click “Next.
On the Server Selection screen leave everything default and then click “Next”. Click “Next” again to bypass the Server Roles and move to “Features”.
Expand both .NET Framework 3.5 and 4.5 and then check to have both installed.
Next click the check box for “User Interface and Infrastructure”. This is going to allow us to add some missing desktop icons. Click “Add Features” when the required features window comes up.
We use SNMP for server monitoring so I check the box for “SNMP Service” and then click “Add Features” when the required features window comes up, then click “Install”.
Right click on your desktop background and click “Personalize”. Click the “Change desktop icons” link and then check the boxes for “Computer, Recycle Bin, and Control Panel”.
Right click on the Desktop again, and under “View”, set icon size to “Small”, and set Auto Arrange and Sort By options according to your preference.
Right click the task bar and click “Properties”.
Check the box “Use small taskbar buttons”.
Click on the “Navigation” tab and then check the box “When I sign in or close all apps on a screen, go to the desktop instead of Start”. I also check the boxes “Show the Apps view automatically when I go to Start” and “Search everywhere instead of just my apps when I search from the Apps view”.
Create a new folder on C: called BGInfo. Place all your BGinfo files into this folder. Edit the BGInfo.bgi file if you want to customize the BGinfo settings. Create a .bat file called bginfolaunch.bat in the BGinfo folder. I have included what I have in my batch file.
Right click on the start button and choose “Run”. Then type Regedit in the open box.
Adding the following entry into the registry will cause BGInfo to automatically refresh BGInfo every time you log onto the server. Add a reg key (string value) called BGInfo with the value of C:\BGInfo\bginfolaunch to HKLM\Software\Microsoft\Windows\CurrentVersion\Run.
Right click on the start button again and this time choose “Control Panel”. Change the view to “Small Icons”. Click on “Power Options”.
Change the power settings to “High performance”. And then click “Change plan settings”. Set both “Turn off the display” and “Put the computer to sleep” to “Never”.
Right click on the Powershell icon and the select “Run as Administrator”. Type powercfg –h off and press “Enter”.
Click “File Explorer” on the task bar. Click “View” then “Options” and then “Change folder and search options”
Check “Display the full path in the title bar area” and click the radio button for “Show hidden files, folders, and drives”. Uncheck “Hide protected operating system files”.
Right click the start button and click “Run”. Type gpedit.msc in the run box. When the group policy window comes up go to Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options. Set “User Account Control: Run all administrators in Admin Approval Mode” to disabled.
Then change “User Account Control: Behavior of the elevation prompt for administrators” to Elevate without prompting.
The final thing is to include Logoff and Disk Manager Icons on the desktop. Create them and place them in C:\Users\Public\Desktop.

13 Comments

Posted in Server 2012, Templates, VMs, VMware Vsphere 5, Windows Server, Windows Server 2012 R2

Tagged Server 2012, Server 2012 R2, Templates

Creating a template for Server 2012 R2 – Part 1

Posted on February 7, 2014 | 5 comments

I have borrowed items from http://www.boche.net/blog/index.php/2012/08/16/microsoft-windows-server-2012-tips/ to create this post. I encourage you to take a moment to check out that post.

This is the step by step document that I used to build my 2012 and 2012 R2 VMs.

VM values will start at:

Hardware:	Value:
Memory	4 GB
CPU’s	1
Video card	Auto-detect video settings
VMCI device	None
SCSI Controller 0	VMware Paravirtual
Hard disk 1	40 GB, Thin
CD/DVD Drive 1	Client Device
Floppy Drive 1	Removed (when done)
Network Adapter 1	VMXNET3
General Options	OS: Microsoft Windows Server 2012 and 2012 R2
VMware Tools	Default Settings
Virtual Machine Version	9

Creating the VM

In vCenter click “File” then “New” then “Virtual Machine”
Choose the “Custom” radio button and then “Next”.
Name the SM and choose the folder location.
Choose the datastore for the VM and then click “Next”.
Make sure that the “Virtual Machine Version: 8” radio button is selected. (5.1 is using version 9 so I am not sure why this can’t be selected here. We will change this later.
Select the “Windows” radio button and then choose “Microsoft Windows Server 2012 (64-bit).
Take the default of 1 virtual socket and 1 core per virtual socket.
Take the default of 4GB memory and click “Next”
Choose your Network and change the adapter to “VMXNET 3” then click “Next”.
Change the SCSI controller to “VMware Paravirtual” and then click “Next”.
Select the “Create new virtual disk” radio button and then “Next”.
Take the default of 40GB and click “Next”.
Take the default virtual device node. For the system partition you want this to be SCSI 0:0. Click “Next”.
On the summary screen click the “Edit the virtual machine settings before completion” box and then click “Continue”.
Click on the Video Card and then change the radio button to “Auto-detect settings”.
Click on the CD/DVD and then choose the datastore location that you have the 2012 R2 install ISO. Make sure under Device Status that “Connect at power on” is checked. Now click “Finish”.
Right click on your newly created VM and click “Edit Settings”.
Click on the Floppy drive 1 and choose the “Use existing floppy image in datastore” radio button. Then click “Browse”. At the bottom of the datastores you should see a folder called “vmimages”. Double click this folder. (For some reason until the VM is created this folder does not show up and that is why we had to create the VM and then go back into the settings to change this).
Double click on the “floppies” folder.
Choose the “pvscsi-Windows2008.flp” and then “OK”.
The Floppy drive 1 settings should look like this and then click “OK”.
On the list of VMs click the one you are building and then click the “Power On” button.
Now click the “Open Console” button.
The VM should boot into the 2012 R2 setup screen. Choose your language and then “Next”.
Click “Install”.
Choose the version of server that you are using. We use the Datacenter here. Then click “Next”.
Agree to give up your first born to Microsoft by clicking the “I accept the license terms” box and then click “Next”.
Choose “Custom: Install Windows only (advanced).
Uh oh, there is no location to install Windows. Luckily you configured the floppy drive 1 earlier right? Click the “Load Driver” button.
Click “Browse”.
Look for the Floppy Disk Drive and then double click “amd64”.
Select the “VMware PVSCSI Controller (A:\amd64\pvscsi.inf) and click “Next”.
Hey look there is our drive!! Click “Next”.
Windows should now be installing.
Enter a password for your admin account. Do not lose this password!
You should have the login screen now.