1 / 13

System Center 2012

Sage Publishing. System Center 2012. Application Deployment. Building an Application. Application Types. MSI Easy. Easy to import into SCCM SCCM automatically detects product installation command, removal, and detection method. EXE Medium - Difficult.

hudgins
Download Presentation

System Center 2012

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Sage Publishing System Center 2012 Application Deployment

  2. Building an Application Application Types MSIEasy Easy to import into SCCM SCCM automatically detects product installation command, removal, and detection method EXEMedium - Difficult Medium – hard level of difficulty on import Possible to extract MSI from EXE Must include install and removal commands Must manually enter detection method SCRIPTDifficult Hard level of difficulty Must manually call all executions or commands Must manually write install and removal commands Must manually create detection method even if there is no direct way to detect the installation of the product

  3. MSI Application Auto Settings Detection Detection Method

  4. Exe Application Detection Method Application Settings • Must manually enter exe information and removal in this case requires scripting • Manually specified Detection Method often requires software be installed on test machine to collect info

  5. Scripted Installer Script Detection Method Application Settings Detection Method must be manually created even if there is no way to detect the success of the script Scripting might require multiple scripts and xml files to gain all desired functionality Both Install and uninstall are scripted and sometimes reference configuration.xml files

  6. Complex Script & Exe Installation Office 365 Deployment Below is an example of a complex script installer. First killing various processes, then installing the application based on a referenced XML Configuration file, and finally running a Powershell script for clean up. Something to note is that you should never place a network path in your applications or scripts unless you are a single site location. The reason for this is network paths hard code that location into the deployment. Defeating the purpose of a Distribution Point. Instead it should look like the above Batch file. Notice how setup.exe does not list its location. When this is the case the current working directory will be searched for that file. In the case of deployment the current working directory will be the folder distributed to the Distribution Points meaning you must distribute the folder with the setup files, the batch file, and in the case of the above the config.xml, and the Powershell script.

  7. Application Deployment Deployment to Users Deployment to Imaging • Deployments should almost always be made to user machines to avoid software accidentally being deployed to other computers the user logs in on • Applications must be deployed to a machine collection as available to appear in Software Center anything deployed as Required will appear on the Required tab • Software has to be made available on Distribution Points • Applications not deployed to users must have “Allow this application to be installed from the Install Application task sequence action without being deployed” box checked to be used in a TS without a deployment.

  8. Monitoring an Application Applications can be monitored through the Deployments tab on the Applications list. Here it will show the compliance state of each deployment. When checking compliance make sure to account for out of rotation machines, newly imaged, failed clients, and other variables that might offset this. Typically 90-95% depending on the deployment can be considered fully deployed. Sage Publishing

  9. Trouble Shooting Failed Update and Applications Deployments When an application or update fails you can click on the blue linked “Failed” status to receive additional information. From here you will be given a return code that can typically be translated with a simple Google search. The most common code is successfully installed but not detected. Which means the application installed but something is wrong with your detection method and the machine cannot verify it.

  10. Troubleshooting when the return code doesn’t makes sense or is generic Often times return codes can be generic or misleading due to the application actually erroring out rather than there being an issue with SCCM or the deployment process. When SCCM does not recognize the applications return codes it will do it’s best to communicate the issue. When this happens it is best to run the application first manually. If no problems come up changes the application settings to show the application when it runs as you see to the right. This way you can view any issues.

  11. Creating Custom Return Codes At times an application might be regularly problematic or may have it’s own unique success and failure codes. In those cases it is possible to customize the return codes that are sent to SCCM so that they are speaking the same language. Here you can add additional success codes if needed or change the current ones.

  12. When all else fails consult the logs

  13. Thank You Sage Publishing Thomas Faherty +1 805-793-5777 Thomas.Faherty@sagepub.com

More Related