Wednesday, March 9, 2011

BitLocker on Windows 7

What is BitLocker?

Windows Vista and 7 included the BitLocker functionality to allow for encryption of the drive.

Deployment Problem:

According to the Info Center documentation, OSD is BitLocker ready. Well, not really. The idea is that OSD has the capability of creating a partition that will allow BitLocker to be activated. The problem is that when OSD creates the partition it assigns a driver letter to the partition and this is not something that can be there for BitLocker to function.

Solution:

As of Windows 7 (and Vista SP1(?), but who cares), Microsoft included a tools called bdehdcfg.exe that allows for the ability to take any partition, shrink it by a certain amount and prepare it for BitLocker. In order for BitLocker to work, it requires a minimum of 100MB or 300MB if you also want the recovery console (For Vista this is 1.5 GB). In order to do this, just use a software module that is deployed with the image to execute the bdehdcfg command.

One thing to note with this solution, when the image is deployed, you will end up with a larger partition than expected. The reason for this is that when the bdehdcfg command is executed, the partition ends up being created at the end of the drive and when OSD is completed, it takes the cache partition (about 500MB) and adds it to the last partition on the drive. So if you are defining bdehdcfg to create a 300MB partition, you will end up with a 800MB partition (approx). Currently the only way around this is to have the bdehdcfg execute after the OSD deployment is completed.

BitLocker sounds simple enough to implement, but there are some things to think about that will impact the business

  1. The PIN is used to provide an additional level of security to the BitLocker process. This PIN is set to the computer not to the user(s) of the computer, so if there are multiple users of the system, then they all share the same PIN.
  2. The PIN can only be set with someone with Administrative access. (I have not personally confirmed this, but I was informed of this by an engineering group, so if this is incorrect, please let me know and I will remove)
  3. There is no native method to enforce a password expiry of the PIN
  4. BitLocker can be disabled/paused by anyone with administrative access, thus leaving the system unprotected.
  5. Will require processes to be put in place when users forget their PIN (you know it will happen) and provide the recovery password. This is possibly the hardest part depending on the users and the number of users.

On the plus side:

  1. It is free so you are able implement encryption without additional software expense
  2. When protected, the encryption seems to be as good as any
  3. Encrypting a drive is relatively quick compared to other vendors
  4. Recovering a drive is simple as you just need the recovery password from Active Directory
  5. Did I mention it was free?

Hope this helps you out :)

If you have any other topics you would like covered, send me a note at martin dot carnegie at gulfsoft dot com.

Deploying Windows 7 with TPMfOSD

Recently I have been involved in using TPMfOSD to capture and deploy Windows 7 images. There is quite a bit of information available on the web and on IBM’s Info Center, but at times we found that there are certain areas that are not completed enough.

I have been working through the Devworks site with various people and thought I would also give back some information. Since this was too big for Devworks, I thought a blog would be best.

At a high level, here is what I did:
1. Importing Windows 7 DVD for Unattended Install
2. Preparing the OS Configuration for Unattended Install
3. Deploying the Unattended Install
4. Customizing Master Image
5. Executing sysprep
6. Capture Clone Image
7. Modifying the OS Configuration for Clone Install
8. Deploying the Cloned OS

For my environment, I am using VMware Workstation to create my profile. There are many advantages of using VMware rather than physical hardware such as:

1. The image does not contain any drivers for the physical hardware. Windows 7 can be installed on VMware with almost no extra drivers (depending on the vm hardware defined)

2. Simple and quick to restore an image with the snapshots rather than using OSD to capture the “Golden Master”

3. Multiple snapshots can be created to backup and restore during various stages

4. The restore of an image can be done to any system that has VMware installed, as long as the hardware is setup the same. So the VM image can be built on Lenovo/HP/Dell/etc hardware

When using VMware, I also add the setting bios.bootdelay=15000 to the .VMX file to allow time to press the F12 key or ESC for the boot menu.

Before starting on this, one big note is around the Built-in Administrator name that is used. When installing Windows 7, you are prompted to create an id that will be an administrator on the system. When this user is created, it will be added to the Administrators group and the Built-in administrator will be disabled. In order to get the Built-in administrator enabled, you need to set the Administrator name in the OS profile to “Administrator” (has to be this no matter what you want the id to actually be). For this example, I will be changing the Built-in administrator to “myadmin” and show how to make this will work.

1. Importing Windows 7 DVD for Unattended Install

This was fairly simple. Just use the New Profile > Unattended Setup and walk through the wizard.

Info Center documentation:

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.tivoli.tpm.osd.doc/deploy/tosd_createunattended_win.html

2. Preparing the OS Configuration for Unattended Install

Once the import is complete, open the OS configuration, go to the Windows tab and set the "Administrator Name:" field to Administrator. Also verify that the time zone is set. If you are using volume licensing, then select the “Volume licensing” option. If not, then set the serial number.

3. Deploying the Unattended Install

After the unattended install system profile is created, it can be deployed to a target system in order to create the clone profile. The methods to deploy an unattended or cloned profile are exactly the same. The big difference is the time for installation. The unattended install is significantly longer to complete than a cloned image.

Info Center documentation:

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.tivoli.tpm.osd.doc/deploy/tosd_startdeployment_win.html

4. Customizing Master Image

There are many options to configure in the image such as included software, user ids, local policies, etc. Also remember that software modules can be used to customize an image after deployment, so make sure what is included will not require you to make more updates to the image than necessary.

Some of the deciding factors for what to do in the image vs in a software module:

- will the software take too long to deploy in a software module. For example:

- MS Office, this product takes a very long time to run through installation than it does to have included in the image

- Adobe Flash, this product is quick to install but is updated quite regularly, so it is probably better to have in a software module.

- Antivirus applications. Since these are core to protecting the corporate environment, they should be in the image. This is because there could be a failure installing the software module which would end up leaving a system unprotected.

The Windows 7 image is quite large even without any software installed, so whatever can be cleaned to minimize this image would be a good idea. Typically I would include any patch backups as this could shrink an image by 1GB or more.

As stated, I have changed my Administrator (SID 500) account to myadmin. This is a typical configuration that most sites will do. There are a couple “quirks” that happen when you do this:

  1. After the change, the user directory on the system will be C:\Users\Administrator. When you deploy the image, the directory will be changed to C:\Users\myadmin. You cannot change the directory name on the original image (you can Google it).
  2. As stated earlier, when setting the OS Configuration in step 7, you have to set the Administrator Name to “Administrator”. If you do not, the system will be deployed with the “myadmin” account, but it will not be the SID 500 account, it will just be an id in the Administrators group. The SID 500 will be called Administrator and it will be disabled. When set correctly, the “myadmin” will be the SID 500 account and another account called “Administrator” will be added to the Administrators and Users groups. For my deployment, I included a software module that would remove it from both groups and disable the account.

Another issue that I ran into was that I deleted the C:\install directory. This is created by the unattended install. When deploying an image to the target, the c:\install directory would be created, but when executing software modules later in the build process, they would not execute. This is being addressed in a future fix (not in FP04). To workaround this issue, just leave the c:\install directory in the image.

5. Executing sysprep

Once the unattended install is complete, the system can then be configured with any corporate software and configurations. After all configurations are completed, the next step is to use the Microsoft tool called Sysprep. This tool is used to remove system specific configurations to allow for a cloning of an image to different systems.

http://technet.microsoft.com/en-us/library/cc783215%28WS.10%29.aspx

Unlike Windows XP, sysprep is already on Windows 7 and is located in C:\Windows\System32\Sysprep. The options selected are OOBE, Generalize and Shutdown. I prefer using the shutdown as I do not want to miss the reboot and have the mini-setup run again.

Info Center documentation:

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.tivoli.tpm.osd.doc/deploy/tosd_ref-compwinvista.html

Notes:

A system that is joined to a domain cannot be used for creating a cloned profile. If the system has been joined to a domain, then it has to be moved to workgroup mode.
- Some extra recommended tasks are:
- Empty recycle bin
- Execute chkdsk to ensure there are no disk error
- Clean out temporary files
- Remove any persistent drive mappings
- Clear the Application, Security and System event logs
- Sysprep still has the limit of being executed 3 times in Windows 7.

6. Capture Clone Image

Capturing the Windows 7 OS is no different than the methods used for any other operating system. The process is quite a bit longer than Windows XP and requires more reboots, but overall the whole process is the same.

Info Center documentation: http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.tivoli.tpm.osd.doc/deploy/tosd_clone_win.html

7. Modifying the OS Configuration for Clone Install

Once an image is imported, the OS configuration will need to be set. The OS Configuration is where you use OSD to set the parameters that will be used in the unattend.xml file. The UI will allow for the configuration of many of the common settings, but if there are more that are required, use the “Edit custom unattend.xml” on the General tab. When setting the OS configuration, the most important item to set is the “Administrator Name” to “Administrator”. This is done by opening the properties for the OS configuration and going to the Windows tab. Also on this tab in the “System Customization”, check the setting “Always authorize installation of unsigned drivers”.

8. Deploying the Cloned OS

Deploying the Windows 7 OS is no different than the methods used for any other operating system. The process is quite a bit longer than Windows XP and requires more reboots, but overall the whole process is the same. One thing that did happen in Windows 7 and not XP is that OSD actually logs into the OS. This causes some issues with scripts that may be in the run/runonce/startup.

Info Center documentation:

http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.tivoli.tpm.osd.doc/deploy/tosd_clone_win.html

Other Notes:

TPMfOSD started supporting Windows 7 in 7.1.1.1, but this version and 7.1.1.2 use the WinPE2. There are some pretty significant improvements in using 7.1.1.3 or better yet 7.1.1.4 as it utilizes WinPE3 for the deployments. If you have not started, or are just starting, then move to one of these versions. There are other reasons for moving to these newer versions, but this is one of the most visible from a deployment perspective.

Conclusion

As noted, this is a fairly high level of using OSD for Windows 7 deployments, but should start you on the right path.


Remember, we at Gulf Breeze Software Partners are ready to help you with your implementations on TPMfOSD or any IBM Tivoli product

If you have any other topics you would like covered, send me a note at martin dot carnegie at gulfsoft dot com.

Monday, January 31, 2011

GbsTask - A Task Management Utility for ITM

Introduction
In Tivoli Management Framework, there is a concept called "Task". Tasks let users to specify executable for a specific platform at the creation time. When a task is run against multiple targets ("endpoints"), the appropriate executable is transferred and executed on the remote system and the output is presented in the standard output. When executed on multiple targets, the execution is done in multi-threaded manner.

We, at Gulf Breeze, developed a Java based solution to implement the task feature in Tivoli Monitoring product and this article discusses about this solution in detail. If you are interested, please email me and I will send you a free copy.

Benefits
  • A Simple database driven tool to create/update/delete/execute tasks.
  • Tasks can be executed on individual OS agents or on ITM MSLs.
  • Tasks can be executed in a multi-threaded manner across agents of different platforms.
  • Supports SQLServer or DB2 databases to store task information.
  • Authorization information kept in a separate file and can be specified with -a switch. You don't need to specify the password in your scripts.
Limitations
  • Maximum number of threads is limited by the maximum number of "tacmd"s that can be run in parallel. Running more than this limit could cause stability issues. As of ITM 6.2.2. FP2, the maximum number of threads is 10.
  • Currently the tasks can be executed only against Windows, Linux and Unix OS agents.
Requirements

To run the "gbstask" solution, you will need the following. The solution is tested with SUN JRE 1.5 and "should" work in other implementations of Java Runtime.
  • JRE 1.5 or later. (The code will NOT work with JRE 1.4).
  • JDBC driver for your database.
  • Tacmd CLI. (The CLI is installed with an OS agent installation or ITM TEMS installation).
  • A SQL Server or DB2 database where you can create a table to contain task information.
Examples

The following command creates task called pingtask for Linux and Windows.
# Creates tasks for Linux and Windows
C:\temp>java -jar GbsTask.jar -a db2.auth -c -l mylib -t pingtask -o Linux -f C:\temp\test.sh
C:\temp>java -jar GbsTask.jar -a db2.auth -c -l mylib -t pingtask -o Windows -f C:\temp\test.bat
# Executes a task on specific managed systems.
$ java -jar GbsTask.jar -a db2.auth -x -l mylib -t pingtask -h Primary:VMTBSM421:NT,vmitm622:LZ,Primary:VMTBSM42X:NT
# Executes a task on specific MSLs.
$ java -jar GbsTask.jar -a db2.auth -x -l mylib -t pingtask -m "*NT_SYSTEM,*LINUX_SYSTEM"
# Deletes a task
$ java -jar GbsTask.jar -a db2.auth -d -l mylib -t pingtask -o Windows
$ java -jar GbsTask.jar -a db2.auth -d -l mylib -t pingtask -o Linux


Sample Output

$ java -jar GbsTask.jar -a db2.auth -x -l mylib -t pingtask -h Primary:VMTBSM421:NT,vmitm622:LZ,Primary:VMTBSM42X:NT
---Begin Task Output for ManagedSystem vmitm622:LZ
PING 192.168.75.21 (192.168.75.21) 56(84) bytes of data.
64 bytes from 192.168.75.21: icmp_seq=1 ttl=128 time=0.276 ms
64 bytes from 192.168.75.21: icmp_seq=2 ttl=128 time=0.255 ms
64 bytes from 192.168.75.21: icmp_seq=3 ttl=128 time=0.168 ms
64 bytes from 192.168.75.21: icmp_seq=4 ttl=128 time=0.221 ms
--- 192.168.75.21 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.168/0.230/0.276/0.040 ms
---End Task Output for ManagedSystem vmitm622:LZ
---Begin Task Output for ManagedSystem Primary:VMTBSM421:NT
C:\WINDOWS\system32>ping 192.168.75.21
Pinging 192.168.75.21 with 32 bytes of data:
Reply from 192.168.75.21: bytes=32 time=1ms TTL=128
Reply from 192.168.75.21: bytes=32 time=1ms TTL=128
Reply from 192.168.75.21: bytes=32 time=1ms TTL=128
Reply from 192.168.75.21: bytes=32 time=1ms TTL=128
Ping statistics for 192.168.75.21:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
---End Task Output for ManagedSystem Primary:VMTBSM421:NT
---Begin Task Output for ManagedSystem Primary:VMTBSM42X:NT
C:\WINDOWS\system32>ping 192.168.75.21
Pinging 192.168.75.21 with 32 bytes of data:
Reply from 192.168.75.21: bytes=32 time=1ms TTL=128
Reply from 192.168.75.21: bytes=32 time=1ms TTL=128
Reply from 192.168.75.21: bytes=32 time=1ms TTL=128
Reply from 192.168.75.21: bytes=32 time=1ms TTL=128
Ping statistics for 192.168.75.21:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
---End Task Output for ManagedSystem Primary:VMTBSM42X:NT

Interested?
Interested? Please email me at venkat at gulfsoft.com and will send you a free copy of this tool. You can download the documentation for this tool from the link below.

Tuesday, December 21, 2010

Adding a custom Java portlet to the TIP for use with WebTop, WebGUI, TBSM, etc.

REMOVED


This article has been removed because it worked for very specific versions of products, but not for the latest versions, and customers were calling Tivoli support to open PMRs when it didn't work. If you're trying to add a portlet, this is CUSTOM work, for which you should not open a PMR.

So I'll revisit this issue when I have time to test with the latest and greatest versions. Until then, if you would like the article, you can send me an email at frank dawt tate aat gulfsoft dot com.

Thursday, October 7, 2010

Using Tivoli Software Package Blocks in BigFix Enterprise Server v8 – Part 2

Now that the Disconnected Command Line (DCLI) is in place, it is time to start defining the SPBs.

At a high level the steps are:

  1. Create a site for Tivoli Software Packages and set the relevance
  2. Use the Software Distribution Wizard to import the SPB
  3. Modify the new task to use the correct syntax (wdinstsp)

I will not cover the creation of SPBs in this blog as if you are interested in using BF for SPBs you are probably already familiar with them.


Create Tivoli Software Packages Site

For this example, I found that it is best to create a specific site for the SPBs so that we can also set the subscriptions using relevance to check for the existence of the DCLI.

  1. Navigate to the Systems Lifecycle domain
  2. Navigate to All Systems Lifecycle > Sites
  3. Right click in the List Panel and select “Create Custom Site…”
  4. Set the name to “Tivoli Software Packages”. Press the OK button
  5. Click on the “Computer Subscriptions” tab
  6. Select the “Computers which match the condition below”
    1. Set the property to “Relevance Expression”
    2. Set the operator to “is true”
    3. Press the “Edit Relevance…” button and enter the text exists file "C:\Program Files\Tivoli\disconn\w32-ix86\classes\swdis_env.bat". Press OK
  7. Press the Create button and enter your password

Use the Software Distribution Wizard to import the SPB

For this example, I am using a simple software package that deploys the Orca.msi. This was created using the Software Package Editor with the MSI Wizard.

I have also been doing some work on using the Sha1.exe (http://support.bigfix.com/fixlet) and BfArchive.8.0.0.exe (http://support.bigfix.com/cgi-bin/kbdirect.pl?id=452) which will allow for the use of the sha1 keys.


Using the Wizard to create the task

  1. Navigate to Systems Lifecycle > All Systems Lifecycle Wizards
  2. Click on Windows Software Distribution Wizard
  3. Replace the with Orca and press the Next button
  4. Select the File option and browse to the SPB file. Press Next
  5. Set the desired platforms. Press Next
  6. Set the target relevance to us the Registry Key: "HKLM\Software\Microsoft\Windows\Uninstall\{63A68338-16A3-4763-8478-A45F91A61E7A}". Press Next
  7. Leave the command line alone for now as this will be modified later. Press Next
  8. Review the summary and press Finish


Manually modify the task to use the wdinstsp command

  1. Set the “Create in site” to “Tivoli Software Packages”
  2. Click on the Actions tab
    1. Replace the “wait __Download\orca.spb” with the following lines

appendfile call "c:\program files\tivoli\disconn\w32-ix86\classes\swdis_env.bat"

appendfile wdinstsp.exe -f __Download\orca.spb

copy __appendfile __Download\orca_install.bat

wait __Download\orca_install.bat

  1. Click the Relevance tab and verify the value. For this example, the value was (name of it = "WinXP" OR (name of it = "Win2003" AND NOT x64 of it)) of operating system AND (not exists key "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall {63A68338-16A3-4763-8478-A45F91A61E7A}" of native registry)
  2. Click on the Properties tab and set the source to “Software Distribution SPB”. This is done just to create a separate folder for viewing “By Source”
  3. Press the OK button and enter the password


Now that the task has been created, it is just a matter of taking action and deploying like any other task.


This takes care of the setup for deploying software packages blocks using BigFix. There are a few other items that would need to be added this to make it really production ready, but I cannot give away everything ;)


If you have any questions/comments, feel free to comment on this blog or email me at martin dot carnegie at gulfsoft dot com.

Monday, October 4, 2010

Using Tivoli Software Package Blocks in BigFix Enterprise Server v8 - Part 1

After doing some work with BigFix, I started investigating methods of implementing the use of SPBs into BigFix. After a little bit of trial, I have developed a fairly simplistic way to achieve this.

At a high level, the steps are
1. Create a standalone copy of the disconnected command line (DCLI from now on)
2. Create a task to deploy the DCLI
3. Create baseline to deploy DCLI to desired targets
4. Create tasks to deploy SPBs and executed with the DCLI


Create a standalone copy of the DCLI
The DCLI is a facility provided with TCM to allow package builders the ability to test SPBs locally on a test system. This is used to make sure that a package is behaving as desired without having to import into TCM and use the framework to install. By using the DCLI, a package builder is able to make changes to a package and “redeploy” in a relatively quick manner. Once a package installs with the desired effect via the DCLI, it is then imported into TCM for further testing. For products such as TPM, TPMfSW and the now defunct TPMDSD/TEM, this standalone method was what was being used.

In order to create a standalone version, you will first need to have the Software Package Editor as this contains the binaries required for the DCLI. You will also need the Tivoli Endpoint installed (this is a requirement for the SPE anyway) as this will have a couple DLLs that are also required. Once you have the SPE installed, follow the instructions below to create the image

1. Create a directory called C:\Program Files\Tivoli\disconn
2. Copy the directory C:\Program Files\Tivoli\swdis\speditor\w32-ix86 to the directory created in step 1. Note that the swdis directory may be installed in a different directory.
3. Edit the file C:\Program Files\Tivoli\disconn\w32-ix86\classes\swdis_env.bat and set it to the following:
set INTERP=w32-ix86 set speditor_dir=C:\Program Files\Tivoli\disconn\w32-ix86\classes set speditor_lib_path=C:\Program Files\Tivoli\disconn\w32-ix86\classes\..\lib set speditor_bin_path=C:\Program Files\Tivoli\disconn\w32-ix86\classes\..\bin set Path=%speditor_dir%;%speditor_lib_path%;%speditor_bin_path%;

4. Copy the following files from C:\Program Files\Tivoli\lcf\bin\w32-ix86\mrt to c:\Program Files\Tivoli\disconn\w32-ix86\lib. Note: this list was created based on some testing of simple packages. There maybe more of these DLLs required.
a. Libcpl60.dll
b. Libdes60.dll
c. Libguid60.dll
d. Libmem60.dll
e. Libmrt60.dll
5. Optional: cleanup extra binaries that are not required for the DCLI
a. In the C:\Program Files\Tivoli\disconn\w32-ix86\classes directory, remove all files except swdis_env.bat
b. Remove the C:\Program Files\Tivoli\disconn\w32-ix86\msg_cat directory

This will be the working copy of the DCLI that will be used to import into BigFix. I have found other methods that can be used to import, such as using Winzip, but for now let’s stay with the importing of files and folders built into BigFix.

Create a task to deploy the DCLI


In the previous section the files that are required for the DCLI were identified and made ready for importing into BigFix. Now these tools need to be imported into BigFix and made ready for deployment.

In this section we will take the image created of the DCLI and build a Task out of it. This task will be under the Systems Lifecycle domain and then create a baseline to apply the Task to all computers.

1. Copy the DCLI files to the BES Server. For this example, they have been copied to C:\CID\disconn
2. Navigate to Systems Lifecycle > Wizards > All Wizards > Windows Software Distribution Wizard
3. Set the application name to Tivoli Disconnected Command Line. Press Next
4. Choose the “Folder” option and browse to (or type) C:\CID\disconn. Check the “Include Subfolders”. Press Next
5. Choose the operating systems that are desired for support. This should work for any platform that TCM supports in Windows, but this was only tested on Windows XP and 2003.
6. Set the target relevance to use the File option and set to C:\Program Files\Tivoli\disconn\w32-ix86\classes\swdis_env.bat.
7. In the “Full command line”, leave it with the setup.exe for now, this will be modified later.
8. Review the summary and press “Finish”

The wizard is now complete and the task will be displayed. From here, we need to make some custom modifications to extract the files/dirs and put them in C:\Program Files\Tivoli

1. In the Create Task dialog, select the Actions tab
2. Make the following changes:
a. Remove the line: wait __Download\setup.exe
b. Add the line: dos mkdir "C:\Program Files\Tivoli\disconn"
c. Add the line: dos move /y __Download\w32-ix86 "C:\Program Files\Tivoli\disconn"
3. Press the Edit button beside the Include custom success criteria”
4. Select “…the following relevance clause evaluates to false” and enter the string not exist file "C:\Program Files\Tivoli\disconn\w32-ix86\classes\swdis_env.bat". Press OK
5. Set the “Create in site:” to Master Action Site, and set the “Create in domain” to Systems Lifecycle. Note: the site could be made to something else, but for this example, we will just use the default. Press the OK button and enter the key password

The task is now created for deploying the Tivoli Disconnected Command Line to targets. Now that this is created, the next step is to deploy this task to the desired computers.


Deploying DCLI to targets

The task has now been created, what next? Well, we need it to get out to the targets so that we can then deploy SPBs. For this example, I will not be using any real complex targeting, I just want to get it out. Targeting is another discussion all together (which we kind of hit on when we go to deploy the SPBs). For my lab, my target computers all start with the name “win2kcli”, so what this example will do is create a site to do just that. Then create a baseline to target all the computers that are subscribed to the site and apply the DCLI as a policy.

Create custom site
1. Navigate to Systems Lifecycle > All Systems Lifecycle > Sites > Custom. Right click in the List Panel and select Create Custom Site
2. In the Create Custom Site dialog, enter “All WIN2KCLI Computers”. Press OK
3. This will create the new site and display it in the List Panel. From here the subscription needs to be set. Select the “Computers which match the condition below”
a. Set the property to “Relevance Expression”
b. Set the operator to “is true”
c. Press the “Edit Relevance…” button and enter the text computer name as lowercase contains "win2kcli". Press OK
4. Press the “Save changes” button and enter password.

Now that the custom site is created, target computers will start appearing under the site’s “Subscribed Computers”

Create Custom Group
In order to target for the baseline, a computer group needs to be created. This group will be assigned the same relevance as the site.

1. Navigate to Systems Lifecycle > All Systems Lifecycle > Sites > Custom > All WIN2KCLI Computers > Computer Groups
2. Right click in the List Panel and select “Create Automatic Computer Group”
3. Set the Name: All WIN2KCLI Computers CG
4. Create in site: All WIN2KCLI Computers
5. Create in domain: Systems Lifecycle
6. Set the relevance field to “Relevance Expression”
7. Set the condition to “is true”
8. Press the “Edit Relevance…” button
a. Enter: computer name as lowercase contains "win2kcli"
9. Press the Create button and enter your password

Create Baseline
The site has been created and the subscriptions set, now the baseline policy needs to be set to deploy the DCLI.

1. Navigate to Systems Lifecycle > All Systems Lifecycle > Sites > Custom > All WIN2KCLI Computers
2. Right click in the List Panel and select “Create New Baseline…”
3. Set the Name to “Deploy DCLI”
4. Set the Description to “Deploy Tivoli Disconnected Command Line”
5. Click on the Components tab (image create_baseline_2.jpg)
a. Set the Group Name to DCLI and press Save Group Name
b. Click on the “add components to group” link and press the Tasks tab
c. Navigate to All Tasks > By Source > Software Distribution Wizard and select Software Distribution – Deploy: Tivoli Disconnected Command Line and press OK
6. Click on the Relevance tab and select “Computers which match all of the relevance clauses below”. Set the clause to: not exist file "C:\Program Files\Tivoli\disconn\w32-ix86\classes\swdis_env.bat".
7. Set the Create in site to All WIN2KCLI Computers
8. Press the OK key and enter password

Activate Baseline
With the new baseline created, it now needs to be activated. Since we need to be on all the computers we need to set this as a policy.

1. Navigate to Systems Lifecycle > All Systems Lifecycle > Sites > Custom > All WIN2KCLI Computers > Baselines
2. Select the “Deploy DCLI” baseline
3. Press the “Take Action” button
4. In the “Preset” field, set it to Policy
5. On the Target tab, select the option “All computers with the property values selected in the tree below
6. Expand to All Computers > By Group and select All WIN2KCLI Computers
7. Press the OK button and enter the password

This takes care of the DCLI. This is currently a proof of concept and I need to do some more testing to verify that I have set the various properties/groups/etc. If you have any comments/suggestions, please post a comment on this blog.

For the next blog entry, we will take a SPB and import it into BigFix. Stay tuned, it will be posted in a couple days.