Eager to know some "best practices" when utilizing the K2000? Look no further. These practices will not only save you time by avoiding the headache of hunting down enigmatic problems but can also ensure that your K2000 appliance is running at maximum efficiency. So without further ado, let's dive right in:

Use the "start /wait" command when deploying software via K2000 Postinstallation Tasks

When deploying software via an application Postinstall task it is a good idea to begin the task's command line with the "start /wait" command. This command will open a new command prompt and execute the remainder of your command line. The /wait switch ensures that the application installer finishes all of its tasks before ending the task and moving on to the next Postinstallation item. If you notice your deployments are not installing items of software slated for deployment via a PO task, take a look at each task's command line and add "start /wait" (without the quotes) to the beginning of the command line.

Use "call" when utilizing scripts in tasks

Much like the previous best practice, using "call" at the beginning of your command lines that execute scripts is always a good idea. A deployment, whether it be a Scripted Installation or a system image, is orchestrated via a large BAT script on the backend of the K2000. Placing "call" in your command line will prevent the script being called from inadvertently terminating the main BAT deployment script.

Keep 20% free space on the K2000 HDD

We recommend keeping at least 20% of the K2000 hard drive free at all times. The reason we accept this as best practice is two-fold. First, it is possible to over commit the K2000's hard drive, writing more than 100%. This is due to the way FreeBSD, the OS of the K2000, reports HDD space. Over committing the hard drive will result in an unresponsive K2000, so having the buffer zone of 20% free space will grant us some breathing room. Second, whenever a kimage is exported (or any item for that matter), the resulting .pkg is written to \\k2000\restore. The \restore share is simply another directory on the K2000 hard drive. While it's true that the K2000 deduplicates image files when they are stored on the appliance, exporting an image requires writing a unique version for each file contained in that image to a .pkg file saved to \restore. Maintaining the 20% free space buffer zone allows these exports to take place without the chance of over committing the hard drive. Which brings us to our next best practice:

Don't use the \restore share as a permanent backup location

We outlined above that \\k2000\restore is a share located on the same hard drive array as the rest of the data stored on the K2000. Let's pretend a very isolated thunderstorm sends a lightning bolt directly into your K2000's hard drive, the result being a completely destroyed K2000 RAID array. At this point, everything on \restore has been fried along with the rest of the K2000's data. Wildly improbable thought experiment aside, you can see that using \restore as a backup location is a bad idea. Instead, export the items you wish to backup and move them off of the \restore share to a safe location. In fact, the K2000 can do this automatically for you using the Off-board Package Transfer settings located in Settings and Maintenance > Package Management.

Don't delete an image if capturing an image

The K2000 utilizes deduplication technology for storing kimages. If a kimage is deleted while an image capture is taking place, there is a chance that files thought to be pre-existing before the capture took place get removed. The end result is a captured image that is missing files, as those files got deleted when they should have been shared with the newly captured image. Avoid this problem by not deleting kimages unless there is positively no image capture taking place.

Avoid using OEM media with Scripted Installations

This is more of a legal issue than a technical limitation but I think it is worth including in the list of best practices. The OEM licensing model issues a unique Windows license key for each physical system. If OEM media is used to deploy Scripted Installations throughout your environment, make sure that each deployment receives its own unique license key. The ideal model for a Scripted Installation is using volume licensed media in conjunction with either a Key Management Server (KMS) or a Multiple Activation Key (MAK). The results is a no-touch Scripted Installation while still remaining license compliant.

By incorporating these simple practices into your normal operations and being vigilant to not deviate from them you will spend a lot more time basking in the glory of a job well done and a lot less time digging through logs and troubleshooting.