3 Replies Latest reply on May 18, 2009 7:38 PM by Dthompkins

    Provisioning Setup Architecture


      Well I've been working on Provisioning now for about 2 months and I must say I've learned a great deal. This post is a question, but there won't be one right answer. I want it to be more of a discussion to help those new to Provisioning to get a better understanding of how others use it in the real world. I know there are plenty of templates out there that do offer some help but in my mind are limited. My question to everyone is:


      How have you setup your Provisioning structure? (Action Items)

      Do you use it for a full setup of a machine? (Meaning you format, image, install agent's, install software, install patches)

      Do you use it to just Capture images?


      My personal plan is to essentially have a machine fully fuctional after it's been Provisioned. I'm interested to see how others feel.



      One other question (off-topic), does anyone know of a way to setup a provisioning task to add a domain user group to the Local Administrator group on a machine?


      I appreciate all the info!


      - Paul

        • 1. Re: Provisioning Setup Architecture

          Hi Paul --


          I too believe that the purpose of provisioning is to have a single, end to end process that allows the configuration of machines (both servers and workstations) with a good level of quality control.  A lot of the work that I have done for our customer base is around a solution set that BizCarta has dubbed "OneTouch".  A user can pull a machine out of the packaging, brand new, and PXE boot it letting LANDesk provisioning do the rest.  This has included the following:


          • Booting to Windows PE
          • Detecting the location of the system
          • Mapping to the nearest distribution server to obtain images and scripts
          • Deploying the image
          • Pushing the drivers
          • Rebooting to sysprep
          • Installing the LANDesk Agent
          • Deploying patches according to the patch level variation between the SOE version and the current patch level
          • Installing applications according to a department level template.


          I have this process working at home in my lab, and at several customers who are converting from hardware independent imaging via OSD to Provisioning based HII.  Provisioning even works really well for scripted installs of Windows and Linux boxes.


          To answer your question, yes you can add domain groups to local groups via provisioning, however you'd have to script it as a batch file and use the execute file action.  If your additions need to be dynamic (i.e. the domain groups added to the local group are contingent on where the machine is), you can use a batch file and have variables replaced using the replace value action.

          • 2. Re: Provisioning Setup Architecture



            Thank for that post. Having the ability to get the mac address of a machine from the manufacturer and pre-configure Provisioning to run from start to finish is an amazing thing. I have two comments about your post. Is there any reason you would apply the patches before running software installations? I had planned to do software installations first. I'm not sure if there is a preferred order? One other thing, for me, I plan to add the same group into the Local Administrator group on the machine. I'm glad to hear that this is possible. Do you have any examples? I can probably seach the web, just thought i'd ask.


            Thanks for the info!

            • 3. Re: Provisioning Setup Architecture

              In response to your questions:


              The rationale used behind NOT patching software as a part of the onetouch process is that the distribution packages should be kept up to date.  Rather than having to manage a onetouch template every time a patch is found for a piece of software, then removing the component from the template once the patch is integrated into the software package, its my belief that its best to ensure the software is rolled up to date.  While this doesn't always apply neatly for every package, software like your Firefox browser rolls updates into their base installs. A few things to be mindful of are as follows:


              • Version control in your templates:  What happens if you have Firefox in your software distribution template, but update the version from 2.x to 3.x?  You'd be buliding a new software distribution package to push the latest version of firefox, and if you are using the distribute software action in your template you have to explicitly specify which package in the console to deploy. If you statically add the Firefox 2.x install package into the template, you'll have to rebulid all of your templates to use the new package.  What I recommend is having a single package called Firefox-Latest.  Once the version of Firefox to use within the corporation is ratified, modify the ''Firefox-Latest" package to have it install using the new files and command line parameters.  You'll have to reset the package hash, but this will keep you from rebuilding your templates.  If you still need to support for the version of Firefox you've just replaced, build a separate package with the specific version in the name for it.
              • Package Chaining Template:  Unfortunately Application chaining within software distribution packages doesn't appear to be supported in the distribute software action.  As such, you may find that some of your more complicated software packages would be better with a separate SWD package built to wrap all of the patches into a single executable.  Alternatively, you can have a provisioning template to install the software plus all of the patches wrapped in one.  Since you can stack provisioning templates (i.e. include one provisioning template in another), if you maintain your 'Deploy Microsoft Office' template with the latest hotfixes, etc., any other provisioning template that uses it will be up to date.


              This is not to suggest that my way is the best way on the block -- I'm just more of a proponent of enforcing governance by requirement.  You could install software as a part of your template and then run patch installs, but I have found that some IT personnel have the false sense of security in the thought that LANDesk Security and Patch will update all of their software if its run after the software is installed -- this isn't the case.



              regarding the addition of users to local groups, its a one liner.  Use the net localgroup command to add domain users to any local group.  The following command adds the domain admins to the local administrative group:


              Net Localgroup administrators "mydomain\domain admins" /add


              you can create this as a batch file and execute it in a provisioning action, or you can have it as part of the sysprep to execute after the system first boots to windows (assuming you join the domain as part of the mini setup process)