String Theory

The inaugural meeting of the Atlanta PowerShell User Group will be held on Tuesday February 16th from 6:00 to 8:00 PM. You can sign up now at http://powershellgroup.org/atlanta.ga.

Our first meeting will be a script club.

What is a script club you ask? You bring an idea for a script, and ask your fellow PowerShell users for help getting the script written. If it’s PowerShell, its covered — just bear in mind that it may be hard to test things like Exchange scripts or Active Directory management scripts unless you have a nice virtual lab on your laptop.

What are the Rules of Script Club?

1. You always talk about script club
2. You always talk about script club
3. If someone asks for help, and you can help, you help
4. Two people help one person at one time
5. One module per person per night
6. All scripts, all PowerShell
7. Scripts will be as short as they can be
8. If this is your first time at Script Club, You have to script!

Please RSVP so we can get a head count (especially if you want Pizza and come ready to pitch in a few dollars to help pay for the pizza.)!

Our meeting will be held at the New Horizon’s training center at 211 Perimeter Center Parkway, Suite 200, Atlanta, GA 30346. Click here for directions and a map.

pJust playing around with Microsoft One Note 2010 as described here: a href=”http://webworkerdaily.com/2009/12/16/blogging-with-onenote-2010-beta/”http://webworkerdaily.com/2009/12/16/blogging-with-onenote-2010-beta//a
/p

In our environment we use Altiris Deployment Solution (DS) to perform a completely automated server build. My deployment jobs configure the hardware, install the operating system, Citrix XenApp, and supporting applications. At the end is a server, ready to take applications. We are now in the process of virtualizing our XenApp servers on XenServer and I want to automate that process, as well. This guide will provide the instructions for performing an automated Citrix XenServer build, and end up with a XenServer installation with the Altiris agent installed and configured.

The XenServer installation guide shipped with the software, specifies how to perform an automated PXE installation of XenServer. For the record, that documentation has many, many mistakes, so if you follow it exactly you won’t get a working setup. Citrix seems to have just copied it from early Xen versions without updating it.  The documentation assumes the use of a Linux server that will serve as a DHCP/PXE/HTTP server for the installation. We already have Altiris Deployment Solution, and I didn’t want to have to reinvent the wheel, and have two disparate solutions; so I started working on getting the automated build working with Altiris. My solution will assume Altiris Deployment Solution 6.9 SP1 and XenServer 5.5.0, but you should be able to easily adjust for your environment.

Install Files

The first step in the installation routine is to provide a location for the install files. The XenServer automated build process actually support http, ftp, and nfs for storage locations. I am using http because I already have it running for the Deployment Web Console.

1. If you don’t already have IIS installed for the Deployment Web Console go ahead and install it now.
2. Navigate to the “Default Web Site” home directory.
   1. Create a directory called XenServer.
   2. Within XenServer create a directory called 5.5.0.
3. Copy the packages.main directory from the XenServer install CD to 5.5.0.
4. Copy the packages.linux directory from the XenServer Linux CD to 5.5.0. (You can leave this step out if you never plan on running Linux guests.)
5. In IIS Manager, bring up the properties for the XenServer directory.
   1. Under “HTTP Headers”, select “MIME Types…” and enter the information below.

      This step is needed  for IIS to treat all .* files as binary files and allow them to be downloaded during the installation.

6. Configure  and copy adlagent.conf from the Agents\AdlAgent directory of your DS eXpress share to the XenServer directory.
7. Copy Altiris-adlagent-2.6-65.x86_64.bin from the Agents\AdlAgent directory of your DS eXpress share to the XenServer directory.

Answer File

The next step is to create the answer file that the XenServer installation process will use for the install. In my installation, I keep this answer file as simple as possible and use Altiris to perform the customizations. The next step is to create the answer file that will provide the configuration details for the base installation.

1. In the XenServer\5.5.0 directory created earlier, create your answer file, “answerfile.xml”. Refer to Appendix B in the XenServer 5.5 Installation Guide pg. 32 for the syntax.

Included below is a working example you can use. Replace *SERVER* with the name or IP Address of your DS server. Also, since this file can be read by anyone, I highly recommend changing the root password at the very earliest occasion.

<?xml version="1.0"?>

<installation>

    <primary-disk gueststorage="no">sda</primary-disk>

    <guest-disk>sdb</guest-disk>

    <keymap>us</keymap>

    <root-password>password!</root-password>

    <source type="url">http://*SERVER*/XenServer/5.5.0</source>

    <!--<driver-source></driver-source>-->

    <post-install-script type="url">http://*SERVER*/XenServer/post-install-setup.sh

    </post-install-script>

    <admin-interface name="eth0" proto="dhcp"></admin-interface>

    <timezone>America/New_York</timezone>

</installation>

Installation Scripts

Now we will work on the installation scripts. This process involves two. The first script sets up the second script to be executed when the server reboots into the XenServer OS. The main reason for this is that during the installation process the target filesystem is actually mounted to /tmp/root. So any installations, such as the Altiris client, would actually install to the temporary filesystem setup by the installation environment. We remedy this by having the setup work done when the server reboots into the XenServer OS.

Post-install-setup

1. In the XenServer folder create post-install-setup.sh and insert the code below substituting *SERVER* for your DS name or IP Address.

As mentioned above, the root filesystem of the host is actually mounted to /tmp/root so by placing the post-install-script.sh in /tmp/root/etc/rc3.d we can have the script run on the first host boot.

Post-install-script

1. In the XenServer folder create post-install-script.sh and insert the code below substituting *SERVER* with your DS name or IP Address.

This script downloads the agent files, installs the agent, copies the configuration file to the appropriate location and then deletes itself.

PXE Setup

Now we will set up the PXE files to start the installation process.

1. Create a directory and copy the following files from the XenServer Installation CD: install.img, Boot\xen.gz, and Boot\vmlinuz.
2. Download Syslinux from http://www.kernel.org/pub/linux/utils/boot/syslinux/ and extract mboot.c32 and pxelinux.0 to the directory above.
3. Open the PXE Configuration Utility and create a new boot option.
   1. Select Linux, x86, and user supplied.
   2. Click “Manual Boot Image…” and select the directory created above.

   Make a note of the “Final Location”. You will have to edit some files manually.

4. Navigate to the PXE\MasterImages\MenuOptionXXX directory using the number designation from the “Final Location”.
5. In the X86PC directory create a directory called pxelinux.cfg. In this directory create a file called default and insert the content below substituting *SERVER* with your DS server name or IP Address.

default xenserver-auto
label xenserver-auto
  kernel mboot.c32
  append xen.gz dom0_mem=752M com1=115200,8n1 console=com1,tty --- vmlinuz console=ttyS0,115200n8 console=tty0 answerfile=http:///XenServer/5.5.0/answerfile.xml install --- install.img

Note: The append line, which is the last line, is one single, non-breaking, line. If you break up the line it will break the setup.

6.    Replicate the PXE\MasterImages\MenuOptionXXX directory to PXE\Images\MenuOptionXXX directory using the number designation.

Conclusion

Now with all of this setup you now have a working automated XenServer build. On your target server, boot the server. At the PXE menu, hit F8 and select “XenServer Automated Build”. The server will have XenServer installed and automatically added to your DS console.

The selecting of the PXE boot boot menu has to be manual. You could have it boot into the menu by assigning the job, but since there is no agent in the installation environment it would just continuously boot into the PXE installation.

Since the hostname was not specified, it will default to localhost.localdomain. This also means that it will show up as localhost in the Altiris console.  For one system this is not really an issue. However, when  trying to set up a number of systems this can cause confusion. In a subsequent post,I will demonstrate a method for using an external reference, to provide to Altiris the information needed to correctly configure the systems.

This afternoon there was a discussion about determining the version of PowerShell installed on the local system. Each of us had our own answer. Someone mentioned the [System.Version] .Net class. Its a relatively small class that might you might find useful.

Lets take the Product Version of the PowerShell executable installed on my Windows 7 workstation and get the properties of the class.

$Version = [Version][Diagnostics.FileVersionInfo]::GetVersionInfo(
   “$PSHome\PowerShell.exe“).ProductVersion
$Version | Select *

And this is what we get:

Major         : 6

Minor         : 1

Build         : 7100

Revision      : 0

MajorRevision : 0

MinorRevision : 0

System.Version also implements operators so you can use the PowerShell comparison operators. For example lets say you want to compare the current version of PowerShell to determine if its a later release the CTP3. Just using the following statement.

$Version -gt [System.Version]"6.1.6949.0"

Post Your PowerShell Profile!

Posted using ShareThis

For the past several months I have had an issue with my blog, whenever I previewed a post in Windows Live Writer it would crash. I tried changing my theme and upgrading, but it didn’t solve the problem. So I just created a new WordPress installation from scratch. It seems to be working alright. Its still at the same URL as before.

I have recently been following the whole Getting Things Done (GTD) methodology created by David Allen. So far it has actually been helping me get organized. One of the things it mentions is to get tasks out of your head and down on “paper”. Otherwise you will be forgetting tasks and wondering what you are forgetting. Since I am always in PowerShell and most of my tasks now are PowerShell related. You know, “I have to check out PowerBoots” “Wouldn’t it be cool to do feature x in my script?”. So I decided to create a PowerShell advanced function that I can use to create Outlook tasks.

You can grab the code at: http://www.poshcode.org/829

Today we will take a look at the Bitwise Operators in Windows PowerShell and how you can manipulate them for your needs.  First we will get some insight into the enumeration. Let’s begin by looking at the values for the [System.IO.FileAttributes] enumeration which provides attributes for files and directories.

As you can see from the table below each member corresponds to a different attribute that you can apply to files and directories. Some of these are common values that you see daily such as ReadOnly and Hidden, but others are not so common. I won’t go into the meaning of each of these, but if you are interested you can review them on the MSDN site here. Each value, in decimal, is a power of 2 greater than the previous value. To add attributes you add the binary value. So the attributes for a file that is ReadOnly and Hidden would be "1" + "10" = "11" or 3.

An interesting note is that given any enumeration value there can be only ONE possible combination of values that will add up to the enumeration value.

So. Enough for the theory. Let’s have fun.

Determining if an attribute is set

The first task we want to accomplish is checking to see whether an attribute is set on a specified file. In this case we are using a file called "test.txt" with the Hidden and ReadOnly attributes set. First we get the file information and attributes. Then we use the -band bitwise operator to compare the objects.

$File = Get-ChildItem .\test.txt -Force
$File.Attributes
if ( $File.Attributes -band [System.IO.FileAttributes]::Hidden )
{ Write-Host "Hidden Attribute Set" }

With the "-band" operator each binary value is compared and in each position if a 1 is present in both numbers then a 1 is returned. If not, a 0 is returned. So for our example "11 -band 10" is equal to 10 because a 1 is in the second position in both numbers. The way that enumerations are setup dictate two possible values for this comparison. Either the returned value is equal to the attribute being compared or 0, indicating that the attribute is not set.

Setting an attribute

The next task we want to perform is setting an attribute. We are going to use the same file we used in the previous example and set the System attribute. For this task we are going to use the -bor operator.

$File = Get-ChildItem .\test.txt -Force
$File.Attributes
$File.Attributes = ( $File.Attributes -bor [System.IO.FileAttributes]::System )
$File.Attributes

Here, by using the "-bor" operator each binary value is compared and in each position if there is a one present in either number then a one is returned for that position. It’s like a light switch. If it is turned on in either number then it is turned on in the resulting output.  Using this analogy we are flipping on the switch that corresponds to the System attribute.

Removing an attribute

The last task is removing an attribute. For this example we are using the "-bxor" operator. This operator is like a two-way light switch. If you turn on one light switch, the light is on. If you then turn on the other switch, the light turns off.  So you can probably see the issue. If you run the following script a couple of times on the same file you will notice that the System attributes gets turned on or off each time you run it.

$File = Get-ChildItem .\test.txt -Force
$File.Attributes
$File.Attributes = ( $File.Attributes -bxor [System.IO.FileAttributes]::System )
$File.Attributes

This is good if you want to set an attribute to the opposite of the current setting. However if you want to just remove an attribute you will need the following script.


$File = Get-ChildItem .\test.txt -Force
$File.Attributes
if (  $File.Attributes -band [System.IO.FileAttributes]::System)
{ $File.Attributes = ( $File.Attributes -bxor [System.IO.FileAttributes]::System )  } $File.Attributes


We use the "-band" operator to make sure the option is set and then unset it using the "-bxor" operator.