Windows Server

If you have access to an HP server running Windows but you don't have access to ILO information (such as IP info), you can export it all to an XML file using a tool HP includes in the Proliant Support Pack. The tool is called hponcfg.exe and it's located under C:\Program Files\HP\hponcfg on x86 and x64 systems.

In order to use hponcfg, you'll need to have the ILO driver installed on the system. If you go in Device Manager, you'll see an entry under Multifunction Adapters like this:

If the driver isn't loaded, you'll get an error when you try to run the tool:

HPONCFG RILOE-II/iLO setup and configuration utility
Version 1.4 (c) Hewlett-Packard Company, 2005

ERROR: CPQSMIF.DLL and SM2USER.DLL not found.
ACTION REQUIRED: Please install the latest Proliant support pack.

So, to write out the config to an XML file, you'd do something like this:

hponcfg /w ILOConfig.xml

You'll get a file something like this:

 



<DIR_INFO MODE="write">
<MOD_DIR_CONFIG>
<DIR_AUTHENTICATION_ENABLED …

To follow up on the previous post I made about ILO scripting, this one runs through how you can change the password or add a user without having the login details to the ILO. I do thi al the time when I get new servers built in the field and while the local folks load the OS, they don't always remember to provide the username/password off the tag hanging off the server or they typo it, etc. This example also assumes that you have administrator level access to the actual server. You'll need hponcfg and the ILO driver loaded as discussed previously as well.

When you dump the ILO config, you'll be able to glean what users exist on the ILO from the info provided. In this example I'm just going to change the password for the admin user by using the following xml file. We'll set the password to "MyPassword".

 
  
 <USER_INFO MODE="write"> 
  <MOD_USER USER_LOGIN="admin"> 
    
   
  
  

The command to run is hponcfg /f iloconfig.xml where iloconfig.xml is the file holding the a…

I've spent a lot of time lately working on automating server builds. One of my TODOs which I finally tackled today was installing support for the Complex Script and East Asian language packs which you normally have to manually check off in the regional control panel:

If you have run Active Directory in a large environment, particularly with domain controllers in Asia or the Middle East, chances are you've gotten this event before (or a similar one):

Event Type:    Error
Event Source:    NTDS ISAM
Event Category:    General
Event ID:        604
Date:            11/17/2008
Time:            12:23:28 AM
User:            N/A
Computer:        TOKYO-DC02

Description:
NTDS (648) NTDSA: Locale ID 0x00000411 (Japanese Japanese) is either invalid or not installed on this machine.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

You get these when Outlook clients connect via NSPI and they're running one of the languages you need to manually install support for w…

Amazon announced the ability to run Windows virtual machines on their cloud computing platform, EC2, a few weeks ago. I had the opportunity to play with the technology for a few weeks and I was really impressed all around with the experience. If you're looking at solutions for on demand computing or want to have a relatively inexpensive and flexible hosting solution you can control completely, you should definitely take a look at EC2.

I wrote a couple of articles for Amazon as part of the launch of Windows on EC2. The articles cover deploying an ASP.Net app on an EC2 instance and configuring SQL Server 2005 to work with the Amazon EC2 platform. If you're interested in getting a quick feel for how the platform works, check these articles out:

• http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1827&categoryID=174
• http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1791&categoryID=174

Here's a handy trick I discovered recently when I needed to get a lot of server serial numbers pretty quickly. Normally you have to login to the Dell or HP management website and dig around before you can get the serial number. Sometimes the website doesn't work and you're either negotiating with the local support guy to go find it for you (and then the data's suspect by definition), or you're just out of luck.

You can grab this easily from the command prompt. Look up the wmic switches for info on connecting remotely to a machine:

C:\>wmic

wmic:root\cli>systemenclosure get serialnumber

SerialNumber
ABC12345

wmic:root\cli>exit

C:\>

I learnt today how to shut down/reboot a huge number of computers en masse regardless of whether or not they're turned on. Windows XP and Server 2003 have a command line utility called “shutdown”. If you pass a /i switch to it, a cool GUI interface pops up. At the top, you can add one or more computers to reboot/shutdown. I generated text file dumps of my computer labs with each computer on its own line. I paste the whole thing into the box, and click okay. From there, I just set the wait time to two seconds, pick a reason for the shutdown/reboot, and click okay. The utility iterates through the list gracefully, and handles any unreachable machines without error. Machines which are inaccessible have their names printed out the command line once the utility is through.

Learn how to use Sysprep for Windows Vista and Windows Server 2008. The process has changed significantly since previous versions of Windows. Sysprep is a critical step to deploying new system images - both for client computers and servers. If you do not run sysprep, you can quickly run in to problems when uniquely identifying information about your source machine is duplicated across the network.

Learn how to use Sysprep for Windows 2000, Windows XP, and Windows Server 2003. Sysprep is a critical step to deploying new system images - both for client computers and servers. If you do not run sysprep, you can quickly run in to problems when uniquely identifying information about your source machine is duplicated across the network.

Getting the amount of memory installed in a machine with WMI is a bit confusing particuarly if you only read the docs partially. I was initially using Win32_ComputerSystem::TotalPhysicalMemory, but the documentation warns  "Be aware that, under some circumstances, this property may not return an accurate value for the physical memory. For example, it is not accurate if the BIOS is using some of the physical memory."

The suggested alternative is Win32_PhysicalMemory::Capacity. This was an easy switch in my script, but, I was getting numbers I knew were wrong for the machines I was querying. The part I didn't read was that each instance of Win32_PhysicalMemory represents a single stick of RAM, so, you need to loop through them all and take the sum to get the RAM installed. This snippet will get you the total memory in megabytes:

Set colItems = wmiSvc.ExecQuery("SELECT * FROM Win32_PhysicalMemory", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)
totalMemory = 0
For Each item In colItems
      totalMemory …

Another script I wrote the other day, this one will take an input file called workstations.txt and produce a CSV which is easy to view in Excel and look at the local administrators group membership for the list of machines. The script could easily be modified to get the list from Active Directory although he framework I usually use for these is setup for a text file so I just export a list if AD is my source. The script will attempt to ping the machine before connecting in order to try and determine availability. If you have firewalls or routers filtering ICMP between the target machine and the host executing the script you may need to remove or modify this feature.

The script produces two files - a CSV and a log file. These three parameters are all configurable at the top by modifying lines 11 - 13:

Const LogFile = "LocalAdmins.log"
Const resultFile = "LocalAdministratorsMembership.csv"
Const inputFile = "c:\scripts\workstations.txt"

The script is attached below in a ZIP file. If you have any comments, b…

This is another useful script I sometimes use when I need to collect some basic inventory data from a list of machines. The attached vbscript takes an input file called workstations.txt and produces an comma separated output file called workstationinventory.txt. You can modify the two constants at the top of the file as noted below if you want to change this:

The script currently only outputs a limited set of information but the framework is there to extend it to collect really anything available via WMI. The fields currently exported are:

• Make
• Model
• BIOS Version
• Operation System
• Serial Number

To configure the input and output file modify lines 12 and 13:

Const PATH_TO_INPUT = "workstations.txt"
Const PATH_TO_OUTPUT = "workstationinventory.txt"

If you're looking for some guidance on other WMI data, check out the Scriptomatic tool from Microsoft.

The script is attached below in a zip. If you have any comments, bugs, etc feel free to leave them in the comments field and I'll take a look.

UPDATE:…