One of the biggest challenges in application deployment is modifying settings post-install. These “settings” can include customizing application preferences, tying the application to a data source, activating the software, or accepting the EULA. This article will explorer where to find these settings and how to deploy them as part of your deployment. These processes are system-agnostic, meaning that they will work whether you use group policy for software deployment, System Center Configuration Manager, KACE, or any other desktop management solution.
As a disclaimer, please ensure that your license agreement allows you to accept the EULA for a product or activate it for multiple machines. If your agreement does not allow this, then do not automate these processes.
This article will contain numerous uses of phrases like “most of the time” or “for the most part”. No two installers are same. Some products store things in files, folders, or registry keys that you have no idea what the developers were thinking when they built it. When dealing with software installs, you must have patience and the time to root out these settings. Packaging software is more of an art form than anything else.
Locations
Most of the time, post-install settings will be located in four areas. These areas are the user’s AppData folder (C:\Users\\AppData), ProgramData (C:\ProgramData), HKEY_CURRENT_USER, or HKEY_LOCAL_MACHINE. If you’re lucky, settings will be stored in ProgramData or HKEY_LOCAL_MACHINE. These are the easiest areas to deploy too, because they exist for the machine and not the user. Deploying to these areas are normally simple file/folder copies or registry writes. If it is an MSI installer, you also have the option of creating an MST that contains the files, or even directly editing the MSI.
If settings are stored in the user’s AppData folder or in HKEY_CURRENT_USER, the process becomes a little more difficult. Normally, this involves copying the files/folders to the Default user directory (C:\Users\Default) or loading the Default user registry hive and writing the keys there. I will go into more detail on this later.
For the most part, it is a look-until-you-find-it process of finding these configurations. Normally, you need to look for folders, files, or registry keys that are named with either the manufacturer of the software or the software title. That is a good indication that you need to pick up those files.
Machine Locations
Machine locations are far easier to deal with than user locations. As I said before, all you normally have to do for items saved in machine locations is copy them to your package directory. You can then use a script to first install the software, then copy down and files/folders, and then write any registry keys that are required.
I recommend using a simple batch file or a PowerShell script to do these installs. Always start with the program install first, then do any of your copies or registry changes. To copy files in a batch file, use the xcopy command. Here is the format: “xcopy /c /q /s /e /y /i”. To copy files using PowerShell, use the copy-item cmdlet. Here is the format: “copy-item \* -recurse”. Please note that in both of these commands, if the directory you are copying too is not already built, you can add the directory to the end of the destination path. For example, if I were wanting to copy files to “C:\Users\\AppData\Roaming\application1” and the folder application1 did not exist yet, my destination path for xcopy and copy-item would be “C:\Users\\AppData\Roaming\application1”.
To write registry keys with a batch file, use the reg command. The format will be like this: “reg add /v /t /d /f”. For PowerShell, there are two commands that you must run. First, we must create the key. To do that, you run: “New-Item -Path
”. Next, we have to create the values. To do that, run: “New-ItemProperty -path
-name -PropertyType -Value ”. I know that some of the descriptions seem confusing, but that is what they are. In the example below, I show what is considered the key, the value, the type, and the data.
So if I were writing the above key using a batch file, the command would look like this:
reg add HKLM\SOFTWARE\7-Zip /v Path /t REG_SZ /d “C:\Program Files\7-Zip\” /f
If I were writing it with PowerShell, it would look like:
new-item -path HKLM:\SOFTWARE\7-Zip
new-itemproperty -path HKLM:\SOFTWARE\7-Zip -name Path -propertytype string -value “C:\Program Files\7-Zip\”
Always remember to include your directory path in quotes if the path contains spaces. This applies to batch files and PowerShell scripts.
User Locations
User locations are much harder to deal with. If the user account has already been created on the machine, you almost always have to run the installer as the user instead of as administrator. This can present problems if you do not run your users as machine administrators. For SCCM shops, this means setting the deployment to run as user instead of as administrator. I do not have a good solution for capturing these settings if the user account has already been created. One solution, though not ideal, is to do two programs / deployment types. One program will run as administrator and do the application install. The second program will be our script that copies the settings and will run as the user. You can chain these together by using “run another program first” or “dependences”, depending on if you are doing it as an application or package.
If the user account has not been created yet, you can copy all of the settings to the Default user profile, and those settings will be copied to every user that logs onto the machine. For file / folders, use the same xcopy command from above, but copy everything to C:\Users\Default. For registry settings, we have to mount the default user registry hive. From a batch file, run this command:
reg load HKLM\default C:\Users\Default\NTUSER.DAT
This will mount the hive to HKLM\default. From there, you can run normal reg add commands to the hive. When you are done, run:
reg unload HKLM\default
This will unmount the hive.
PowerShell, again, is more complicated. We have to create a new PowerShell drive to make this work, but first we have to use the above command to mount the hive. Here is the series of commands:
cmd.exe /c ‘reg load HKLM\default C:\Users\Default\NTUSER.DAT’
New-PSDrive -Name HKDU -PSProvider Registry -Root HKLM\default
These commands create the new drive, and we can write keys to it. To write the key, the path is “HKDU:\
”. Other than that, use the same set-itemproperty command from above. To unmount the drive and hive, run this at the end of your script:
Remove-PSDrive HKDU
[gc]::collect()
Cmd.exe /c ‘reg unload HKLM\default’
The [gc]::collect() is very important. It clears the PowerShell drive from memory so that the reg unload command works.
AdminStudio Repackager
If you cannot find any files, folders, or registry keys to deploy, you can use the Repackager that comes with AdminStudio to find what is modified after you change something. You can do the normal snapshot method in Repackager to analyze the entire system for changes. This will tell you what changed on the system. You can then either extract those changes and use a method listed above to deploy them, or compile the Repackager project into an MSI and deploy it. I would caution against using the MSI that Repackager can create for changes in user locations, as they usually do not deploy correctly.
For complete article on Repackager, go here: http://www.windowsmanagementexperts.com/application-deployment-using-adminstudio-repackager/application-deployment-using-adminstudio-repackager.htm.
Summary
If you take anything away from this article, let it be that it takes patience to find and collect this changes and then write the scripts to deploy them. The PowerShell scripts included in this article appear challenging and long, but PowerShell is the better to go. It is very versatile and can be very detailed. As I stated at the beginning, packaging applications is an art. I have been doing this for years and discover new things about it every day.
AdminStudio is a product from Flexera Software that can be a complete, end-to-end application management system. It includes products for application modification and deployment. It comes with Repackager, Tuner, and InstallShield, as well as a host of other products. This article will focus exclusively on Repackager.
I will start with all of the information you need to know about Repackager, then go through a simple example where I repackage Mozilla Firefox into an MSI.
Background
Repackager is a product for converting legacy EXE installers into deployable MSI installers. It captures all changes made to a system during installation and creates an MSI from these changes. This product is very useful for administrators who must deploy software using Group Policy. GPO’s can only deploy MSI installers, so this a required product for an organization that does not have a system like System Center Configuration Manager.
Repackager can also be used to detect system changes that occur from configuring a product after installation. I use it all the time to see what changed on a system whenever I open a program and check a box in the program’s settings. This is especially useful if you must deploy an application with a certain set of settings. Repackager can tell you almost instantly what changed, and you can either deploy the MSI that is created from Repackager, or grab the file or registry key that changed.
Limitations
Repackager does have some limitations. It absolutely cannot capture drivers. Flexera is very open and forward about this. If an application installs a driver as part of its installation, Repackager is not a solution for deployment. In these instances, software installation is almost always a manual process and cannot be automated.
Another limitation is that Repackager can pick up erroneous data. If you do the snapshot method (more on that later), it will pick up EVERY change made to the system. That means if your virus scanner updates its definitions that will be picked up. If Windows Update runs a sync it will be picked up. The newest version of Repackager (v11.5) mitigates this somewhat with Installation Monitoring. I will go into more detail about this later in the article.
Lab Setup
To minimize capturing erroneous data with Repackager, I recommend creating a “clean” computer to do your capturing on. I also recommend that this be a virtual machine that can easily be snapshotted back to a clean state. Products such as Hyper-V, VirtualBox, and VMware Workstation can satisfy these requirements. I further recommend that you do not install virus protection and that you disable Windows Update and Windows Firewall. This will greatly reduce the amount of erroneous data captured with Repackager. I also do not join my Repackager machine to my domain or have it in my CM 2012 environment.
The AdminStudio suite can be installed on your primary machine. Version 9 debuted the Remote Repackager. This is a shared directory that gets mounted inside your VM. Repackager then runs from the clean machine, while the suite is installed on a different machine. Flexera has a very good guide for setting this up here: http://kb.flexerasoftware.com/doc/Helpnet/adminstudio901/Content/ashelplibrary/ISR_Optimal_Remote.htm. These directions are for version 9, but they work with the newest version (11.5).
One further recommendation is to repackage the application on the operating system that it will be deployed on. For example, if I’m deploying to Windows 7, I will repackage on Windows 7. The system is supposed to work crossing operating system versions, but I have had better experiences when keeping the operating system version the same. Also, I have noticed that architecture (32 vs. 64-bit) does not make a difference. If I am deploying to both, I still try to package the application in 32-bit.
Installation Monitoring vs. Snapshot
This is basically the only option your given (besides package name) when setting up a repackage. This is the method that Repackager will use when analyzing the application installation.
For simple applications, installation monitoring works really well. It watches the installation and captures the changes. This most suited for applications that need no extra configuration after install. You can adjust shortcuts after install, but that is it. If you need to make any configuration changes, snapshot is the method that you need to use.
Snapshot takes a “picture” of the operating system before and after install. It then analyzes the before and after and captures the changes. This is most suited for applications where post-install configuration is needed. This post-install configuration can be activating the software, clicking through the EULA, or just changing an application setting. Always make sure that your license agreement supports activating the software for all users or accepting the EULA on behalf of your users. If you launch the application before analyzing the changes, any change you make will be preserved in the captured MSI.
Overall, I use the snapshot method almost exclusively. Over time, I have seen better results with this method. There is more data that you have to exclude on every capture (more on exclusions later), but it seems to work better.
If you are trying to figure out a change outside of an installation, snapshot must be used. This is where you are trying to figure out what changes when you change an application setting, or anything post-install.
Exclusions
After capture, the repackaging wizard comes up. This is where you can exclude erroneous information. There is no set of items that you can automatically exclude after every capture. You must look at it the files and registry keys and decide if what Repackager captured really belongs with this installation. After doing a few these, you will get the hang of what can be excluded. If you find that you excluded something that should’ve been included, you can always change it back and rebuild the MSI.
A few general things to look for are files stored in Windows, system32/SysWOW64, and off the root of your system drive. Most applications do not write to these locations anymore. Again, you cannot just blanket exclude changes in these directories, but they are a good place to start.
On the registry side, things that write to HKLM\SOFTWARE\Microsoft or HKLM\Software\Classes can be excluded. In the Classes key, be sure not to exclude items that have to do with your product. Sometimes, file associations can be written to these registry keys. Also, anything written to HKLM\SYSTEM can normally be excluded.
The main thing to remember when excluding things is to just pay attention to what you are doing. If something seems like it’s needed, then keep it. Also, remember that if you exclude something and the install does not work, you can always go back and include it.
Example
Here is an example of the Repackager process. I am going to use Firefox as an example. This is a simple demo, but it will illustrate all of the features of the program. I will use the snapshot method to capture the installation. After install, I will set a bookmark that will persist into the MSI. After capture, I will compile it into an MSI, reset my VM to a snapshot, and install the MSI.
When you first open Repackager, you are presented with this screen. We want to capture an installation, so we select “Capture an Installation Using Repackaging Wizard”.
Next, you are presented with this screen. This is where you tell it if you want to use Installation Monitoring or Snapshot. Since I want to set a bookmark in my Firefox install, I am going to select snapshot.
On the next screen, I select multiple steps. The single step process is pretty much the same thing as installation monitoring, so we will not be able to customize Firefox. Once we analyze the system status, the second option, “Analyze system status changes”, will be selectable.
When we click “Next”, the system analysis will begin. This process can take some time, depending on your system. After the analysis is complete, you get this screen:
When you click Finish, the wizard goes away. This is where we install our application. I am not going to go through the Firefox install process, but I did use all of the defaults.
I am now going to open Firefox and set a bookmark.
While doing this, it also took care of initializing and authorizing any plugins. It also performed the import of IE settings.
Now that I have my configured application, I am going to launch the Repackager again. I select the “Capture an Installation Using Repackaging Wizard” option again. Select “Snapshot” again for the capture type, and you’re presented with this screen:
As you can see, the analyze system option is now selected. Just click “Next” on this screen.
Next is the product information page. Fill in these values and click “Next”. Note that the “Product Name” and “Company Name” options are required. These fields define their corresponding MSI property fields.
Keep the default package location on the next screen and click “Start”. Repackager now analyzes your system. Again, this process can take a few minutes. When it is done, click the “Finish” button. Repackager now launches the project.
This set of screens is where we can go through and exclude files, registry keys, and INI file settings. With this particular example, there were no files/folders that need to be excluded. Here is a screenshot of what I am excluding from the registry section:
As you can see, even with a simple installation, there were a lot of erroneous registry keys that the system captured.
Once you have gone through everything and excluded the bad data, we need to compile this into an MSI. You can do that by clicking the “Build” icon in the toolbar:
This constructs the MSI and saves it to “C:\Packages\MSI_Package”. You are looking for the file called “Firefox.msi” in this directory. Once you have the MSI, you can import it into SCCM, Group Policy, or whatever deployment system you choose.
After I built the MSI, I reverted my VM back to the snapshot and installed my MSI. Before reverting your VM, be sure that you copy the ENTIRE Packages directory off of the VM. You will need the entire directory (not just the MSI) to make any further changes.
Here is a screenshot of the Firefox windows, complete with my custom bookmark:
Summary
That was a quick and simple example of the power of Repackager. I have used it to repackage applications much more complicated, as well as capture settings such as the bookmark. I could have used Repackager to only capture the bookmark if I wanted too, or to simply find where the file is that controls Firefox bookmarks. More information and pricing for the entire AdminStudio suite can found here: http://www.flexerasoftware.com/.
In System Center Configuration Manager 2012 the spectrum of devices that can be brought under centralized management is significantly expanded. In SCCM 2007 Windows Mobile and Windows CE were the only platforms that could be managed, and to do this required native mode (http://technet.microsoft.com/en-us/library/bb633175.aspx). Does this mean that with SCCM 2012 you can now remotely manage application installs and OS updates for your organization’s iPhone, Android, and Windows Phone users, using just SCCM? Unfortunately no. However, you will still be able to take advantage of limited management for these devices via SCCM’s ability to connect to Exchange.
Combining ConfigMgr 2012 with Windows Intune enrollment allows more full-featured management of IOS, Windows Phone 8, and Android devices, including application deployment. However, if you don’t have or don’t want Windows Intune, this functionality won’t get you very far.
There are three ways to manage mobile devices using SCCM 2012 without Intune:
Enrollment by Configuration Manager
This method allows for robust management including software deployment and configuration baselines. However, Windows Mobile 6.1, Windows Mobile 6.5, and Nokia Symbian Belle are the only supported mobile operating systems.
Mobile Device Legacy Client
The legacy client method provides software deployment, software inventory, and monitoring. However, the legacy client is only available for Windows CE and Windows Mobile 6.0 mobile operating systems.
Exchange Server Connector
New in Configuration Manager 2012 is the Exchange Server Connector. This enables SCCM to connect to multiple Exchange servers, centralizing management of any device that is able to be managed via Exchange ActiveSync from within ConfigMgr. This feature is just another way to access and control Exchange’s mobile device management features, and as such functionality is necessarily limited. The main benefit of the Exchange Server Connector is being able to access functionality such as remote device wipe and settings control for multiple Exchange servers from within SCCM – there’s no new management capability for an organization that already manages mobile devices with Exchange ActiveSync.* It’s also worth noting that the Exchange Server Connector is only available for use with Exchange 2010 and later, and some versions of Exchange also require Configuration Manager 2012 SP1.
For more information on exactly what can be done with each method and to see Microsoft’s info on supported devices, check out the following TechNet resources:
Supported Configurations for Configuration Manager – http://technet.microsoft.com/en-us/library/gg682077.aspx
Determine How to Manage Mobile Devices in Configuration Manager – http://technet.microsoft.com/en-us/library/gg682022.aspx
CM 2012 does not provide a built-in method for alerting administrators when a remediation action fails for Endpoint Protection. When remediation fails, the device is still considered infected. Even more of a concern is if the infection changes Endpoint Protection settings.
This is the first of a two part series that will go over how to create an alert so that administrators can be notified when remediation fails. This part goes through the first half of creating the run-book, and next week will be the second half, and the other run-book that is required.
Background
In the Monitoring node on the CM 2012 console is a section for Endpoint Protection. If you expand this node, and select “System Center 2012 Endpoint Protection Status”, you can see a chart like this:
This chart shows you what is happening in almost real time. As you can see, I have four devices where remediation failed (ie the device is still infected) and one device where the malware modified the client settings. These are the machines we are focusing on.
By default, this chart updates every 20 minutes when Endpoint Protection summarization runs. You can set that value lower or higher by using the CM 2012 PowerShell cmdlets. Simply connect to CM 2012 using PowerShell (in the file menu of the console) and type:
Set-CMEndpointProtectionSummarizationSchedule -Interval <value> -UnitType <minutes, hours, or days>
To complete this runbook, your Orchestrator service account will need at least “Read-Only Analyst” in the CM 2012 console. This allows the service to execute WMI queries again CM 2012. If you want to do the query database step to grab the path of the infection, the Orchestrator service account will need “db_datareader” access to your CM 2012 database. You will also need to open port 1433 (TCP and UDP) from your Orchestrator runbook server to the server running the CM 2012 database. If you do not use the default SQL port, replace 1433 with the port number you use.
Preparing the System
For my process, I create a marker file that is the name of the device. I create this file in a share on the runbook server. You need to create this share before building the runbook. Creating the share is outside the scope of this article, but I do recommend hiding it (simply put a dollar sign ($) after the share name). Your Orchestrator service account will need Full Control rights for the share, and Read / Write / Modify NTFS rights to the folder containing the files.
When the runbook executes, it creates this file after sending the alert email. When the runbook executes again, it checks this directory for those files, and does not send another email if a file with the infected computer name exists. This is to prevent you from getting multiple emails for a single computer. I then have another runbook that runs that deletes these files once the computer is cleaned (more on that later).
Creating the Alert Runbook
Here is a picture of what your runbook will look like:
It looks complicated, but it’s actually quite simple. The items on the top line are the “essential” processes. These are what gathers the data and does the processing. The bottom line can be left out if you want. I will go through each one individually.
Find Computers with Remediation Errors
To get started, expand the “System” integration pack and drag a “Run .Net Script” activity into your workspace. Open it, click the “General” node, and give this step a name. I named mine “Find Computers with Remediation Errors”. Next, go back to the “Details” node, and set the language type to PowerShell. In the box, paste this code:
$a = @()
$epfailed = Get-WmiObject -ComputerName <FQDN of your CM 2012 server> -
namespace “root\sms\site_<3-digit CM 2012 site code>” -class SMS_CombinedDeviceResources |
where-object -FilterScript {$_.EPInfectionStatus -eq “4″}
foreach ($fail in $epfailed) {
$a += $fail.Name
}
This step creates an array of all devices where the EPInfectionStatus property is set to “4”. When a device infection status is set to four, it means that remediation has failed or the client settings have been modified by the infection.
Next, click on the “Published Data” node. Click the “Add” button, and fill the box in like this:
This publishes the list of devices to the next step. The variable name field is the value you assigned to the variable, and the name field is a common name for the variable.
Check to see if Computer has Alerted Already
Drag another “Run .Net Script” activity into your workspace. Open it, give it a name, and return to the Details node. Change the language type to PowerShell, and paste the following code into the script box:
$comps = “{Computer Name from “Find Computers with Remediation Errors”}”
$alerted = “No”
ForEach ($comp in $comps) {
If ((test-path \\<FDQN of server running marker share>\<share name>\EP\$comp) -eq $true) {
$alerted = “Yes” }
}
Delete the “{Computer Name from “Find Computers with Remediation Errors”}” part (leaving the outside quotes). In its place, right-click, go to “Subscribe”, and select “Published Data”. Select “Computer Name” from the box, and click ok. This inserts the variable. Remember this, as we will be doing this a lot through the rest of the article.
Now we need to publish some more data. Open the “Published Data” node again, select “Add”, and fill the box out like this:
This publishes the “alerted” variable to the next step, which tells the system there has already been an alert generated for this device.
Process Computer Data
Next, create another “Run .Net Script” activity. Open it, give it a name, and go to the “Details” node. Change the type to PowerShell. This the main activity in the runbook. It is what gathers all of the data needed to generate the alert email. Paste this code into the script box:
$comp = Get-WmiObject -ComputerName <FQDN of CM 2012 server> -namespace “root\sms\site_ <CM 2012 site code>” -class SMS_CombinedDeviceResources | Where-Object -FilterScript {$_.Name -
eq “{Computer Name from “Find Computers with Remediation Errors”}”}
ForEach ($infection in $comp) {
$compname = $infection.Name
$resourceid = $infection.ResourceID
$infectionname = $infection.EPLastThreatName
$sigversion = $infection.EPAntivirusSignatureLastVersion
If (($infection.EPAntispywareSignatureLastUpdateDateTime) -gt “1″) {$virdefupdate =
$infection.ConvertToDateTime($infection.EPAntispywareSignatureLastUpdateDateTime)}
If (($infection.EPLastFullScanDateTimeEnd) -gt “1″) {$fullscan =
$infection.ConvertToDateTime($infection.EPLastFullScanDateTimeEnd)}
If (($infection.EPLastInfectionTime) -gt “1″) {$lastinf =
$infection.ConvertToDateTime($infection.EPLastInfectionTime)}
}
$usra = (Get-WmiObject -ComputerName <FQDN of CM 2012 server> -namespace “root\sms\site_<CM2012 site code>” -class SMS_UserMachineRelationship | Where-Object -FilterScript {$_.ResourceName -
eq “{Computer Name from “Find Computers with Remediation Errors”}“}).UniqueUserName
ForEach ($usr in $usra) {
If ($usr -like “*”) {
$ = $usr
$usrname = $.replace(“\”,”") }
}
$ipa = (Get-WmiObject -ComputerName <FQDN of CM 2012 server> -namespace “root\sms\site_ <CM2012 site code>” -class SMS_R_System | Where-Object -FilterScript {$_.Name -eq “{Computer Name
from “Find Computers with Remediation Errors”}”}).IPAddresses
ForEach ($ip in $ipa) {
If ($ip -like “.*”) {
$ippub += $ip }
}
In this step, we are running three WMI queries against the CM 2012 server. The first pulls all relevant information from the SMS_CombinedDeviceResourses class. It is pulling the computer name, the resource ID of the infected client, the name of the infection, the anti-virus definition file version, the date and time of the last definition update, the date and time of the last full scan, and the date and time that the device was infected. All of this data, except for the resource ID, will be used in the email. We will need the resource ID for the query database step. All of the date and time variables are channeled through IF statements because the “ConvertToDateTime” action will error the PowerShell statement if the field is blank. I am not sure at this point why the field would be blank, but I have noticed it in some cases.
The second WMI query is pulling the primary user of the machine. It is also tunneled through an IF statement, because that value can also be a local user. This step pulls local users out, and only sends through the domain user. This is important in the “Get User” step that is coming up. Replace <domain name> with your domain name.
Finally, the third WMI query is pulling the IP address(es). This is piped through an IF statement also to strip off non-company IP addresses that get stored in CM 2012. Replace <first two octets of IP range> with the first two sets of numbers from your organization’s IP range. Make sure you keep the “.*” as is. It would appear that this section would form an array if a computer has a wired and wireless card. Because we do not have $ippub = @(), the array is never actually formed. If you actually type this into PowerShell and view the output, it will look similar to “192.168.2.3192.168.2.4”. This is the purpose of the next item. We will split these into two sections. It is important that this step is not an array, because Orchestrator recognizes an array and splits it into separate jobs, which would create two emails for one computer. This process (not adding $ippub = @()), essentially “flattens” the array.
Now we need to set up our published data. If you go to the “Published Data”, set it up like this using the same method from above:
To finish this action, we need to modify the connection between “Check to see if computer has already alerted” and “Process Computer Data”. If you double-click on the arrow connecting the two, you get a box like this:
If you click on “Check to see if computer has alerted already”, you select “alerted”. Once you do that, the statement changes so that it will only proceed if “alerted” equals some value. You specify this value by clicking on “value”. Put a value of No in this box. Once complete, it should look like this:
This concludes this part of the series. Next week we will talk about the second half of this runbook, and the runbook that removes the markers when created.
This is the third and final part in a series about migrating from SCCM 2007 to CM 2012. For a high-level overview of the migration process, please click here: http://www.windowsmanagementexperts.com/migrating-from-sccm-2007-to-system-center-2012-configuration-manager/migrating-from-sccm-2007-to-system-center-2012-configuration-manager.htm.
Migrating clients from SCCM 2007 to CM 2012 is the last step in completing your migration. As with the rest of the migration process, this step should be carefully planned and thought-out before attempting the client migration.
Migrated Client Data
When migrating clients from SCCM 2007 to CM 2012, the client GUID and advertisement history are preserved. This is how CM 2012 can put the client in the proper collections once it is migrated. Because the advertisement history is preserved, CM 2012 will also know what software has been installed on migrated clients, so any deployments to those clients will not re-run.
Data that are not migrated includes files in the client cache, data stored in the Configuration Manager Client registry, inventory information, and desired configuration management (DCM) data. CM 2012 will have to regenerate all of this data. Data the is stored in the client cache will be regenerated if the package is ran again from Software Center.
If you persist data in the client cache, this data will have to be put back after migration is complete. This may involve reinstalling the application that persists data. Also, if you have power schemes (SCCM Power Management), logging settings, or local policy settings saved in the Configuration Manager Client registry, these items will have to be repopulated.
App-V application data, because it is stored in the client cache, will also be removed. The App-V application will have to be reinstalled from Software Center to get the application to run again. Any data or settings stored with the application will also be removed.
No inventory information is transferred. As long as you put the same inventory rules in place that you have in SCCM 2007, all of this data will repopulate after an inventory cycle. Also, any data generated by desired configuration management will have to be repopulated. As long as DCM is configured in CM 2012, everything should repopulate.
The fact that a lot of this data is not migrated when you migrate your clients stresses the fact that you do not migrate clients until after CM 2012 is set up and objects are migrated. You must migrate packages, DSM settings, and recreate client settings before migrating any clients into the system.
Migrating Clients
There are four methods of migrating clients from SCCM 2007 to CM 2012. I will go over, in detail, three of these methods. The fourth method is manually installing the new clients on machines. In most environments large enough to run CM 2012, this will not be an option.
The first method is using group policy to install the client. You do this by using the “Software installation” node in your Group Policy object. I recommend doing the installation on startup (computer configuration) instead of logon (user configuration). The main reason is user vs. computer. If you install based on user, the client will try to install on any computer that a particular user logs in on, making keeping track of the migration process much more difficult. If it is applied based on computer, it will install for a particular computer once, and that’s it. To set up the install, simply copy the client.msi file from “C:\Program Files\Microsoft Configuration Manager\Client\” to a location where other GPO software installations exists. You will have to do separate installs for 32-bit and 64-bit. As long as you have your AD schema extended correctly for CM 2012, no other options or parameters should be needed (extending the AD schema is outside the scope of this article). Once the software installation is set up, the client will install on next boot up. The installation will proceed in the background and still allow the end user to log in and use the machine as if nothing is going on.
The second method is using software updates. You can add the same client.msi installer to your SCCM 2007 software update point and deploy it that way. You will need SCUP in order to do this. Adding updates via SCUP is outside the scope of this article. Again, as long as your AD schema is extended correctly, no additional parameters are needed.
The third method is to use client push to migrate clients. This is the simplest method. For this to work, you must have AD system discovery turned on. Turning discovery on will import all devices from a given organizational unit in AD into CM 2012. Once the clients are discovered, you simply add the clients to a collection in CM 2012, and push the client to the collection. It will uninstall the SCCM 2007 client and install the CM 2012 client. If a client is not turned on or not connected to your network when you push the new client, CM 2012 will continue to try to connect to the client. Once it is able to connect, it will install the client.
If you do not have your AD schema extended and want to extend it, see this TechNet blog: http://blogs.technet.com/b/configurationmgr/archive/2012/10/30/extending-the-schema-in-system-center-2012-configuration-manager.aspx. If you cannot extend your schema, add the “SMSMP=” as a parameter of your Group Policy and Software Update installations.
Best Practices
Microsoft has two recommendations that it considers as “best practice”. This first is to migrate clients in batches, and not all at once. The CM 2012 database can become overloaded with new information if you migrate too many clients at once. Also, quite a bit of network traffic is generated between the newly-migrated clients and the CM 2012 servers. According to Microsoft resources, a new client will generate 4.7 MB of traffic to sync itself with the new system. Migrating too many at once can overload your network. Sticking with 300-400 clients at time worked well for me. I would recommend taking it by organization functional unit when migrating.
The second recommendation is that you disable all advertisements and task sequences from SCCM 2007 when beginning the client migration. This will ensure that users are not trying to install software during an upgrade of their client. It will also keep network traffic lower, allowing for more clients to be migrated.
Summary
My preferred method of client migration is client push. This was very simple to do, and could be done “on-the-fly” as organizational units became ready. I was able to migrate the majority of our 6,000 clients in a week using this method. I was able to track these numbers by looking at the client push report, and also by creating a collection of computers that did not have the CM 2012 client. I could watch the successful installs, failures, and postponements from the report, and also see that number of computers in the collection drop. The biggest thing to remember is to plan. Evaluate which method works best for you, and test it thoroughly.
This is the second part in a series about migrating from SCCM 2007 to CM 2012. For a high-level overview of the migration process, please click here: http://www.windowsmanagementexperts.com/migrating-from-sccm-2007-to-system-center-2012-configuration-manager/migrating-from-sccm-2007-to-system-center-2012-configuration-manager.htm.
There are several key points that are worth mentioning again from the first article. The first is the planning your migration is vital. You must determine what data needs to be migrated, and what data needs to be rebuilt or redesigned. Second, collections are now either user or device based, not both. If you rely on collections with both users and devices, those collections will have to be redesigned. Third, not everything can be migrated. For a full list of what can and cannot be migrated, see this TechNet article: http://technet.microsoft.com/en-us/library/gg712991.aspx.
Setting up your migration
When setting up your migration, you need an Active Directory account that has full administrator rights in CM 2012. Microsoft recommends making this account the computer account for the 2012 primary server. This same account needs read access to all objects in your SCCM 2007 site. It also needs db_datareader and smsschm_users access to the SCCM 2007 database. You also must add this account to the “Distributed COM Users” group on your SCCM 2007 site server. By granting this account essentially read access to your SCCM 2007 environment, CM 2012 can make no modifications to it, so there is no risk of one system messing up the other system.
You must also open ports 445, 135, and 1433 (all TCP) from your CM 2012 server to your SCCM 2007 server. Port 1433 is for access to the SQL server, so adjust that accordingly if your SQL server runs on a different port.
Once your migration account and ports are configured, open your CM 2012 console and click on the “Administration” node. Expand the “Migration” tab, and right-click on “Source Hierarchy”. Select the “Specify Source Hierarchy” option. This is where you tie your SCCM 2007 system to your CM 2012 system. You should get a windows like this:
From this window, you specify all of the settings required for migration. In this window, the “Top-level Configuration Manager site server” is the FQDN of your SCCM 2007 server. Also, “source hierarchy” means your SCCM 2007 environment, and “destination hierarchy” means you CM 2012 environment. I recommend using the same account for the SMS Provider access and the SQL Server access. Once all of the information is provided, click OK, and CM 2012 begins to scan your SCCM 2007 environment.
Migrating objects
Once CM 2012 is done scanning the environment, you can set up migration jobs. From the CM 2012 console, select the “Administration” node, then the Migration tab, right-click on Migration Jobs, and select “Create Migration Job”. Give your job a name, then select the “Job type” drop-down box. You are presented with three options – Collection migration, Object migration, and Objects modified after migration.
Object migration is packages, task sequences, driver packages, images, etc. This makes a direct copy of the object, so if your source directory changes, you will have to change it on the package once it is imported into CM 2012. Migrate your objects in this order:
1. Software Distribution Packages
2. Operating System Deployment Images
3. Operating System Deployment Drivers
4. Operating System Deployment Driver Packages
5. Recreate your Boot Images (not migrate)
6. Task Sequences
Following this order will ensure that your task sequences are migrated successfully. Migrating your boot images is possible, but CM 2012 will want to recreate them with the newest version of WinPE, so recreating them is usually a better method then migration.
When migrating any objects, simply select the type, then the object (or group of objects), and then click Next.
You are then asked to confirm the sites. You should be able to keep the defaults. The next screen asks you to assign security scopes. Security scopes are outside of the scope of this article, but they basically are the new way to assign security rights in CM 2012 and work a lot like groups. Select the appropriate scopes, and click next. Read over the job information, then click next. The schedule window allows you to either run the job now, or schedule it. If you are migrating a lot of objects at once, scheduling the job may be beneficial, because the import process can be resource intensive on both the SCCM 2007 and CM 2012 servers. You can also specify what to do if there is a conflict. This runs based on the object ID and not the name, so be mindful of that. You can either set it to not overwrite current objects, or overwrite objects. Finally, you can have the system keep the same folder structure in the console.
After completing this window, click Next and view the Summary. If everything is correct, click Next and the migration job will execute.
Collection migration is exactly what it says – it migrates collections and their settings. This is also where you can migrate advertisements and turn them into deployments. The system reads the fact that there are advertisements related to the collection, and asks you if want to migrate those as well. If you plan to migrate advertisements, I would recommend doing collections last, because the packages and task sequences must be in place before the deployments can be created.
To migrate a collection, right-click on “Migration Jobs” and select “Create Migration Job”. Give the job a name, and leave “Job type” as “Collection”. Keep in mind that you cannot migrate collections that have both users and devices. These collections will not even show up in this list. You can click the “View Collections that Cannot Migrate” to see a list of these collections.
If you want to migrate advertisements, keep the “Migrate objects that are associated with the specified collections” option checked.
Check the collections that you want to migrate, and click Next.
The screen will list the deployments and packages associated with the collections that you selected. You can uncheck any of these options if you do not want to migrate something. Keep “Software Distribution Packages” checked, even though you have already migrated them. Click Next when you are ready to move on to the next screen.
Click Next through the site ownership screen. The next screen is the Security Scope screen. Apply security scopes as needed. Click Next through the next two screens (Collection Limiting and Site Code Replacement). Review the information on the next screen, and click Next. Configure schedule, conflict options, and organizational folder options on the Settings screen. These are the same settings we saw when migrating objects. The only new addition is the “Enable programs for deployment in the destination hierarchy after an advertisement is migrated from a source hierarchy”. This option does exactly what is says – activates a deployment after it is migrated. Click Next after all of the settings are configured. Review the summary, and click Next to run the job.
The final migration “Job type” is “Objects modified after migration”. This allows you to update an object if it is already been migrated. It will overwrite the object in the CM 2012 environment, so be careful when using this. It runs off the object ID, so just changing the object name will not keep it from being overwritten.
Summary
The most important thing with migrating from SCCM 2007 to CM 2012 is planning. It is critical to the success of your migration. When done correctly, migration can be very easy and really cut down on the time that you must maintain two systems. Lay out what you want to migrate and a timetable to get it done, and let the system do the rest.
Please be sure to come back for the third part in the series about how to migrate clients.
This is an article in a continuing series on the new Application model in SCCM 2012. You can find a high level overview of applications and how they differ from packages here: http://www.windowsmanagementexperts.com/sccm-2012-applications-vs-packages/sccm-2012-applications-vs-packages.htm.
Requirements allow administrators to target applications to users or devices that meet a certain setof conditions. The application model in SCCM 2012 expands greatly on the available requirements for packages. Now, administrators can target applications based on a wide variety of pre-defined rules. This part in the series will focus on the three categories of requirements: user, device, and custom.
You can add requirements to your application by opening the “Deployment Type” that needs a requirement and going to the “Requirements” tab. From here, you select “Add” and the category of the requirement. Multiple requirements can be added to one application.
User Requirements
There is one condition when selecting the user category – Primary device. For those new to SCCM 2012, the system assigns a computer to a user (known as Primary device) based on a time length that is set in the device client settings. This time-length can be set to whatever the administrator feels is appropriate. I have mine set to 8 hours (one working day) in a 14 day span (two working weeks).
This condition allows you to ensure that an end user can only install the application on their primary device. This can help a lot with licensing, because you can guaranteed that a user will not be able to walk around an organization and install a licensed program on multiple computers.
The converse is also true; you can set it where a user cannot install a given application on their primary device. I am not really sure why this would be necessary, but it is an option.
Device Requirements
Device requirements is exactly what it says – the administrator can base application installs on device information. Options include number of processors, memory amount, hard drive space requirements, etc. Any of these options come with logical operators so that targeting is simple.
This is also where administrators now set operating system requirements. This helps to ensure that end users are not trying to install 64-bit applications on 32-bit machines, and also that applications that require Windows 7 are not being installed on Windows XP. This condition works exactly the same way as it does with packages.
Two new options here are “Active Directory site” and “Organizational Unit”. Both of these options can be used to deploy an application to devices in a particular department without having to build a collection in SCCM for them. If your AD is already set up for department-based OU’s, there is no need to build a collection to deploy the application too. The administrator can simply define one of these conditions and be done.
Also, if you have multiple sites, applications can be required to be in one site or another using the “Configuration Manager site” condition. The “Operator” option allows the administrator to define an allowed group of sites, or a disallowed group of sites.
Custom Requirements
The custom category can cover anything that the user or device categories do not. There are options for file system, scripts, and SQL queries, just to name a few. As said in previous parts of this series, please always pay attention to the check-boxes talking about associating the requirement with a 64-bit application.
The four most useful custom conditions are file system, registry key / value, SQL query, and script. The file system condition can be used to detect if files or folders are / are not present. The application install can then be based on this. The same applies for the registry. This can be especially helpful with deploying application updates or add-ons where a base application is needed. The administrator can use these settings to define the rules by which these updates or add-ons are installed.
SQL queries can also be very helpful. The ability to query a SQL database opens up almost endless possibilities for application management. One such option is to create an application database for managing license numbers and which users should be able to install certain applications to keep within license agreements. It could also be used to query help-desk systems to see if an application is needed somewhere.
Finally, scripts can cover any other holes in requirements. You can load other libraries on the system to test for things, use WMI to test conditions, or anything else that is doable with a script. When you select Script, you are given the option to add one. From here, there are three scripting languages available: Jscript, Windows Powershell, and VBScript. From there, you can type your script in the box, or you can click “Open” and select a script that you already have prepared.
Summary
Exploring all of the new Requirement conditions in SCCM 2012 can really help with application deployment. Administrators can further ensure applications are only being installed on devices that need them and can adequately run them. If an application does not meet the defined requirements, it will show up the deployment reports for the application. This allows the administrator to see exactly why an application isn’t suited for installation on a particular device.
This is an article in a continuing series on the new Application model in SCCM 2012. You can find a high level overview of applications and how they differ from packages here: http://www.windowsmanagementexperts.com/sccm-2012-applications-vs-packages/sccm-2012-applications-vs-packages.htm.
Detection methods allow the administrator to check software installs to ensure that the application is not already installed. It can also prevent an install of an application if it conflicts with another application that is already installed. Also, during the normal “Application Deployment Evaluation Cycle”, the SCCM client can detect whether an application is installed using these methods, even if the user did not use Software Center or the Application Catalog to install it.
Default Detection Types
There are three default ways that SCCM can detect an application. Any of these methods work great, especially given the granularity at which the administrator can define the method.
File System
The first method is file system. This method detects whether a file or folder is present on the system. If the file system object is not present, the application is marked as not installed. The administrator can mark it as just being present, or apply logic to say that the file or folder had to have been modified after a certain date or equal a particular file version (just to name a few). You can use the “Browse” button to find the file on your computer. This will pull in all relevant information, such as the file version or modified date. You can also use the “Computer name” box to connect to a remote computer (Windows Remote Management must enabled in your environment for this to work).
One important thing to watch is the “This file or folder is associated with a 32-bit application on 64-bit systems” check box. By default, if you are on a 64-bit system, SCCM will only verify against “C:\Program Files” or “C:\Windows\system32” for files or folders and not “Program Files (x86)” or “SysWOW64”. If the application installs to “C:\ProgramFiles (x86)” or puts something in “C:\Windows\SysWOW64” and you queue off of that file, SCCM will not find it. When the user attempts to run the application, it will install again, possibly corrupting it or making it unusable.
Registry
The second method is registry. The first thing to select here is the hive. You can select any registry hive you want. You can use the “Browse” button in the same way that you can for file system. You simply put the Key path in the “Key” box, and the value in the “Value” box. In the “Data Type” box, select the type of the data the value holds. If you must test for the data in a key, select the “This registry setting must satisfy the following rule to indicate the presence of this application” and fill in the data in the “Value” box.
I would caution against using a key in HKEY_CURRENT_USER. This hive is loaded per user, and every user’s CURRENT_USER hive is different. Using this hive will work if the application can only be installed per user, instead for all users on a machine.
As with the file system method, pay attention to the “This registry key is associated with a 32-bit application on 64-bit systems” check box. This checkbox needs to be checked if you are targeting a key on a 64-bit system that gets put into “HKEY_LOCAL_MACHINE\SOFTWARE\Wow64Node” or “HKEY_CURRENT_USER\SOFTWARE\Wow64Node”.
Windows Installer
The third method is Windows Installer. This method is automatically filled in when using an MSI install type. This method detects whether the MSI product code exists on the system. This method should only be used when dealing with an MSI. If you do not use the MSI install type, you can use the “Browse” button and find the MSI installer to automatically pull the product code.
For products that update, but keep the same product code, you can use the “This MSI product code must exist on the target system and the following condition must be met to indicate the presence of this application” options to specify the version of the MSI. A product keeps the same product code if it updates via an .MSP file. It is best to test these before deploying them.
Custom Detection
If you cannot adequately detect your application using one of the default methods, you can use a custom script. SCCM determines that the application is installed if the script returns successful. To use a custom script, select “Use a custom script to detect the presence of this deployment type”. Click the “Edit” button to bring up the script window.
From the edit window, there are three script types. You can select PowerShell, VBScript, or JScript, depending on your preference. If you already have the script typed up, you can hit the browse button to find it, and SCCM will import it for you.
Again, pay attention to the “Run script as 32-bit process on 64-bit clients” check box. SCCM must execute the script properly for it to detect the application.
Logs
It can be difficult to get these methods working if they are complex. There are two logs that you can reference to see what SCCM is doing. They are “Appenforce.log” and “Appdiscovery.log”. These will give you detailed information on what exactly SCCM sees when it runs the detection methods, and the subsequent result. Appenforce.log shows the actual install of the program, while the Appdiscovery.log shows the discovery engine testing the machine for the deployment method. These logs can be found in “C:\Windows\CCM\logs” and are viewable using the CMTrace.exe tool.
Summary
While complex, these new detection methods allow administrators to finely tune their installers to ensure that they only get to the devices that need them. Setting these detection methods up correctly will also give you a better count of machines that have something installed. Even if the user does not install the application from Software Center or the Application Catalog, their devices will still register as having the program. This is a huge step forward in software management. This final screenshot illustrates this fact. The application shown here was only converted from a package to an application a week before this article’s writing. All of the machines in this count installed this software before it was converted. These statistics are viewable just be clicking on the application in the SCCM console.
Microsoft released its System Center 2012 Suite in April of 2012. With this release came a much improved and very different version of Configuration Manager. Right off the bat, SCCM now has a native console, instead of running off a MMC, which has improved the stability of the console. It also puts Software Center (formally Advertised Programs) in a website.
So why should you migrate? What is the migration process like? How much planning do you need to do? Which objects can be migrated, and which cannot?
Microsoft Documentation
Before even considering migration, the official Microsoft documentation on migrating should be read and considered. It can be found here: http://technet.microsoft.com/en-us/library/gg682006.aspx. This guide gives a lot of good information.
Pre-Migration Planning
As with any IT system, a lot of planning needs to go into this deployment. There are several key changes that must be considered. The first of these is that this is a true side-by-side migration. There is no upgrade path. This means that you will be maintaining two systems for a period of time. The extra time that this will take must be a consideration. One recommendation would be to “freeze” development of the 2007 system at a given point during the migration. This means no new packages, images, or anything except monthly patches.
Secondly, account access must be considered. To complete the migration, an account must be assigned to the 2012 site that has full administrator access to the 2007 site. This account gathers all of the data from the 2007 site. This account must also have rights to the 2007 site database.
Third, where is your image and software repository? If it is stored on a 2007 site server, it will need to be copied as well. The migration process can also only migrate images and packages that use a UNC path as their source path.
Fourth, is your environment optimized? Because this is a side-by-side migration, you can use the opportunity to analyze your environment and make improvements if needed. It can also be a good time to clean up old software packages, collections, and any other aged data.
Fifth, the SCCM client in 2012 relies heavily on Silverlight. Software Center and the Application web catalog are written using Silverlight.
Changes
A few terms change from 2007 to 2012. This is by no means a comprehensive list, just the highlights.
First, “Advertisements” no longer exist. They are now referred to as “Deployments,” and they are stored with the package or task sequence instead of in their own area.
Secondly, “Advertised Programs” is now “Software Center”. This is now a one-stop shop for software, updates, and operating systems. Certain client settings, that the administrator defines, can also be adjusted from Software Center. SCCM 2012 also allows for different client settings based on collection membership.
Third, collections are now either device-based or user-based. You can no longer have users and devices in the same collection. Collections are also organized into folders now, instead of having to put collections inside of collections for organization.
Migration objects
Packages and task sequences can be migrated. One consideration here is that if you use a 2007 site server as your software and image repository, these files will need to be moved and the source paths on all packages will need to be changed.
Collections can be migrated. Before migration, you must reconfigure collections that have both users and devices. These collections cannot be migrated with both. SCCM copies the membership rules that exist in 2007. During the collection migration process, you can elect to migrate advertisements, which will recreate them as deployments of your packages. Because of this, packages should be migrated before collections.
Security rights on objects cannot be migrated. The method by which access is granted to objects in 2012 is very different from 2007. Access is now granted based on your security role and security scope. You should read up on both of these concepts before migration begins.
A comprehensive list of objects that can and cannot be migrated can be found here: http://technet.microsoft.com/en-us/library/gg712991.aspx.
Client migration
Microsoft provides a guide on a few different ways to migrate clients from 2007 to 2012. They are client push, group policy, manual installation, software advertisement, and software update.
The most popular method is client push (you must have client push enabled and setup for this method). With this method, you simply use 2012 to discover the clients that you have in 2007, and then push the clients to them. It is not recommended to do all clients at once. You should consult your network administrator and figure out the number of clients that will not overload your network.
When you push the client using 2012, it uninstalls the 2007 client and installs the 2012 client. If you use Forefront in SCCM 2007 and System Center 2012 Endpoint Protection in SCCM 2012, it will also uninstall Forefront and install Endpoint Protection.
The client upgrade process retains only the client’s unique identifier (GUID) and advertisement history. It does not retain inventory information, power schemes, settings for logs, or local policy settings.
Conclusion
The migration from SCCM 2007 to System Center 2012 Configuration Manager is a worthwhile endeavor. There are many new features and improvements in the entire system. It is also a great opportunity to reevaluate your environment to ensure that the system is optimized for your environment. I would encourage anyone who is currently running 2007 to investigate the move to 2012.
With the introduction of SCCM 2012, Microsoft debuted a new way of managing software. This method is Applications. The new application model closed a lot of the gaps left by packages in SCCM 2007. This article will go through the similarities and differences between the two, and will also tell you when one may be better then the other.
The application model, combined with the application catalog, is where Microsoft is going. The day will most likely come where there is no Software Center and everything is done via the website that hosts the application catalog. Learning how to create and manage applications now, as well as beginning to slowly migrate your legacy packages to applications, will benefit you in the long run.
Differences
I will start with a quick run-through of the differences between applications and packages. First, applications are primarily designed for user deployments, while packages are primarily designed for device deployments. You can still use packages for user deployments and applications for device deployments – the settings in each type are just more geared for one versus the other. Either of these types can also be installed using required deployments, either for user or device.
Second, applications can utilize the new approval request feature. This is the feature that allows the administrator to deploy applications to a wider user base, while still maintaining license control. You can find an entire article on approval requests here: http://www.windowsmanagementexperts.com/sccm-2012-%E2%80%93-application-requests-and-orchestrator-alert-2/sccm-2012-%E2%80%93-application-requests-and-orchestrator-alert-2.htm.
Third, applications provide a much greater level of detail when looking at the application’s deployment status. It pulls up error codes, and also has more categories of statuses.
Fourth, the application feature can deploy apps to devices that are in the Apple App Store (for iOS devices), Google Play store (Android devices) or the Windows Store (for Windows Phone or Windows 8). This allows administrators to provide these apps in a managed format.
Applications
Applications give you more options to target particular devices. You can set detection method clauses to determine if a particular file, folder, registry key, or Windows installer code exists. If the condition is met, then the application either runs or it doesn’t, depending on what the administrator specifies. With packages, the administrator would have to specify certain files or file types in the Software Inventory section of the SCCM client. SCCM must have a pervious inventory record of these files or file types to create collections based on them. The application model makes this whole process much simpler, because it can look at any criteria on the fly. An article on these methods is forthcoming.
Applications can also be superseded. This means that if you update your version of Flash player, and you supersede the old version, the application will re-run, and install the new version of Flash without having to redeploy it. Applications provide an entire process of developing an application, deploying it, and then eventually retiring it.
For certain installer types, applications are very easy. If you have a MSI, SCCM will automatically set the name, manufacturer, version, and uninstall string (you change these if you want) for you. It will also set the detection clause for you based on the Windows installer code. This doesn’t only apply to MSI’s. It also applies to apps for the Windows Store that comes with Windows 8. Applications that come in a Scriptable installs format (i.e. EXE’s) will still work with the application method, but the administrator must add all of this information manually.
Finally, applications utilize single-instance storage (now called the content library), meaning that they only need to store the content once on your distribution points. For packages, content must be saved to the distribution point and to the package share to deploy software from the network (i.e. not have to download the content then run it). Applications do not have this restriction. They get saved one time, and run either from the network or by downloading the content first.
Packages
Packages are far easier and less time consuming to set up than applications. For an application, the administrator must figure out the correct detection clause, and fill out a lot more information. Packages are created the same way they are created in SCCM 2007, and the administrator only has about five screens to go through.
Also, management of the deployment of specific programs is separated with packages. With applications, you are deploying all of the deployment types that you set up. You cannot pick only one to deploy. The biggest issue this gives is if you need different user experience settings for an install from Software Center versus an install from a task sequence. Say you have one deployment type that is set to run only when a user is logged in or allow the user to interact with the program. Applications or Packages cannot be added to a task sequence with either of these settings. For applications, you would have to have two separate applications to do this.
One glaring disadvantage to packages is reporting. Applications have much more detailed reporting then packages. With packages you only get whether the install was success or failed.
Example of Application Deployment Status
Example of Package Deployment Status
Summary
Because Microsoft is moving towards the application model, enterprises running SCCM 2012 should begin migrating their legacy packages to applications. A tool to help you convert your packages to applications is available at: http://www.microsoft.com/en-us/download/details.aspx?id=34605. I hope this article helped explain a little bit of the differences between the two.
|
|
