Tag Archives: Kloser look

Sep
26
2012

K1000 Kloser Look: Using the K1000 Resources Feature

Posted on September 26, 2012 by Christopher Blake

The K1000 has the ability to import or export Resources. While this is often an overlooked feature, it can be an excellent utility for various purposes. These resources can be E-Mail Alerts, Managed Installs, Processes, Queues, Reports, Scripts, Smart Labels, Software Inventory, and Custom Ticket Rules.

So, if you have a specific software installer or one of the other items available for import/export you can export and save them. This could be for a very specific backup purpose, or archiving older tasks off of the appliance for care & feeding, but it is mostly designed for sharing information between Org’s if you have a K1200, or multiple appliances if you have more than one, and other K1000 customers to reduce the amount of work we all do!

If you are exporting resources they will be placed on the \\kboxhostname\clientdrop. If you are importing resources you will need to place them at this same location. If you are exporting resources for archiving or sharing, don’t forget to delete the files after you’re finished moving/sharing them.

 

Posted in New Posts | Tagged , , | Leave a comment
Jul
16
2012

K2000 Kloser Look: Providing Windows 7/Vista/2008 Licenses in a Scripted Installation

Posted on July 16, 2012 by Christopher Blake

The goal of most K2000 administrators is to have a fully automated installation process that is easy to maintain. Scripted Installations fit the bill- they are fast (typically, 2x-10x faster than other images), flexible, hardware independent, and simple to modify. However, the purpose of this article isn’t to sell you on Scripted Installations so we’ll leave it at that and hope you’re already using them to be as agile as possible for your users.

One possible hurdle that one may encounter when setting up a Scripted Installation is figuring out how to provide the license key and activate Windows. Unfortunately, the answer is not as straight forward as it once was. You see, things change, and Windows Licensing is no exception. Due to piracy, administrative needs, and many other factors, Microsoft has introduced multiple methods for licensing Windows. Let’s take a look at the methods and talk about how to utilize them when preparing scripts to install Windows 7/Vista/2008.

A successful answer file requires no intervention. The most rational thing to do is to put your license key into the answer file, correct? Maybe not… Previous versions of Windows required a key and the K2000 Answer File Wizard has an enticing text box for it in the wizard. Logically, you are compelled to enter the key. Please read on before doing so though; It may seem counter-intuitive, but the best thing to do is to choose a KMS key (yes, even if you aren’t using KMS) and change it with a postinstall task after the OS installs; or leave the license key field blank in the Wizard or set it to /Image/Name and value of Product Name in the answer file you created.

Unlike Microsoft Windows XP, which can’t be installed without the key, Windows 7 can be (and even does better without it).  Having the Win7 key in your answer file typically causes problems ranging from a complete failure, to a prompt for the key during the installation.

What should you do? First you need to understand the relationship between your source media and key type. Installation disks and key types are not interchangeable. Using the same type of key and media is required. What do I mean, well the OEM disk that came with your computer won’t work with your Volume License key. Likewise, the Volume Media that you downloaded from Microsoft doesn’t work with an OEM key. The type of media you use determines how you should provide the license key and activate Windows. The following are some guidelines:

  • Retail key: A single key for one computer. Typically this is a small organization that does not have a high volume of installations. Most customers with retail keys choose to install a trial version and manually enter the key (answer file with no key and specified Product Name). Alternatively, you can modify your answer file and enter the new key before each installation (leaving out the product name/image type).
  • OEM key: Single computer license used to install Windows 7 at the factory. Typically, used by medium size organizations trying to leverage the license that came with the computer. While this might be the easiest purchase option due to price and availability, this can be the most difficult to administer and deploy in many environments. If OEM is what you have- Leave the key field in the answer file blank and select the Image Type (Product Name). The installation media checks for the manufacturer meaning that your source media is only compatible with computers that came from the same manufacturer. During the installation, Windows 7 automatically gets the key from the computer. An OEM key is tied to the motherboard and other BIOS settings. So if you replace the motherboard or BIOS, the OEM media might not work on that computer any longer. The other caveat is the media should only be used on computers that came with Windows 7 installed. You can’t legally install Windows 7 from an OEM disk onto a system that came with Windows XP for example.
  • Volume MAK: A multi-seat license managed by Microsoft, requires internet access to complete the activation. Volume seats are typically used in organizations with more than about 50 computers. Leave the license key field in the answer file blank and selects the Image Type (Product Name). Create and use the following post installation task (batch script) in your Scripted Installation. Simply replace the X’s with your MAK key; also consider separating these into 2 tasks, so you don’t have to activate (“burn an activation”) each time you deploy an image/script for testing purposes.
REM Configure Client using VL MAK
cscript.exe c:\windows\system32\slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
REM  Activate the machine using the VL MAK
cscript.exe c:\windows\system32\slmgr.vbs /ato
  • Volume KMS: Multi-seat license managed by a KMS server that you host, typically used by larger enterprise customers, but available to many Microsoft Licensing Agreement customers. The client keys are the same for all KMS clients, your Microsoft-issued KMS key does not go on the clients, it goes only on the KMS server. If you don’t have a KMS Server configured and you have a volume key, chances are you use a MAK style key. Even though your K2000 has a drop-down with the keys right there for KMS clients, as tempted as you might be, we recommend selecting the Image Type rather than using Autodetect; feel free to select your key, but also select the image to install. If properly configured, your KMS server should pick up the new Windows 7 installation, automatically set the key, and activate it.
Posted in New Posts | Tagged , , , , , | Leave a comment
Jun
22
2012

K1000 Kloser Look: Testing Patches before deployment

Posted on June 22, 2012 by Christopher Blake

Testing patchesK1000 Patch management report before deploying them to all of your production machines can be a tedious task that few want to do, but it is a crucial part of keeping your network as secure and bug free as possible. While no company releases patches to break their product it does happen from time to time. There are several methods for testing patches; one method requires you to look at each individual patch and approve it for deployment after careful research, another method is to have a test group of computers that get deployed patches before the rest of your environment does.

The first method is fairly straight forward, what you will want to do is have a manual patch label, created under “Label Management”. This manual label can have patches manually added to it on the Patch Listing page, the Patch Listing is located under the Security Tab. This will show you all available patches that you can choose from to add to this label. What you do next is simply click the check box to the far left of the appropriate patch(es), then click the Choose Action drop down box and select Apply Label and viola your label is now updated. This allows you to have a great degree of control over what patches are applied to the machines in your environment.

The second method is a bit more hands off, for those that don’t have the time to go through all the patches one by one you can set up a patch smart label for testing and another for production machine deployment. The way this works is you create a Patch smart label, targeting the appropriate patches you wish to deploy for testing. Next you create another patch label with the same criteria with one extra item, select “Release Date” “>” “DATE_SUB(now(), INTERVAL 30 DAY)” and create the label, name it ex. OS Patches Greater than 30 days Old. Next you will need to edit this label, to go the Home – > Label – > Smart Labels and select the label you just created by clicking on it. Once you’ve clicked on it, locate the ’DATE_SUB(now(), INTERVAL 30 DAY)’) and remove the quotation marks before Date and between the last to parenthesis. This greater than 30 days old will be your production patches because it will allow you to deploy the first label that includes all patches regardless of age to a test group of machines and if there is an issue you can catch it before it goes company wide. What you can now do is take the standard label and deploy it to a group of computers in various departments for testing (or use a labels that includes your standard testing machines), if your other deployment labels are also including a variation of this for GREATER than 30 days- your automated testing of the patches has 30 days before it goes live for deployment to the rest of your network, so you have 30 days to catch any issues that are caused by a particular patch. Adjust INTERVAL 30 DAY to INTERVAL 10 DAY or any other number that you wish to set your release cycle to.

These are just two methods of testing patches before they are deployed to your environment, they vary in the amount of automation for the deployment and both offer better flexibility and security than just simply deploying patches and hoping for the best.  In many environments we see that “testing” amounts to deploying the patches to the IT staff to see if it breaks anything. If not, it just rolls out to the rest of the world. The challenge with that and similar methods is that you’ve forgotten that you use your machines differently than the end users; if I update office and open Word and Excel and say it’s all good, then roll it out to a group of Publisher and Access users and there’s an important feature that’s broken… we might well create more work for ourselves to undo the patch, and worse- we’ve impacted the users. Testing across multiple departments and business functions is ideal if possible. Many companies are taking a tiered approach based on our Label automation noted above- IT First for 1-3 days, Testing Label including various hardware types/OSes/Departments/Etc. for 10-14 days, then all deployed machines within 30 days.

Posted in New Posts | Tagged , , , , , | Leave a comment
Jun
5
2012

K1000 Kloser Look: Labels Terminology

Posted on June 5, 2012 by Christopher Blake

Labels are arguably the most important part of your K1000 because we’re going to use them in almost everything we do. Having a good foundational understanding of Labels will serve you well in using the K1000 to run scripts, install software, define permissions in the user portal, distribute patches, focus your download of patches, license compliance, and reporting among other tasks.

We often get asked what the types and differences of Labels are. So, I’d like to take a look at some terminology and define what is and isn’t and maybe what could be.

Label: Is a way to organize together the various types of objects on the K1000. Labels are intended to be used in a flexible manner, and how you use labels is completely customizable. Once included in a label, items can be managed on a per-label basis. All items that support labeling can have none, one, or multiple labels. While objects such as Computers, Users, Patches, Software, and Dell Updates are often separated into their own labels, it is possible to create a label that contains more than one type of object if necessary, though it is only rarely useful to do so.

Manual Label: Manual labels are static labels that are manually applied and removed for each object. An example of a manual label might be grouping computers on a particular sales project so we can distribute software or files to those machines. Grouping the users from that group into a label might be useful for granting access to certain knowledgebase articles that are useful for that group.

Smart Label:  Smart Labels are more dynamic than manual labels; Smart Labels are automatically applied and removed when an object meets some criteria that you’ve defined via a SQL wizard, or directly writing the SQL. Smart labels allow us to be flexible and set policies and automation. Smart Labels contain 2 parts- a manual labels and a linked SQL query. Any labels that have a linked SQL query can only be applied and removed by that SQL evaluation. Most evaluations happen immediately, but Computers are evaluated only at the normal inventory interval. Note that if you want to convert a previously created (and likely populated) Manual Label into a Smart Label simply re-use the name or choose it from the dropdown naming menu in the Smart Label wizard.

LDAP Label: LDAP Labels are similar to Smart Labels, in that they are dynamic and will automatically apply and remove themselves when an object meets certain criteria. The major difference is we’re querying your directory rather than the SQL objects. The LDAP labels can only be applied to Users and Computers, and might be useful for repeating directory structures such as OU’s or Security groups as Labels.

Label Group:  Label Groups are strictly for organizational purposes, such as the “View By” function in the Computer Inventory page. They cannot be targeted for Patching jobs or Managed Installations for example. You can associate labels with one or more Label Groups; membership in one Label Group does not preclude membership in another Label Group. In fact, Label Groups can be a member of another Label Group.

Given the importance and wide range of usues that Labels have- For various reasons it’s a good idea to be very descriptive when naming labels. A good descriptive name can reduce mistakes moving forward, and a structured naming scheme can help later when grouping labels, or referring to another label or set of labels from a different one. Each customer will have their own preferences and needs, but these basics can help you acheive great success with your K1000 Systems Management Appliance.

Posted in New Posts | Tagged , , , | Leave a comment
Apr
10
2012

K2000 Kloser Look: Importing Software Installers from K1000

Posted on April 10, 2012 by Christopher Blake

Have you ever wanted to install the same application on K2000 that you already set up as a Managed Installation on your K1000? Wish you could magically transform that Managed Installation into a Post Installation Task, well you can. Don’t duplicate effort by recreating those Post Installation Tasks from scratch when it’s as easy as simple as K1000 Export –> K2000 Import. If your managed installation is working properly, and the payload of your software package includes the installer (as opposed to a script or wrapper only) the package is eligible to be converted to a Post Installation task on your K2000.

To export the Managed Installation, log in to the K1000 Management Appliance Screen shot of the K2000 console showing the deployment taskadministration portal. Next, click Settings > Resources > Export K1000 Resources. Select the Managed Installation(s) that you want to add to the K2000 as Post Installation Tasks, and then click Export to Samba from the Actions menu. The K1000 creates a K-package file in the \\k1000host\clientdrop share. Note that by default, the client drop share does not have a password, but you can set one on the Control Panel > Security Settings page.

The package is ready to import to your K2000. On your K2000 Deployment Appliance, click Settings & Maintenance > Package Management > Import K2000 Packages. In Choose Action, click Upload Package for Import. Click Browse, enter the path to the K1000 client drop (\\k1000host\clientdrop) share, select the Managed Installation K-package, and then click Import Package.

Uploads from a browser is limited to around 1.5 GB. To import larger packages, copy the k-package from the client drop share to the K2000 restore share at \\k2000host\restore. You can also use this method to import several files at once.

The Managed Installation automatically displays in the Import List based on what is in the restore share. Just select the package(s), and then click Import Selected.

Now go to your Library > Post Installation Tasks list and verify that the command line of the Post Installation task will work properly on the K2000. For some commands you may need to add the file name or slightly alter the command.

Posted in New Posts | Tagged , , , , | Leave a comment