Archives for August 2010

SYSPREP resetting your renamed Administrator and Guest accounts?

Lately I’ve been working on our Server 2008 R2 vSphere 4.1 template and ran into an interesting issue. During the template build process we rename the Administrator and Guest accounts, to comply with best practices. However, after vCenter executed the¬†customization specification the accounts got reset back to Administrator and Guest. Well that’s no good since it violates our¬†security policies. I wanted to find an automated solution, and I did.

During the SYSPREP process Windows can call a script called setupcomplete.cmd which is located in %WINDIR%SetupScripts. So I added two lines to my existing script:

wmic useraccount where name=”Administrator” call rename name=”NewAdmin”
wmic useraccount where name=”Guest” call rename name=”NewGuest”

Since this gets called at the very end of the sysprep process, it renames the accounts just before Windows reboots. This should work on Windows 7, and very likely previous generation operating systems.

vSphere 4.1 Performance Best Practices

With the release of ESX 4.1 and vCenter 4.1, VMware has greatly increased the performance of vCenter. I accidentally stumbled upon this VMware document called VMware vCenter Server Performance and Best Practices.

It’s a great read covering benchmark performance differences between vCenter 4.0 and vCenter 4.1, plus a lot of tips and tricks for getting the most out of vCenter. I highly recommend anyone deploying vCenter 4.1 to read the document. It’s really quite enlightening.

Automate vCenter 4.1 64-bit DSN Creation

Back in the days of vCenter 4.0 it required a 32-bit DSN to connect to your SQL database. Now that vCenter 4.1 and ESX 4.1 are out, it now requires the use of a 64-bit DSN. This makes sense as vCenter now requires a 64-bit server. The PowerShell script I wrote last year automated the configuration of a 32-bit DSN. So I needed to do a couple of minor tweaks to make it create a 64-bit DSN.

If you are using Windows Server 2008/R2, make sure you run the PowerShell script as Administrator or it will fail with lots of error messages. The script is compatible with both SQL 2008 and SQL 2008 R2.


## Creates a 64-bit System DSN for vCenter Server.
## Version 1.0, 21 August 2010

$DSNName = “vCenter Server”
$DBName = “vCenter Server”

If($args[0] -eq $NULL) { echo “Must specify FQDN of SQL server.”; Exit}

$HKLMPath1 = “HKLM:SOFTWAREODBCODBC.INI” + $DSNName
$HKLMPath2 = “HKLM:SOFTWAREODBCODBC.INIODBC Data Sources”

md $HKLMPath1 -ErrorAction silentlycontinue
set-itemproperty -path $HKLMPath1 -name Driver -value “C:WINDOWSsystem32sqlncli10.dll”
set-itemproperty -path $HKLMPath1 -name Description -value $DSNName
set-itemproperty -path $HKLMPath1 -name Server -value $args[0]
set-itemproperty -path $HKLMPath1 -name LastUser -value “Administrator”
set-itemproperty -path $HKLMPath1 -name Trusted_Connection -value “Yes”
set-itemproperty -path $HKLMPath1 -name Database -value $DBName

## This is required to allow the ODBC connection to show up in the ODBC Administrator application.

md $HKLMPath2 -ErrorAction silentlycontinue
set-itemproperty -path $HKLMPath2 -name “$DSNName” -value “SQL Server Native Client 10.0”

Just save the file on your vCenter server, open an elevated PowerShell command window and execute the script with an argument of the FQDN of your SQL server. For example:

DSN-vCenter64.ps1 SQL01.contoso.net

Be sure to change the database name variable to match what you configured in SQL.

Staying thin in the real-world with a 3PAR array

If you aren’t familiar with thin provisioning, it’s a technology being widely adopted by storage vendors that only allocates back-end disk space to a LUN when data is written. For example, if you present a 500GB LUN to a server and only write 100GB of data, the array only uses 100GB of disk space. The remaining 400GB can be used by another server, or the same server when more data is written.

But what happens when you delete the data? With many arrays the space is still allocated to that LUN and not put back into the ‘scratch’ pool for future re-use. Depending on your data access patterns, you may end up with a lot of trapped capacity. Thin volumes can gain weight and become fat..like much of America!

Several vendors such as EMC, Hitachi and 3PAR have updated their arrays to reclaim some of this trapped capacity. They do this by detecting chunks of zeros and tossing those chunks back into an unallocated storage pool. Since we use a 3PAR array at work, I decided to put their Thin Persistence feature to the test.

Unfortunately I can’t post screen shots since I don’t have an array at home and this is my personal blog. So you will have to take my word for the results. Listed below are the high-level steps that I took to perform the test.

1. Provisioned a new thin-provisioned virtual volume of 100GB in the 3PAR T400.
2. Enabled zero-detection on the volume (simple GUI check-box).
3. Exported that virtual volume as a LUN to a Windows Server 2003 R2 physical server.
4. Formatted the new LUN with the NTFS file system and assigned it a drive letter.
5. Copied 90GB of data into the new volume and verified in the 3PAR InForm Management Console that it showed approximately 90GB capacity utilization for that volume. Check, it did!
6. Deleted 40GB worth of data from the LUN, so 50GB was remaining.
7. Executed the MS Sysinternal tool “sdelete” with the -c option to zeroize all unused disk space.
8. I then monitored the volume’s utilization in the 3PAR InForm management console, and it slowly dropped as the sdelete command was running.
9. By the time the sdelete command finished, the volume utilization was down to 50%, matching the 50GB of still used disk space. 40GB of space has been reclaimed.

This test proved that the 3PAR zero reclaim feature worked as advertised, happens in real time, and take very little effort to use. The same process would work for a virtual machine as well. If I was using the Veritas Storage Foundation I would not have to use the sdelete command and it would be fully automated. Hopefully they will work with Microsoft and VMware to support a fully automatic and native method to reclaim the deleted space. Until then, you can run sdelete from time to time to drop those extra pounds from your fat LUNs.

Stay thin with no gym time for your array..yippee!

© 2017 - Sitemap