Miscellaneous Tips and Tricks for Using Deployment Solution for Dell Servers 3+

After using a product for awhile, you tend to learn a few tricks that save time. Unfortunately it may take you doing a certain action dozens of times before finding a better way. This article is meant to be a miscellaneous compilation of little tricks that I learned over time that save time and frustration when deploying machines with Deployment Solution for Dell Servers 3+.

Tip 1: Make it a habit of upgrading your firmware using the DUPs in automation jobs.

Many people have no idea what a DUP is, or how to use the "Apply DUP" jobs. Before version Deployment Solution for Dell Server 3.0 SP1, running a DUP was generally forgotten, and could only be done after an OS was installed. This was putting the cart before the horse in many cases because upgrading the firmware is something you do to make sure the installation of the OS goes smoothly. With the introduction of the "Apply DUP in automation" jobs you can just set the job to run before a deployment (providing you have downloaded the DUPs with the configuration utility) and forget it. The job automatically applies the latest DUP that applies to your hardware from the selection of DUPs you've downloaded.

Making sure the firmware is updated has fixed many of my deployment problems. For instance, I once was having trouble with the SCSI card hanging on boot up. Upon investigation, I discovered that a simple firmware upgrade was all I needed, and so I used the "Apply DUP in automation" job to update all my machines, and haven't had any trouble since.

Tip 2: Use the job builder.

The Job Builder, introduced in version 3.0 is an incredible tool to build custom jobs, as well as giving you a starting point for customized jobs. It gives you access to every step of the Bare Metal to OS process and I often use it to create jobs that use a combination of Linux and WinPE, or even for non-deployment situations where I just need a good starting point.

Tip 3: Use return code handling to anticipate errors

Return code handling allows your jobs to perform a predefined action in response to the result of another action. This allows your jobs to be more reactive, hands free can save you some time. For instance by default every time a task executes in automation it will go to the next task only if it was successful. But what if there was an error? By default the job will fail with a red X, and the machine will reboot... why? Because the job was set to "stop" execution on failure, and when a machine has no more tasks to execute in automation it boots to production. This can be a headache in a few different ways: first, you will have to reboot back into automation to troubleshoot the problem; second, chances are you didn't sit and watch your console waiting for errors, so if the machine you're dealing with doesn't have an OS it is stuck in an unmanaged state. Then, you either have to reboot it remotely (if you're lucky), or send an intern out to locate the machine and reboot it manually.

A great solution to this problem is if you have any suspicion that a job will fail, "guard it" with a "wait in automation" task. Let's learn how to do this by looking at a job in the "1.1 Capture Configuration Input Files" which are all "guarded"; specifically the the "Get RAID Configuration File" task.

Click to view.

As you can see, after the Run Script task, there is a wait task which causes the machine to wait in automation if the run task was successful. If we double click the run script task and go to the third page of the wizard we see:

Click to view.

You'll notice that the "Default:" field which by default is "stop" has been changed to "Wait in Dell Linux". What this means is that if the job fails, it will run the "Wait in Dell Linux" job defined in the Dell Samples Folder. You can select any arbitrary job to run in case of failure by choosing "Select a Job.." from the drop down.

Click to view.

With this job guarded with wait tasks in this way, we can be assured by running it, we will never put this machine into an unmanaged state.

Tip 4: Use job conditions

Why have two jobs when you can have one? Job conditions allow you to branch job execution when certain conditions are found. Certain jobs in Deployment Solution for Dell Servers already use conditions, let's look at one of them. Open the "3.1 Apply Dell Update Packages (DUPs)" folder and select the "3.1.1 update RAID Drivers and Reboot" job.

Click to view.

If you click the "Condition" drop down, you'll notice three entries, "default", "Linux", and "Windows". Change the selected condition from "default" to "Windows".

Click to view.

Listed are the jobs that will run if the machine this job is scheduled on is running Windows. Similarly, the entries listed when the "Linux" condition is set will run when the machine it runs on is a Linux machine. The "default" condition will be run if the machine has no OS.

Let's quickly look to see how these conditions are made. Click "Setup->Modify".

Click to view.

In this window you can define a number of conditional statements based off of information found in the database. Note: The database contains static information. If you want to branch execution based off of information discovered at runtime, use the return code handling mechanism. See Tip 3.

So instead of having one job for Linux machines, and one for Windows machines, I can combine these jobs into one job and simplify my console, and how I schedule jobs.

Tip 5: Add a production task to the end of a Scripted OS install to better determine when the job is complete.

Whenever a Scripted OS install job is run it will complete when it's tasks are done, not necessarily when the installation is complete. It can sometimes take upwards of an hour (depending on which OS you are installing) after you seen the green check mark for the machine to connect back to DS. Sometimes you might want to know how long it actually took to deploy the OS, or you simply don't want the green check mark until it's actually done. Whatever the reason, just simply add a production run script jobs with one line of text ( "echo Hello" ) as the last task in your long string of deployment tasks within the job. With that last production task in place, the job will still show as running until the OS is up and running and has connected back to DS.

Tip 6: Do dry runs of rule based raid configurations

Many users are reluctant to use Rule Based Raid configuration available in the Job Builder because they don't know if they've written their rules correctly. An unwritten rule may delete unwanted data, and so for these situations I'd suggest performing "Dry Runs" of the raid rules. This can be done quickly and easily by using the job builder, and by consulting the log.

Step 1 - Know where the logs are

Log are located within the eXpress share under "Dell\alogs" and are named according to the machine ID. You can discover the machine ID by double clicking a machine in the console. The ID is listed under the "General" section (example: 5000001).

Step 2 - Create a Rule Based RAID job using the Job Builder.

Actually creating the rule based RAID configuration is simple, but you might benefit from some guidance from the documentation.

Step 3 - Create a Dry Run Job

Make a copy of the rule based RAID configuration job you just made with the job builder, and delete all tasks after "Delete Existing RAID configuration"

Click to view.

Add a "Wait task at the end" by clicking "Add>>Wait", and select the preboot you are using (Linux or WinPE). This allows you to run several tests back to back without having boot over and over into automation.

Lastly, we don't want our machine rebooting if the our rule doesn't match. Therefore, double click the "Evaluate RAID rules" task and go to the third page of the wizard. Set the drop down after "Default:" to "Continue".

When you're done your job should now look like this:

Click to view.

Step 4 - Run the job and view the output.

It should get a green checkmark, and the machine will go into a wait state. Open the log file and you'll see something like the following:

Found the following array disks on controller 0 
0:0:1,0:1:1 
Comparing server RAID controllers to RAID rules and generating scripts. 
Running command: 
.\Dell\atools\eros.exe Test_RAID_configure.xml 5000005_raid.xml linux 5000005 
RuleListCount: 1
Evaluating rule
	Priority list
		raidRule controller count: 0
		serverRule controller count: 1
		Found match for controller: 0
		Rule matches
Applying matched rule to server and generating scripts
Processing controller 0
	Inserting the following commands for delete:
	$DELETE_SCRIPT 0
	Inserting the following commands for create:
	$DYN_CREATE_SCRIPT 0 0:0:1,0:1:1 2 NONE NONE
 

The second line is a comma separated representation of the disks that were found. The first value in the triple is the controller number, the second is the disk number. If we look a little lower we can see the beginning of the rule evaluation, and the key piece of text to look for is "Rule Matches".

Here's an example of a the log output when a rule did not match:

Found the following array disks on controller 0 
0:0:1,0:1:1 
Comparing server RAID controllers to RAID rules and generating scripts. 
Running command: 
.\Dell\atools\eros.exe Test_RAID_configure_2.xml 5000005_raid.xml linux 5000005 
RuleListCount: 1
Evaluating rule
	Physical Order
		Rule doesn't match
Error: No rules match this system's configuration

Conclusion: As time permits I may add more tips in additional articles. Feel free to add comments with your own tips too!