Wednesday, April 27, 2011
Friday, April 22, 2011
Interesting information on Tivoli's Cloud initiatives
https://www.ibm.com/developerworks/mydeveloperworks/blogs/9e696bfa-94af-4f5a-ab50-c955cca76fd0/entry/csp_technical_integration_note_managing_the_core_system9?lang=en
If you're new to Tivoli's Cloud movement, I think the best way to get use out of this paper is to just read about the products that are involved in the total solution. If your company is moving toward the cloud, knowledge of those components will definitely help you.
If you're new to Tivoli's Cloud movement, I think the best way to get use out of this paper is to just read about the products that are involved in the total solution. If your company is moving toward the cloud, knowledge of those components will definitely help you.
Tuesday, March 29, 2011
Passing TCR UserID in BIRT Reports
Many times, you might want to display/determine the TCR user name that is invoking the reports. While there is no GUI way of doing this within BIRT, a simple Javascript is all you need. Here is how to do it in BIRT
- Select a blank area in the report. This should display report properties in the Property Editior.
- Now click on the "Script" tab for the report displayed at the bottom of the main work area. (where Preview/Layout tabs are).
- In the script drop down, select "Before Factory" and paste the javascript code below.
TCR_IUSER = "com.ibm.tivoli.reporting.api.reportEngine.IUserInfo";
userInfo = reportContext.getAppContext().get(TCR_IUSER);
userName = "unknown";
if (userInfo != null) {
userName = userInfo.getUserPrincipal();
} - Now you can use the userName javascript variable in your reports to identify/display the TCR User.
- For example, to display the UserName, insert a "Dynamic Text" item anywhere in your report and enter the following value. "User name = " + userName
Thursday, March 17, 2011
IBM Service Management YouTube channel
This is great - a channel containing lots of fairly technical videos of Tivoli products and integrations:
http://www.youtube.com/user/ismconnect?feature=mhum#p/c/5C4BC71AD2C77801
http://www.youtube.com/user/ismconnect?feature=mhum#p/c/5C4BC71AD2C77801
A great tutorial on ITCAMfT integration with TBSM
TBSM is able to read Discovery Library Adapter (DLA) books from a number of products, including ITM, TADDM, and ITCAM for Transactions (there are others, but I don't know of a comprehensive list). Sometimes the specifics about the integration are dependent upon what other products you have installed, but that is a larger discussion also. This piece from IBM contains extremely useful information on how you can filter the data in the ITCAM for Transactions DLA so that it can be processed more quickly by TBSM and increase the quality of the data in TBSM (by eliminating services that are not important):
The information is great, but you definitely have to do some work before you can just follow along. In the example, they exclude all of the .gif, .css and .jpg components. In many shops, this would work great. However, I've been in some companies that have had problems specifically with .css files being moved/renamed/locked/etc., and those companies would definitely not want to exclude those entities. So before you can just dive in, you need to analyze your business needs and the current state of your components. This could be done in a DEV/QA environment, or possibly in a temporary portion of your TBSM implementation.
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
- 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.
- 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)
- There is no native method to enforce a password expiry of the PIN
- BitLocker can be disabled/paused by anyone with administrative access, thus leaving the system unprotected.
- 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:
- It is free so you are able implement encryption without additional software expense
- When protected, the encryption seems to be as good as any
- Encrypting a drive is relatively quick compared to other vendors
- Recovering a drive is simple as you just need the recovery password from Active Directory
- 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:
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:
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:
- 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).
- 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:
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:
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.
Subscribe to:
Posts (Atom)