Aug 302010
 

While setting up a PKI environment in our lab (using LDAP as our first CRL and HTTP as our second CRL), we noticed some weird behavior. We are using HTTP as a second CRL since most (if not all) of our clients are not joined to our lab environment’s domain.

When everything was installed and the certificates where distributed we noticed a weird error when connecting with RDP to one of our domain controllers. The error was “A revocation check could not be performed for the certificate”. Ok, this error would indicate that the client is not able to contact the CRL list which is located in AD and on the HTTP server.

image

While testing we noticed that the HTTP server was accessible for anonymous traffic. So that wouldn’t be the problem. While searching the internet for some relevant information we found two links which seemed to be related with our case. The Microsoft TechNet threads “Revocation check using LDAP URL fails” and “Certificate revocation check from external network”. While doing some tests we also noticed that domain joined systems didn’t have any of the same issues. So for some reason the RDP client could not failover to the HTTP CRL URL. To me it looks like a bug, and it’s something I’m certainly going to test more in a “private” lab within VMware Lab manager. Hopefully a sniffer trace or something like that will shed some light on this.

In the end we decided to change our PKI environment because we are lacking the time to trace the problem deeply. Instead of using Active Directory (or LDAP) as the first CRL and HTTP as the second CRL we switched it around and are now using HTTP as the first CRL and LDAP as the second CRL. This is currently working just fine.

Jul 152010
 

At my job site we have a very nice and cool lab environment. However due to budget cuts we are currently not in the position to extend our lab. So at the moment we currently have two uninterruptable power supplies (UPS) which would give the systems enough “juice” in case we have a power outrage. However, these UPS systems don’t have a management interface card. The problem with that is we are not able to communicate with the UPS to make sure that the servers are brought down nicely.

So we changed our system environment a bit. The Cisco switches are now connected on dirty power, so if we have a power outrage, the switches would be gone immediately. If the switches fail, our servers will not be able to communicate anymore with their default gateway. Within VMware this is known as isolation mode. VMware will bring it’s VM’s down, however our 3 physical servers (SQL 2008, VCenter and a DC) will have a problem. They are not brought down in such an event.

Therefore I wrote a little PowerShell script you can find below. Simple edit the time and other variables to suit your environment. With the current timers, the quickest shutdown will take place within 4 minutes, else it will take up to a maximum of 6 minutes. Note: make sure your UPS can hold it that long.

Although I do know that this is really a poor mans solution, I don’t think we have a better choice.

[code lang=”ps”]
$Gateway = "10.75.36.254"

function checkStatus {
$PingCount = "2"
 if (!(Test-Connection $Gateway -Count $pingCount -ErrorAction SilentlyContinue)) {
  $Subject="Network Lost"
  $LogLevel= "Warning"
  $Message = "Gateway didn’t respond within a timely fasion"
  WriteEventLog
  Recheck
 }
}

function Recheck{
$PingCount = "4"
#recheck gatway response within 4 pings.
#wait ten seconds before continue. This to rule out a temporarily  unplugged cable.
Start-Sleep -Seconds 180
 if (Test-Connection $Gateway -Count $pingCount -ErrorAction SilentlyContinue) {
  $Subject="Network connection restored"
  $LogLevel= "Information"
  $Message = "Gateway responded again. ‘nConnection restored."
  WriteEventLog
 }
 else {
 #If ping is still not responding, receck it again, else shudown the Windows Server
 Start-Sleep -Seconds 60
  if (!(Test-Connection $Gateway -Count $pingCount -ErrorAction SilentlyContinue )) {
   shutdownSystem
  }
  else {
  $Subject="Network connection restored"
  $LogLevel= "Information"
  $Message = "Gateway responded again. ‘nConnection restored"
  WriteEventLog
  }
 }

Function shutdownSystem{
$Subject="Network Lost"
$LogLevel= "Error"
$Message = "System is going down since network is lost. Possible due to a power failure `nPlease contact one the System Administrators."
WriteEventLog
# Shutting down the computer will start right now.
Stop-Computer -Force
}

Function WriteEventLog {
 $Event=new-object System.Diagnostics.EventLog("System")
 $Eevent.Source=$Subject
 $InfoEvent=[System.Diagnostics.EventLogEntryType]::$LogLevel
 $Event.WriteEntry($Message,$InfoEvent,65000)
}

$Counter = 1
do {
 #loop forever
 start-sleep -Seconds 120
 checkStatus
}
while ($Counter -eq 1)

[/code]

May 032010
 

Since I’m currently busy with installing multiple ESX servers in our test environment, I needed to create about 32 DNS records. Well since I’m lazy and I’ve really been loving Powershell I thought it would be a nice challenge to use PowerShell and of course the powerful DNScmd command. Since we have a logical IP plan, I could use the following script.

1..32 | % {iex ([string]::format(“dnscmd /RecordAdd mylab.com ESXhost{0} /createPTR A 192.168.10.{0}”,$_))}

Of course there are many other ways. For example, using a CSV file to import the DNS records.

For example:

Import-CSV c:\DNS.csv | foreach {dnscmd /RecordAdd $_.Zone $_.hostname /createPTR A $_.IPaddress}

However, keep in mind that PowerShell uses comma separated files and not the semicolon separated file which Excel automatically creates. So for example, use:

Hostname,IPaddress,Zone
ESX1,192.168.10.50,MyLab.com
ESX2,192.168.10.51,MyLab.com
ESX3,192.168.10.52,MyLab.com
ESX4,192.168.10.53,MyLab.com

Instead of:

Hostname;IPaddress;Zone
ESX1;192.168.10.50;MyLab.com
ESX2;192.168.10.51;MyLab.com
ESX3;192.168.10.52;MyLab.com
ESX4;192.168.10.53;MyLab.com

Mar 272010
 

Last week we started building our lab. Since it’s isolated with it’s own internet feed we thought that it would be a good idea to access it using VMware View 4 over the internet. However, since we prefer using Windows Server 2008 over Windows 2003 we were not sure if we could use this for VMware View Composer 2.0. Somehow we couldn’t find this in the documentation so we started to test this out.

First we installed Windows Server 2008 x64 Enterprise Edition. Of course, this was installed perfectly on our physical server. The next step was installing our vCenter server. Ok, here the problems started. We have a SQL server 2008 instance hosted on another server and we wanted to use this database server. Well, for this we needed to create an ODBC connection. No problem… right? Well, not quite. When you are using a 64-bit edition of Windows you need to make sure you create a 32-bit ODBC connection. Although the process of creating such ODBC connection is pretty straight forward, you can’t use the ODBC shortcut located in the administrative tools.

Instead, you need to use the version located here: %systemdrive%\Windows\SysWoW64\Odbcad32.exe. Although it seems logical that you have to create a system DSN and not an user DSN. However, in our case this was not the only thing we needed to change. With Windows server 2008 x64, the included SQL driver is too new. If you are trying it like we did, you will get this error message: “DSN is pointing to a unsupported ODBC driver.” This is described in this document from VMware. Although it stated that the SQL driver is outdated, the file date from the driver which is included by default is actually newer then the one you need to download. 🙂

So after we downloaded and installed the correct SQL driver (called SQL Native Client 10), we where able to create the correct 32-bit system DSN and finally we could install vCenter Server.

The next step was installing VMware View composer 2 which is an optional component of VMware View. However, since it makes it possible to use linked clones (and also since I like playing around a bit) I thought “let’s install it!” The requirements of this product is that you have to install it on the vCenter Server and it needs its own database. Well, no problem. We created a new database and we setup a new ODBC connection just like we did with the vCenter Server installation. A 32-bit System DSN with the same SQL driver. However during the installation somehow it didn’t see any DSNs. At first I was a bit stumped. But well, it isn’t my first issue, so I stopped the installation process and deleted the newly created 32-bit System DSN. Again I created a new System DSN, but this time a 64-bit DSN. I restarted the installation process and VMware View Composer 2 was finally able to use the DSN

I will probably continue configuring our new lab next week, if I have some spare time. 🙂

Feb 022010
 

Due to security reasons WPAD and ISATAP have been by default blocked in Windows server 2008 DNS. There is a GlobalQueryBlockList which blocks these entries. When you try to create a WPAD entry to configure your ISA Auto Discovery, it will fail to resolve the WPAD entry whereas it will resolve the WSPAD entry. This can be quite problematic when you using the WPAD DNS entry rather then the DHCP possibility.

To remove the WPAD from the block list type the following command:
Dnscmd /config /globalqueryblocklistisatap

This command will override the existing list with ISATAP as the only keyword.
Now, you can resolve the WPAD entry from NSLOOKUP

Check DNS Server Global Query Block List from the Microsoft website for more details about DNS


Source