I got a question from one of my customers the other day that was an easy, but not obvious, answer.  They had SCCM 2012 setup in Forest A but wanted to discover machines in forest B.  They supplied alternative credentials with the correct username and password for this other domain\forest but kept getting back a 0x8007052E error, which translates to “Logon failure: unknown user name or bad password.”

That error is, unfortunately, a misleading error.  There is nothing wrong with the username or the password.  The real problem was in the formulation of their LDAP query.  They needed to add a named DC to the query for it to run correctly, which was not an obvious thing to do.  The solution syntax was to formulate the LDAP query that looked similar to this:

LDAP://RemoteDC.remotedomain.com/DC=remotedomain,DC=com

If you are new to System Center 2012 Configuration Manager and learning the new Role Based Authentication (RBA) model you may not initially grasp the concept that you grant a user a role and scope to define their security access.  I find this gets people a little confused some times.  The role is the set of abilities a user is given. To compare to some thing people are more familiar with, Administrator role means you can do things in AD like crate accounts, stop services, etc.  That’s fine, but then the question is WHERE you can do these actions.  A local administrator has a different set of objects they can affect compared to a Domain Administrator.  This is their scope (local or domain).  In ConfigMgr you grant a user a scope to define what objects in the hierarchy the user is allowed to exercise their actions against.

Said one more time for clarity, a security role defines the actions you can take, the scope defines on what objects you can take those actions.

Now, the scenario I recently hit with a customer was where they had a CAS and a primary site.  They created a scope, called Pri1, and tagged the primary site object to be part of this scope.  They then granted a user the Full Administrator security role, but only on the Pri1 scope.  This let the user administer and run the primary site, but not touch the configuration on the CAS.  We got down to setting client settings from the Primary, and couldn’t see them.  They are considered a part of the CAS site, where no rights were granted.  Now, how do we let the user at the primary access these client settings but not have full permissions over the CAS?  If we simply added them to the  CAS scope, they would combine that with their full administrator permissions and be able to do far more than desired.  The answer is in this screen shot:

The names used in this screen shot are different, but the key is the use of the 3rd radio button, and not the 1st or 2nd.  We want to Associate the assigned security roles with SPECIFIC security scopes.  To follow on from my earlier example, we need to add the read permission to the CAS site, leaving the Full Admin permission attached only to the Pri1 scope and specific collections.

For some of you this might be enough for the “lite bulb to go on,” but in case you weren’t so lucky, here are the steps you should be taking to set up this user in this scenario:

1. Create Scope for CAS
2. Create Scope for Pri1
3. Tag CAS site object with the CAS scope
4. Tag Primary site object with the Pri1 scope
5. Create a new security role where the only permission granted is Read on the SITE object
6. Add a new user to ConfigMgr giving them Full Administrator role to the Pri1 scope and your newly made security role tied to the CAS scope.

Today’s blog post again comes from a fellow PFE and I can’t take any credit.  However, I thought it was a worthwhile topic and I wanted to make sure the knowledge and information is out there for other folks.

When you create a collection and decide to populate it you have two options, direct membership and query based.  Many folks use direct membership because it is very easy to do compared to a query.  Pick a machine, and it is in your collection.  This works fine if you are setting up a quick package test or something similar but there is a pitfall most folks are not thinking about.  When you do this you may pick a machine/user based on its name, but under the covers SCCM is actually assigning the resource based on an ID number.

Where this can come back to haunt folks is if a machine should change its ID number.  To the SCCM administrator the machine still shows in the admin console, but would no longer be a member of any collections where it was directly assigned.  A machine can change its ID number for various reasons, such as an OS upgrade (hopefully via the OSD feature), because it is accidently deleted from SCCM and then repopulates from a new DDR, or if maintenance tasks are set to aggressively and delete the current record.

The solution here is slightly more work in the short term, but can save you some work in the long run.  When you create that collection membership make it query based and in that query you can specify to return all machines/users with a specific name.  Now no matter what happens to the machine and it’s ID in SCCM it will continue to be a member of the collection as long as it keeps the same name.

One more catch, this time in relation to the solution I mentioned.  I have heard (but not witnessed myself) that collections with a large amount of queries can perform poorly.  I would suggest that rather than making one query for each machine you want you instead make a single query that is a “list of values” instead of the more standard “simple value” and then just add all your machines to that one query.

I was with a customer recently who found management of their Forefront updates to be problematic and they were looking for an alternative method to the general recommendation (http://technet.microsoft.com/en-us/library/dd185652.aspx).  They had actually come to this idea on their own then asked my input, but if they had asked me first this is the same solution I would have proposed.

Setup a script to download the updates (see http://support.microsoft.com/kb/935934 to get you started) and run that script as a scheduled task (say…, every 4 hours).  In SCCM create a package that points to the source location where your updates are downloading to.  Set a schedule to update your distribution points on a regular interval (such as every 4 hours, about 10 minutes after your download is kicked off).  Create a program that silently installs the update. Advertise that update with a re-occurring schedule that runs the update program on the client on a regular interval, such as every 4 hours and about 45 minutes after your initial download via your script (depending on your DP replication times).

Tada…, all your clients now have up-to-date forefront definitions, all done through the bandwidth controlled mechanism of SCCM.

NOTE: The time interval I gave was just for discussion and example purpose.  Depending on your environment, size and latency of your SCCM hierarchy, etc. you may need to adjust that time interval and/or set up separate downloads and packages for down level child sites.

All kinds of news today.  A piece I find interesting…, ConfigMan is no longer going to be available as a stand alone product, but instead as part of a suite.  A good write-up is linked below.

http://www.zdnet.com/blog/microsoft/microsoft-details-new-licensing-plans-for-its-cloud-management-suite/11673?tag=content;feature-roto

Heads-up to everyone out there.  The RC of System Center Configuration Manager 2012 is now availible for public download.  You can find it at http://www.microsoft.com/download/en/details.aspx?id=27841.  Notice how Forefront Endpoint Protection 2012 RC is also included.

OK, I will reveal one of my own skeletons today.  I have setup the FEP definition update tool several times for customers but in my own lab I was banging my head against the wall trying to figure out why it would not run correctly.  For those that don’t know, this is a tool run via task scheduler to automate the deployment of FEP definitions via ConfigMgr with out on-going admin interaction.  No matter what I did, it just would not run and I would get an error of 1 back.  Finally, with the help of my fellow PFE, Richard Balsley, I figured out that this was due to my use of System Center Updates Publisher (SCUP) on my test bench, and a bug in the interaction between the two tools.

Just recently this bug was fixed and a new version of the tool was placed on the website.  There were some other updates to the tool as well which Jason Lewis has nicely documented in a blog post as well. If you have Forefront Endpoint Protection 2010 and aren’t using the tool yet I highly recommend you read the blog post and get it set up.

Part 2

On a separate, but related note, I had another cause for the 0x1 error with one of my customers with a not-so-obvious cause.  We had copied the command line options from the published technet article, which turned out to be the problem.  In that article the quotes around the article ID are actually smart quotes and will not interpret correctly from the command line or task scheduler.  If you replace the quotes with normal ones it should work.  I believe the article is going to be corrected so hopefully by the time you read this it will no longer be an issue.

If you spend much time around Configuration Manager you become aware that a lot of it runs through WMI.  WMI is “Windows Management Instrumentation” and is essentially Microsoft’s implementation of a internet standard called Web Based Enterprise Management (WBEM).

If you are doing task sequences and wanting to provide intelligent branching, digging into hardware inventory to possibly extend it, or working with the ConfigMgr SDK, you are playing around with WMI/WBEM.  One tool I like to show my users who are new to WMI is one which is built right into every windows OS, called WBEMTEST.  As you read this blog feel free to follow along, as I’m betting most readers are on a windows box.  Go to Start and type “WBEMTEST” into the search or run box.

Before I get too far, let me note that there are many WMI tools out there.  On a regular basis I don’t use any of them?  Why?  Many are more friendly with a better UI designed.  The big downside is that they have to be downloaded every time you want to use them.  WBEMtest is at your fingers on any windows machine and OS learning to use it will speed your troubleshooting compared to going in search of your other favorite WMI tool.

When you launch WBEMTEST different OS will work slightly differently.  Some will automatically connect to a namespace, others (like Win7) will not.  If you aren’t connected you can hit the connect button, make sure “root\cimv2” is selected, then hit connect again.  Now you are back in the main UI with everything “lit up” and ready to go.  A namespace is, to relate it to something most folks are familiar with, a directory within WMI.  You can change directories to all kinds of namespaces.  CIMV2 is where a good amount of hardware information is kept.

From here you have lots of options.  If you are already a WMI expert and know hat you are after you could hit the query button and type your WMI query to look at the results.  For the beginner, just exploring WMI for the first time, I suggest you hit the “Enum Classes” button.  In the pop-up choose “Recursive” and hit OK.  You have just done the equivalent of a DIR to list all the contents of the name space.  Everything with underscores (__) in the front of the name is what I call WMI overhead.  This is what helps WMI be WMI.  IN most cases you will skip over that and look at the other stuff.  For this discussion I suggest going to Win32_Service and double clicking.

You have now opened up this “file” in WMI which lists all the collect info about services on your machine.  The file/directory analogy starts to break down at this point.  Know that this is some definition information and skip past it by clicking on the instances button.  You now get a list of all the services on your machine.  Pick a service, such as RemoteRegistry” and double click it.  You now get to see all the info about that specific service.  This view is kind of a pain to look at, however, so I recommend you click the “Show MOF” button to get a nicer view of it all.  Here you can see the service state, description, start mode, etc.

Snoop around in WMI and see what you can find.  Know that once you find something you could write queries in your task sequence to use that data as decision points, you could collect it via hardware inventory, or you could script against it using the SDK.  All kinds of things open up for you.  A few other namespaces you might be interested in are

• root\ccm (ConfigMgr client info)
• \root\SMS\site_ZZZ">\\<server>\root\SMS\site_ZZZ (where the ConfigMgr provider info is for the administration console)

Have fun exploring!

I co-worker of mine pointed out a large amount of 30102 and 30103 status messages being generated by FEP 2010 clients.  If you run a status message query on your system you can see them, but nothing in the UI brings them to your attention by default.  They aren’t the most useful status messages.

I don’t normally advocate hiding things from yourself, but unless someone can point out a usefulness to me I will make an exception for these.  If you don’t want to bloat your DB with them I suggest you create a status filter rule to block them from processing.  Remember, status filter rules process top to bottom, so put your new rule before the write to DB and block further processing and all should be good.

Today’s post falls into the category of things I feel a little guilty about posting, but I will anyway.  I’m not saying anything new here, just trying to spread the knowledge because I keep seeing customers hit the same problem, which has a simple solution.  If you want to skip reading my blog you can go to http://blogs.technet.com/b/configurationmgr/archive/2008/11/12/configmgr-2007-osd-task-sequence-fails-with-unspecified-error-80004005-and-setupact-log-indicates-invalid-product-key.aspx and get the details.

What I see with customers is that they are building a new OSD task sequence and they enter their company product key into the task sequence only to have it fail, usually with a 80004005 error code.  This is occurring because the product key they entered was a a MAK (Multiple Activation Key) and not a standard product key, which ConfigMgr just doesn’t know how to handle.  The solution is easy for newer (vista and higher) OS.  Leave the key blank and add a step to your task sequence, after OS install, to run the following command line and set the product key:

SLMGR.VBS -ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

I had one customer encounter this with older OS, WinXp.  We didn’t actually get into the issue so if that is your situation I can only offer you the advice I offered them (and if it works or not, please let us all know in the comments below) but I have not yet had validated.  Add the key to a custom unattend.txt file and then add that text file to your task sequence, in the “Apply Operating system”.  This might pass it along correctly.

Last night I decided to tackle a minor, but annoying, problem in my household.  I have a Zune and I use my 10 credits every month to buy music that I like.  I don’t have physical media for these songs and perhaps I’m just old school, but I wanted physical copies of my music as a backup.  The secondary purpose was to be able to play the CDs in my car.  My 3rd purpose was to write the music not as a typical music CD but as data so I could fit more songs per CD.  My 4th purpose was to start building my powershell skills, which I’m lagging behind much of the world on developing.

When I purchase my music I have been adding it to a playlist, for tracking.  The physical files are in various directories and it was going to be a pain to track them all down to copy to the cd to burn.  Instead I decided it was time to brush up on my powershell some and wrote the script below one night.

You will notice there are some TODO items.  There are a few “fit and finish” pieces to handle, but the script functions as is.  I will be cleaning up my personal copy but I wanted to get this quickly posted for my friends who wanted to see it.

The script accesses a saved ZUNE playlist, finds all the files from that playlist, and copies them all to one single directory which you can then burn to CD.

“This software (or sample code) is not supported under any Microsoft standard support program or service. The software is provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the software and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the software be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the software or documentation, even if Microsoft has been advised of the possibility of such damages.”

##------------------------------------------------------------------------------------------------------------
## Created by Michael Griswold on 8-16-11
##     Last updated: 8-17-11
##
## This script will parse the XMl from a Zune playlsit file (ZPL) and then copy each listed file to a specific
##   directory.  You can then burn to CD as native MP3 files for playback on MP3 aware CD systems.
##
##    Reminder: Run this to allow execution of this script on yoru PC:  set-executionpolicy remotesigned
##
##------------------------------------------------------------------------------------------------------------

# TODO: Add in ability to read in values from the command line.
[string]$ZPLFilepath="C:\Users\Mike\Music\Playlists\To Burn.zpl"
[string]$Outputpath="c:\temp\ZPLOutput\"
   

## Prompt for ZPL file, with full path
"ZPL file path is hard coded"
"Output directory is hardcoded (and must be pre-created) to c:\temp\ZPLOutput"

## Parse XML file
[System.Xml.XmlDocument] $xd = new-object System.Xml.XmlDocument
$xd.Load($ZPLFilePath)

## Fetch the music files and paths
$nodelist = $xd.selectnodes("/smil/body/seq/media")
Write-Output $nodelist
# $nodelist | Get-Member | more

## Parse all the media tags to find the file name
foreach($mediaNode in $nodelist)
    {
#         "Entering foreach"
#         $mediaNode | get-member | more
        $path=$medianode.src
        Write-output $path
        ## copy the files to a final location
        Copy-Item $path $OutputPath
    }

# TODO: Add validation on user inputs

Before System Center Configuration Manager was known as “ConfigMgr 2007” or “SCCM” it was Systems Management Server (SMS).  You have probably all heard the joke about what SMS stood for; Slow Moving Software.  Well, those that have not adjusted their lifestyles to suit the speed (and I will add, power) of the product now have something to keep them busy.  Next time you are waiting for some OS deployment to complete, why not do a few ConfigMgr quizzes to see how smart you really are.  Who knows…, maybe you will learn something while you wait.

Hi folks.  For those that have been using SCCM and SCUP for a while you may recall that adobe had a limited catalog available for distribution via SCUP.  Adobe was removed from the “catalog of catalogs” which SCUP accesses.  Then they had a direct download of their Flash catalog.  Now they are coming around to include many more of their products.  They are not yet in the “catalog of catalogs”, but I’m told that is coming soon.  For more info see the blog post and links at http://blogs.technet.com/b/configmgrteam/archive/2011/02/11/announcement-adobe-acrobat-and-reader-x-scup-catalogs-are-here.aspx.

For those who have been using SMS and SCCM for a while this post will tell you nothing new, so check out the new picture at Http://bing.com and then go search for something else interesting to read.

I’m a big advocate for avoiding duplicate work.  To that end there are many things which I work on or encounter in SCCM that can be shared, and should be in my personal opinion.  One area where such sharing has done well is around collection of information via hardware inventory.

Changing the SMS_DEF.mof and Configuration.mof to collect additional information on your SCCM clients is a key concept but for folks new to SCCM there is a learning curve on how to modify MOF files, what they are, and how to get the information they want.  Thanks to Sherry Kissinger, and many of the folks who she has worked with, there is a handy tool to help you collect the information you seek with-out yet being a SCCM guru.  It is the Mini Monster MOF builder (http://myitforum.com/cs2/blogs/skissinger/archive/2008/10/28/mini-monster-mof-builder.aspx).  A simple download, search, and click of a button gets you the info you need, then copy and paste to your SCCM site and wait for the info to start rolling in.

Next time you want to extend the inventory collection capabilities of your SCCM infrastructure, check out the Mini Monster MOF and see if you can save yourself some time and effort.

When I talk with customers new to SCCM there are two things I advise them to not mess with:  Heartbeat discovery and the “All Systems” collection.

Heartbeat discovery is configurable, and it is ok to adjust the interval to meet your company needs, but don’t turn it off.  It isn’t obvious to the new SCCM admin but there are several maintenance tasks that key off that heartbeat DDR.  Disabling heartbeat discovery may cause systems to be deleted from SCCM before you had expected or intended.  I don’t ever recommend turning it off.

The All systems collection is a different, but similar issue.  That collection has a default object ID of SMS00001.  If you delete that collection you can, of course, re-create a collection with the same membership, and the same name.  It will, however, not get the same ID.  I have seen od behavior when that collection is missing.  I have never had the time to investigate the exact problem, but in general I just suggest not deleting it.  If you do perhaps delete it then you can restore it.  An example is http://blogs.msdn.com/b/vinpa/archive/2010/03/17/how-to-restore-the-all-systems-collection.aspx.

File this under the category “won’t kill ya, but best not to mess with it”.

For those that may not have seen the news you may want to take a look at the SCCM V.next Community Evaluation program.  If you are accepted you will get some early builds of the product as well as an opportunity to provide some feedback to the product group.  The program nominations close Sept. 24th.

Working in the System Center space I occasionally I get asked about management of environments that don’t really fit the world that SCCM focuses on.  SCCM is not a cost effective solution for many small businesses and with a top scale of 200,000 clients (soon to increase with R3 release) there are a few very large environments that go beyond what SCCM can handle effectively.  For the smaller environments there is a related product called System Center Essentials.  This is a product aimed at 50-500 client machine companies and is essentially a combination of SCCM, SCOM, SCVMM and Hyper-V all rolled into one nice and affordable package.  For now, that is what I recommend to smaller IT shops.  However, there is a new offering coming online that may be appropriate for some organizations and it is called Microsoft Intune.  Intune is less a hybrid of things, like essentials is, and more of a SCCM-lite or  WSUS-lite offering.  It has some of the same features of SCCM but is hosted in the cloud so small businesses don’t have to pony up the money for server hardware and can more easily get at the key things they need.  It doesn’t have nearly the deep and rich feature set that SCCM has, but for some companies it might be the right answer.  Check it out if you think it might be the right thing for you!

SCCM 2007 R3 released today.  I don’t see a RTM download yet, but it should be on the web this afternoon it seems.

http://blogs.technet.com/b/systemcenter/archive/2010/10/14/system-center-configuration-manager-2007-r3-unleashed.aspx

As I am working with customers often times there is a discussion about Active Directory discovery (usually systems, sometimes users).  People often do not want to discover EVERYTHING in AD, only a sub-set.  If they already have a specific OU or two to aim at, that’s great and SCCM can do an LDAP query to just those few OUs.  However, if there is a lot of separate OUs this becomes a pain to add plus you may miss out if a new OU is added by the AD folks.

A common example of all this is where a company wants to discover and manage all their workstations, but none of their servers.  Even though discovery of servers doesn’t mean they will be managed, folks do not want to take that chance so they want to limit their discovery so no servers are discovered.  Often times servers are in their own OU while workstations are in many OU.

So the very simple trick here is to simply grant a DENY permission for the SCCM Site server machine account on the OU you do not want discovered and then point SCCM to discover everything in the domain.  This allows discovery of everything in AD except specific OUs.  SCCM uses the machine account context to query AD during discovery and if it has deny permissions on an OU it simply skips over it, finding everything else and including, by default, all new OUs your AD team makes in the future.

I can’t take any claim for this idea but it is one that I think is handy enough, and not very well known, that I am trying to spread the word.  One of my co-workers has a great way to capture OSD logs when a failure occurs so they can be easily read and not lost simply because you weren’t in front of the machine to hit the function key and sniff around via a command prompt.

The simple concept is this…. you take your entire task sequence and place it under a new high level folder.  If any step in your TS should fail control will be returned up to this top level folder.  You set this top level folder to continue on error, leading to the next part.

Also at the top level, but below the folder you previously created you create a log capturing folder.  Under this folder you have some tasks which capture the SMSTS log and other related files and copy them to a file share on your network.

The end result of all this is that if any task in your TS fails, no matter which stage, you don’t have to hunt for the logs and you don’t loose them when the machine re-boots into a failed deployment.  You just go to the file share and take a look at what failed then go fix it.

All the details are on Steve Rachui’s blog at http://blogs.msdn.com/steverac/archive/2008/07/15/capturing-logs-during-failed-task-sequence-execution.aspx

For those that may not have yet heard, the SCCM 2007 R3 beta is available for folks to look at if they are interested.  I’m in process of setting up my own test box to play with it.  It is an open beta program and eval version, so you can only apply it to a SCCM eval install, not to a full install as most folks have.  The good news is that you can download a VHD of SCCM 2007 R2 eval and then apply the SP3 to that and play around.  The VHD and other R3 info is at the open beta section on Microsoft connect (https://connect.microsoft.com/site16).

It looks like the open beta for the next version of SCCM is coming soon.  The Microsoft Connect website has a section where you can sign-up to get it once it comes out.  See https://connect.microsoft.com/ConfigurationManagervnext and sign-up.  Rumor is this month sometime it will be available.

Inventory settings are site wide yet there are times when you want a class of hardware inventory collected for all machines EXCEPT a few (for example, some kiosk machines where many folks are logging in with new and separate profiles).  To handle that there is a handy write-up at http://myitforum.com/cs2/blogs/skissinger/archive/2009/07/03/selectively-disable-ccm-recentlyusedapps-per-client.aspx that will allow you to disable certain inventory classes only on select client machines while leaving it enabled for all other machines in that site.

Handy Eh?

Today’s post isn’t a tip or trick per se, but rather an issue that is not well documented that I hit with a customer.

When you install ConfigMgr 2012 you will notice that .NET 4.0 is a pre-req.  If, after installing the site, you decide you want to want to put the Application Catalog Website and Application Catalog Web Service on the site server you will most likely need to install WCF, a sub-component of .NET 3.5.1.

This will cause you the first issue, as documented in KB2015129.  Apparently WCF install messes up .NET 4.  Easy fix to stop the flood of status messages is to run aspnet_regiis.exe /iru and then everything looks good, the error status messages stop, and all is good, right?  Maybe

For one customer of mine this seemed to do the trick, but for my other customer the results were mixed.  The status messages stopped and all seemed fine.  Domain admins could access the Http:\\<server>\CMApplicationCatlog website just fine, but other users would get a 401 error:  “Unauthorized: access is denied due to invalid credentials after launching Software Catalog.”  we tried various things but in the end found another article on the net with the final solution (sorry I can’t give credit, I can’t seem to find it again).  The final solution to all this was:

1. Uninstall the Application Catalog Website and web service
2. Run aspnet_regiis.exe /iru
3. Reinstall the Application Catalog and web service

Today’s tip is one which many folks already know, but surprisingly many folks, even those who have used the product for a long time, have some how missed.  Due to some work I put into this many years ago it holds a special little place in my ConfigMgr admin heart.

If you use any version of System Center Configuration Manager (SMS, ConfigMgr, SCCM) then you have probably created some packages and programs to deploy software. Have you ever noticed the option (varies based on product version) for creating a package from definition?  That option was originally placed there so that software makers, such as Microsoft, could provide an easier way to deploy the product by you, the ConfigMgr admin.  Along with the binaries of the product they could also supply a file, called a package definition file, which would auto populate some fields in ConfigMgr such as product name, version, proper command lines, etc.  Originally these files were a .PDF extension but, for reasons I am all figure out, we changed that to be a .sms extension.

So.., great concept.  You grab the files from the software maker, import the package definition file to create the package and program details in ConfigMgr, then you point the newly created package at your source files and start distributing software.  The catch is… that it didn’t catch.  Most companies and products did not bother with the creation of package definition files.  Then along came our friend, the MSI.

With MSI technology picking up we saw the opportunity to help the ConfigMgr admin use this package definition concept.  Code changes were made and now you can reference an .MSI as well as a .SMS or .PDF file for package and program creation.  No longer must you depend on the software maker to create a special file.  If they have an MSI then you can reference that and ConfigMgr will extract all the necessary data out to create the package and programs you need.

Next time you need to deploy software, check this out and see if it helps you take a few steps out of the deployment process.