I recently came across a VM while generating a server list. I have a script that queries Active Directory for all server-based operating systems. I take that script and query the servers for the make/model info. Recently, I saw a VM in the list and was curious because I wasn't familiar with it. My script uses WMI to query two items:
SystemManufacturer
SystemProductName (AKA Model)
For Hyper-V VM's, the SystemManufacturer is Microsoft Corporation.
For Hyper-V VM's, the SystemProductName is Virtual Machine.
There are a number of ways to get the values. WMI using VBScript. PowerShell. Or just reading the values from the registry via REGEDIT.
REGEDIT: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SystemInformation
PowerShell: Get-WmiObject -Query "select * from Win32_ComputerSystem"
VBScript (watch out for line wrapping, tie this VBScript into larger script):
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystem", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)
For Each objItem In colItems
objTextFile.WriteLine strComputer
objTextFile.WriteLine objItem.Manufacturer & " " & objItem.Model
objTextFile.WriteLine
Next
If anybody wants the entire script (for automating querying a large number of servers), comment and I'll post it.
However, as others have pointed out (see: http://www.commandbreak.com/CommentView,guid,53004814-7f71-4772-bba2-4b77988d9b73.aspx#commentstart) - other Microsoft virutalization platforms return that same data. So you have to look a little further to distinguish Hyper-V VM's:
BIOSReleaseDate
Generally speaking, the BIOSReleaseDate for Hyper-V VM's will be 2008 and later while everything else will be older (2006, etc.). This isn't that concrete but it's a starting point. But now what? Even if you determine that you have a Hyper-V VM, how do you determine which Hyper-V host it resides on? Where is the management operating system?
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters
There are three values here that are of interest:
HostName REG_SZ
PhysicalHostName REG_SZ
PhysicalHostNameFullyQualified
Here is where I finally found the concrete answer. Once you have the host name, you can quickly manage it and get the rest of the details you need. I haven't had a chance to compare this data with that of Virtual Server. But I think I'll build some of this data into my scripts.
For those asking for the same thing but for VMWare (ESX or VSphere) - I cross checked this against both and while the make/model info is valid, the rest isn't. I will have to dive into determine your host ESX/VSphere server from a VMWare VM another time.
Monday, March 8, 2010
Monday, January 11, 2010
Monday, January 4, 2010
FAT vs. NTFS for USB drives
I was going to buy a new USB drive for my keychain the other day. I had a couple of gift cards from Christmas and figured it was time to upgrade my 16GB drive. Just before I was about to click the buy button, I realized that I needed to clarify a couple of things first. For me, it was specifically related to being able to copy files larger than 4GB to the drive. By default, keychain drives are formatted with FAT32 and the maximum file size for a FAT32 formatted drive is 4GB (to be technical, just under 4GB). Like many others, I use my keychain drive as a utility drive - temporarily storing large .ISO files (among other things). And these .ISO files can get larger than 4GB.
I had heard some negative things about using NTFS for USB keychain drives. To see the latest thoughts, I searched Google and read a few of the forums and blogs. And the information is still negative. And many times, wrong. Some of the common things reported about NTFS on USB keychain drive: slower performance, inability to access files on other machines without clunky workarounds, file corruption if you don't properly eject, and the inability to disable write caching on NTFS formatted USB keychain drives. Now if all of these things were true, I'd be stuck using FAT32!
I decided to put some things to the test. Obviously, I am not a scientist and the sampling is incredibly small. But useful nevertheless.
Computer: Dell E4300, P9400, 2.4GHz, 4GB of RAM, Windows 7 Pro (64-bit)
USB keychain drive: Corsair Flash Voyager 16GB (about 2 1/2 years old)
I started by enabling write caching on the Corsair (via Device Manager in Windows). This allowed me to format the Corsair with NTFS. I formatted the Corsair with NTFS and left write caching enabled. I proceeded to copy a 3.31GB .ISO file from my laptop to the Corsair. Then I deleted the file, disabled write caching, and copied the file again. Finally, I formatted the Corsair with FAT32 and copied the file a third time. I performed the same steps for a 1.14GB .ISO file as well. The following table shows the results of the copy operations.
First things first, performance is very similar. Certainly not a noticeable difference. In my case, my entire usage of the keychain drive is to copy files to it for temporary storage, then copy them off at some point thereafter. I'm not using it for online editing of files. I'm not using it for ReadyBoost. I'm just using it for temporary, portable file storage. Based on my tests, I have nothing to worry about with NTFS and performance. In fact, I may gain a slight edge (my calculation shows approximately 1.65% better performance under NTFS w/o caching)!
What about the ability to access your files from other machines? That seems to be something people are worried about too. And if you believe what you read, you won't be able to access your files! Access denied! NTFS permissions will get in the way, you'll have to take ownership, assign permissions, etc. What people forgot to look at was the default permissions. The default permissions on a freshly formatted drive? Everyone, Full Control. What does that mean? That means anybody and everybody can access the files, create files, delete files, etc. In other words, the permissions are compatible with any Windows machine! Just to be sure, I took my freshly formatted USB keychain drive (NTFS w/o caching) to a friend's machine, stuck my keychain drive in, and tested. I was able to access everything and copy new files to the drive. I took it back to my original test machine and was able to access everything (including the new files). Worked flawlessly.
OK... so what about file corruption and proper ejections? Don't you have to eject once you format to NTFS? Well, only if you keep write caching enabled. And I'd recommend disabling write caching. You don't want to have to tell anybody you hand your keychain drive about proper ejection. And you'll want to just rip the keychain drive out of the USB slot on demand. So disable write caching. So isn't NTFS a journaling file system? Yes. Which means that sometimes a write isn't really a write. Sometimes, a write stays in memory before being written to disk. Could that cause an issue? Not for my use. I'm going to copy a few .ISO files to the drive and take it out thereafter. In my limited testing, I have been unable to corrupt and files or lose any data.
Tests performed:
Edit text file, click Save, and immediately pull keychain drive out
Edit text file with 88KB of new data, click Save, and immediately pull keychain drive out
Edit text file with 1 line of new data, pull keychain drive out before saving, then put keychain drive back in, click Save
All tests were successful. No complaints from Windows. No loss of data. No corruption. I've heard of some elaborate things that will cause corruption but they aren't real world situations. One example was to hibernate your laptop with your keychain drive in, pull the keychain drive out, insert it to another machine, copy new data to it, then resume your laptop from hibernation and put the keychain drive back in. This created a problem under specific versions of Windows. But for me, that's not very convincing. It isn't real world use and certainly isn't my use.
Finally, I'll address the ability to disable write caching on NTFS formatted USB drives. Yes, you can disable write caching. No issues there. And by doing this, it allows for the quick removal of the drive (just like you can with the default FAT32 formatted drives).
Although limited testing, I think there's enough good here to warrant a serious consideration for NTFS formatted USB keychain drives. And that's STRICTLY for the ability to work with files larger than 4GB. I didn't even get into the other benefits of NTFS (compression, security, encryption, file system recovery, etc.). Some of you may ask, doesn't NTFS wear out the USB keychain drives? Lots of stories on the web about this. Well, much of that information is old. New methods are in use now and components have improved greatly. This question is best answered by quoting Corsair's life span FAQ:
"Will my Corsair USB Flash drive last more than 10 years?
Yes. All Corsair flash drives are built with memory components that can handle AT LEAST 10,000 write cycles; typically they will handle an order of magnitude more than this. So, this means that in order to exhaust the drive in ten years, one would have to write to EVERY BLOCK in the device about 2.7 times per day, every single day. We simply can’t conceive of such a usage scenario; this would mean that on a fairly typical 8 GByte drive, one would need to write over 21 GBytes of data to it every day for ten years! USB flash drives simply are not used in this way.
If one thinks he or she might actually try this, we suggest buying a Corsair Flash Voyager GT or a Corsair Flash Survivor GT USB drive. They are built with components guaranteed for 100,000 write cycles. With these, one can write over 210GBytes of data to the drive each day, for ten years!"
Corsair's Wear Leveling and Life Span
What's next? Start testing yourself and see if you agree!
I had heard some negative things about using NTFS for USB keychain drives. To see the latest thoughts, I searched Google and read a few of the forums and blogs. And the information is still negative. And many times, wrong. Some of the common things reported about NTFS on USB keychain drive: slower performance, inability to access files on other machines without clunky workarounds, file corruption if you don't properly eject, and the inability to disable write caching on NTFS formatted USB keychain drives. Now if all of these things were true, I'd be stuck using FAT32!
I decided to put some things to the test. Obviously, I am not a scientist and the sampling is incredibly small. But useful nevertheless.
Computer: Dell E4300, P9400, 2.4GHz, 4GB of RAM, Windows 7 Pro (64-bit)
USB keychain drive: Corsair Flash Voyager 16GB (about 2 1/2 years old)
I started by enabling write caching on the Corsair (via Device Manager in Windows). This allowed me to format the Corsair with NTFS. I formatted the Corsair with NTFS and left write caching enabled. I proceeded to copy a 3.31GB .ISO file from my laptop to the Corsair. Then I deleted the file, disabled write caching, and copied the file again. Finally, I formatted the Corsair with FAT32 and copied the file a third time. I performed the same steps for a 1.14GB .ISO file as well. The following table shows the results of the copy operations.
| Operation | File System | Elapsed Time |
|---|---|---|
| 3.31GB file copy | NTFS w/ caching | 6 min. and 18 seconds |
| 3.31GB file copy | NTFS w/o caching | 6 min. and 14 seconds |
| 3.31GB file copy | FAT32 w/o caching | 6 min. and 25 seconds |
| 1.14GB file copy | NTFS w/ caching | 2 min. and 13 seconds |
| 1.14GB file copy | NTFS w/o caching | 2 min. and 12 seconds |
| 1.14GB file copy | FAT32 w/o caching | 2 min. and 15 seconds |
First things first, performance is very similar. Certainly not a noticeable difference. In my case, my entire usage of the keychain drive is to copy files to it for temporary storage, then copy them off at some point thereafter. I'm not using it for online editing of files. I'm not using it for ReadyBoost. I'm just using it for temporary, portable file storage. Based on my tests, I have nothing to worry about with NTFS and performance. In fact, I may gain a slight edge (my calculation shows approximately 1.65% better performance under NTFS w/o caching)!
What about the ability to access your files from other machines? That seems to be something people are worried about too. And if you believe what you read, you won't be able to access your files! Access denied! NTFS permissions will get in the way, you'll have to take ownership, assign permissions, etc. What people forgot to look at was the default permissions. The default permissions on a freshly formatted drive? Everyone, Full Control. What does that mean? That means anybody and everybody can access the files, create files, delete files, etc. In other words, the permissions are compatible with any Windows machine! Just to be sure, I took my freshly formatted USB keychain drive (NTFS w/o caching) to a friend's machine, stuck my keychain drive in, and tested. I was able to access everything and copy new files to the drive. I took it back to my original test machine and was able to access everything (including the new files). Worked flawlessly.
OK... so what about file corruption and proper ejections? Don't you have to eject once you format to NTFS? Well, only if you keep write caching enabled. And I'd recommend disabling write caching. You don't want to have to tell anybody you hand your keychain drive about proper ejection. And you'll want to just rip the keychain drive out of the USB slot on demand. So disable write caching. So isn't NTFS a journaling file system? Yes. Which means that sometimes a write isn't really a write. Sometimes, a write stays in memory before being written to disk. Could that cause an issue? Not for my use. I'm going to copy a few .ISO files to the drive and take it out thereafter. In my limited testing, I have been unable to corrupt and files or lose any data.
Tests performed:
Edit text file, click Save, and immediately pull keychain drive out
Edit text file with 88KB of new data, click Save, and immediately pull keychain drive out
Edit text file with 1 line of new data, pull keychain drive out before saving, then put keychain drive back in, click Save
All tests were successful. No complaints from Windows. No loss of data. No corruption. I've heard of some elaborate things that will cause corruption but they aren't real world situations. One example was to hibernate your laptop with your keychain drive in, pull the keychain drive out, insert it to another machine, copy new data to it, then resume your laptop from hibernation and put the keychain drive back in. This created a problem under specific versions of Windows. But for me, that's not very convincing. It isn't real world use and certainly isn't my use.
Finally, I'll address the ability to disable write caching on NTFS formatted USB drives. Yes, you can disable write caching. No issues there. And by doing this, it allows for the quick removal of the drive (just like you can with the default FAT32 formatted drives).
Although limited testing, I think there's enough good here to warrant a serious consideration for NTFS formatted USB keychain drives. And that's STRICTLY for the ability to work with files larger than 4GB. I didn't even get into the other benefits of NTFS (compression, security, encryption, file system recovery, etc.). Some of you may ask, doesn't NTFS wear out the USB keychain drives? Lots of stories on the web about this. Well, much of that information is old. New methods are in use now and components have improved greatly. This question is best answered by quoting Corsair's life span FAQ:
"Will my Corsair USB Flash drive last more than 10 years?
Yes. All Corsair flash drives are built with memory components that can handle AT LEAST 10,000 write cycles; typically they will handle an order of magnitude more than this. So, this means that in order to exhaust the drive in ten years, one would have to write to EVERY BLOCK in the device about 2.7 times per day, every single day. We simply can’t conceive of such a usage scenario; this would mean that on a fairly typical 8 GByte drive, one would need to write over 21 GBytes of data to it every day for ten years! USB flash drives simply are not used in this way.
If one thinks he or she might actually try this, we suggest buying a Corsair Flash Voyager GT or a Corsair Flash Survivor GT USB drive. They are built with components guaranteed for 100,000 write cycles. With these, one can write over 210GBytes of data to the drive each day, for ten years!"
Corsair's Wear Leveling and Life Span
What's next? Start testing yourself and see if you agree!
Wednesday, September 16, 2009
Why do you have to confirm your e-mail address?
OK. This is getting ridiculous. Every single site I can think of requires me to confirm my e-mail address when I sign up or purchase something. The only exceptions are typically when you sign up for a new e-mail account. Those sites only ask you for a secondary e-mail address one time. Which is still a bit strange. If somebody is new to the Internet and is signing up for an e-mail address for the first time, how would that person already have a secondary e-mail address?
Think about all the information you give when you purchase something on a web site - your name, your billing address, your shipping address, your phone number, your payment information, and your e-mail address. If I was the seller, I'd be asking you to confirm your payment information a second time long before I'd be asking you to confirm your e-mail address a second time. But what happened was that confirming your e-mail address became an unspoken standard. Every time a new web site went up selling something, they'd just base their checkout page on existing checkout pages. And that's when the process of having you type your e-mail address a second time spread everywhere. Funny thing is, I usually just highlight what I typed the first time, copy it, then paste it when it asks me to confirm my e-mail address!
I can just imagine where this can lead to.... confirm your name, confirm your address, and confirm your credit card number a third time!
What is also becoming the norm is to actually validate your e-mail address. So enter your e-mail address twice and then wait for a validation e-mail to visit a web site to validate that the e-mail address is really yours. If I'm selling something, why do I care? As long as the credit card number is valid and the billing address checks out, I'm ready to sell you something. If you mistype your e-mail address or use a fake e-mail address... OH WELL. Nothing lost on my side. Except I can't send my marketing e-mails to you!
I think we should consider some of this redundancy for non-Internet usage. It could really cut down on fraud!
Teller: Welcome to PYHOOYA Bank! Can I help you?
Bob (customer): Yes. I'd like to make a withdrawal.
Teller: OK. What is your account number?
Bob: 293847173.
Teller: OK. Please confirm your account number.
Bob: But I just told you my account number?! But fine - 293847173.
Teller: And what is your name? What is your name?
Bob: Bob Jenkins.
Teller: I asked for your name twice as I needed you to confirm that the name you gave me is actually your name and that you didn't make a mistake when you told me your name. So again, what is your name, what is your name?
Bob: Bob Jenkins, Bob Jenkins.
Teller: How much money would you like to withdrawal?
Bob: $100.
Teller: Please confirm how much money you would like to withdrawal.
Bob: Screw it. Withdrawal everything. Account closed.
Teller: I'm sorry, your second amount does not match your first amount. You have lost your place in line. Please start again at the back of the line. NEXT CUSTOMER PLEASE.
Think about all the information you give when you purchase something on a web site - your name, your billing address, your shipping address, your phone number, your payment information, and your e-mail address. If I was the seller, I'd be asking you to confirm your payment information a second time long before I'd be asking you to confirm your e-mail address a second time. But what happened was that confirming your e-mail address became an unspoken standard. Every time a new web site went up selling something, they'd just base their checkout page on existing checkout pages. And that's when the process of having you type your e-mail address a second time spread everywhere. Funny thing is, I usually just highlight what I typed the first time, copy it, then paste it when it asks me to confirm my e-mail address!
I can just imagine where this can lead to.... confirm your name, confirm your address, and confirm your credit card number a third time!
What is also becoming the norm is to actually validate your e-mail address. So enter your e-mail address twice and then wait for a validation e-mail to visit a web site to validate that the e-mail address is really yours. If I'm selling something, why do I care? As long as the credit card number is valid and the billing address checks out, I'm ready to sell you something. If you mistype your e-mail address or use a fake e-mail address... OH WELL. Nothing lost on my side. Except I can't send my marketing e-mails to you!
I think we should consider some of this redundancy for non-Internet usage. It could really cut down on fraud!
Teller: Welcome to PYHOOYA Bank! Can I help you?
Bob (customer): Yes. I'd like to make a withdrawal.
Teller: OK. What is your account number?
Bob: 293847173.
Teller: OK. Please confirm your account number.
Bob: But I just told you my account number?! But fine - 293847173.
Teller: And what is your name? What is your name?
Bob: Bob Jenkins.
Teller: I asked for your name twice as I needed you to confirm that the name you gave me is actually your name and that you didn't make a mistake when you told me your name. So again, what is your name, what is your name?
Bob: Bob Jenkins, Bob Jenkins.
Teller: How much money would you like to withdrawal?
Bob: $100.
Teller: Please confirm how much money you would like to withdrawal.
Bob: Screw it. Withdrawal everything. Account closed.
Teller: I'm sorry, your second amount does not match your first amount. You have lost your place in line. Please start again at the back of the line. NEXT CUSTOMER PLEASE.
Subscribe to:
Posts (Atom)