After P2V (VMware), VM loses its Default Gateway Address

I ran into this issue this morning. Yesterday I P2V'd a Windows 7 "server" (don't get me started) that synchronizes nightly with a remote server over the internet. The P2V was successful, and the application passed inspection by the department that used it.

This morning we found out that the server did not synchronize. The first thing I did was run an ipconfig, which revealed that there was no default gateway set! I KNOW I set that. I also know that I've seen this issue before, and it has to do with two different network adapters having the same default gateway setting.

There are two things you need to do to fix this issue, but both are pretty easy. You can do it while the server is running if you are careful not to delete the wrong network adapter.

The first thing you need to do:

1. Open an administrative command prompt
2. type: set devmgr_show_nonpresent_devices=1
3. In the same command prompt window, type: devmgmt.msc
4. Now, in the device manager window that just opened, click View-> Show Hidden Devices
5. Under the Network Adapters branch, you should see a "greyed out" adapter. This is the inactive adapter.
6. Right click on the inactive adapter and choose uninstall. I left the drivers behind.

** NOTE **: It seems like this is also a great way to see if a system you are working on was P2V'd at some point. I also notice other now-disconnected hardware, like the old physical video adapter, when I'm in this view.

The second thing you need to do:

1. Open Regedit
2. Navigate to HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces
3. Underneath that branch, you should see at least one long CLSID that looks like this {542A742-AF234.....}
4. Click on that, and you should recognize the settings - it's your active network adapter. If you had more than one CLSID, click between the different CLSIDs to find the one with the IPAddress that corresponds to your main adapter.
5. Write down what your default gateway is, if you don't know it by heart. 
6. Right-click on the "DefaultGateway" item and click modify.
7. Select all of the text in the large "Value Data" field and delete it, then carefully type in your default gateway and click the OK button.

The reason behind step two is that sometimes an invisible line return character gets added to the value, either in front or behind, and that can make the setting misbehave on reboot.

Report on Group Membership for Sensitive Groups

Here's another script I have that runs weekly, and gives me a run-down on accounts that have membership to sensitive groups in Active Directory. I used Quest's Activeroles Powershell plugin for this. Quest is now owned by Dell, and you can find the plugin here.

I recommend that you run this to identify accounts that may have more access than you'd prefer. If you just add someone to a group temporarily, this can help save you from forgetting that they're a member (long term).

This covers #20 in my list of scheduled reports. Which I highly suggest that you check out...

#-------------------BEGIN SCRIPT---------------------------

#Add the snapin
add-pssnapin Quest.ActiveRoles.ADManagement

Specify a temp file
$TempFile = "c:\temp\GroupAudit.txt"

#Here we list the groups that we'd like to display members for
$Groups = `
"DOMAIN\Administrators",
"DOMAIN\DnsAdmins",
"DOMAIN\Domain Admins",
"DOMAIN\Enterprise Admins",
"DOMAIN\Exchange Admins",
"DOMAIN\Schema Admins"

#For each group, add a header, then output the members of the group. Pipe everything to the temp file
Foreach ($Group in $Groups){
$Header = "`r`nThe current members of the $group group are:"
$Header | Add-Content $TempFile
get-qadgroup $Group | get-qadgroupmember | add-content $TempFile
} #End Foreach

#Get the content of the temp file to form the body of the email
$body = (get-content $TempFile | out-string)

#Specify Email variables
$From = "helpdesk@DOMAIN.org"
$Subject = "PS Report - Sensitive AD Group Memberships"
$To = "me@DOMAIN.org"
$SMTPServer = "smtpserver.DOMAIN.org

#Send the email
Send-MailMessage -To $To -Subject $Subject -Body $body -From $From -SmtpServer $SMTPServer

#Delete the temp file
Remove-Item $TempFile

#-------------------END SCRIPT---------------------------

I Love You, Chrome, but these processes have to die....

I was sitting around in my living room looking at random wireshark captures (What does telnet look like? How about a DNS query?) and I'm trying to reduce the background network "noise" as much as possible. I have no apps running on my taskbar and killed some background fluff that was running, and then I see Hangouts running in my system tray. A right-click reveals no way to exit. I open task manager to find 30 chrome.exe. Well, maybe not thirty, but more than 10. I have quite a few extensions.....

I know WHY it's like this. Separate processes are more easily secured. It's a sandbox thing. What I don't like is that there's not a better description, like "Master Chrome Process" so I can kill one and it will take down all of the child processes with it. I'm not entirely sure that "child processes" is accurate.

There's a lot about this that I don't know, and don't really care about at this point in time. All I want is for Chrome to stop chattering and mucking up my Wireshark capture. I ran a search to see if there was a way to kill all of these processes in some sane fashion, but then I thought, why am I doing this? I can write a script to kill all of these in less time than it would take me to scour the results for a workable process that may or may not exist. Pffft - one liner time:

#Kill-Chrome.ps1
#This script kills all processes named chrome*
#Do not pass go. Do not collect more marketing data.
get-process | where {$_.name -like "chrome*"} | %{stop-process -id $_.id}

Monthly WSUS Database ReIndexing - The Automated Way

A buddy of mine clued me in on this post that recommends re-indexing the WSUS database every month. Sounds like a good candidate for automation to me....

First off, the environment I'm operating under runs WSUS 3.0 SP2 on a Windows Server 2008 R2 64-bit box that is fully patched. WSUS utilizes the Windows Internal Database, and not a full blown SQL database.

The first thing you'll need is "sqlcmd". I tried just copying sqlcmd.exe from one of my SQL servers, but that didn't turn out so well. I was worried that I was going to have to install all of SSMS on my WSUS server, which wouldn't be horrible, but I like to keep things tidy and this seemed like overkill. Some research led me to this download page for the SQL 2005 Feature Pack.

• Download the Microsoft SQL Server Native Client from that download page (skip the red "Download" button at the top for ala carte offerings below; more rejoicing).
• Scroll down farther and also grab the appropriate Microsoft SQL Server 2005 Command Line Query Utility.
• On your WSUS server, install the Native Client, and then install the Command Line Query Utility. In my case, sqlcmd.exe was created in C:\Program Files\Microsoft SQL Server\90\Tools\binn.
• Now, copy the WSUSDBMaintenance.sql script on Technet to a folder (I'll use C:\PS).
• Create a new batch file in C:\PS containing the following:

c:
cd "C:\Program Files\Microsoft SQL Server\90\Tools\binn"

sqlcmd -I -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query -i C:\PS\WsusDBMaintenance.sql

• Finally, schedule the task on the WSUS server so it runs once a month. I picked the last Sunday.

If you're familiar with the blog, you may wonder why I'm not using a Powershell script. :)
The answer is because this is the easiest way to implement this tiny operation. Why fool around with Invoke-Expression when a batch file works just fine?

When I ran this for the first time, I assumed it would take a long time, since I'd never done it before. To my surprise, the process took about 3 minutes.