Software Management Through GPOs

1. Software ManagementThrough GPOs Jim Pattenaude, Marshall CUSD #C-2 Terry Sullivan, Shiloh CUSD #1

2. Disclaimer • This session is intended for those using or planning to use Active Directory on Windows Server 2000 or 2003 with Windows 2000 Professional, Windows XP or Vista • The concepts discussed in this class do not directly pertain to earlier versions of Windows products or any non-Windows products

3. Introduction • Active Directory • Group Policy Objects • Microsoft Installer (msi) • Network install points • Alternate ways to automate software deployment

4. Methods for installing software • Traditional • Group Policy Objects • Scripts • Imaging

5. Traditional Method • Requires manual intervention at each machine • Requires administrator rights • Poor control over install options • OK for small installs or “exceptions” • Bad for large-scale deployments

6. Using GPO to install • Good way to deploy on large scale • Requires advance planning and testing • Tight control over install options • Does not require individual intervention at the workstation • Requires .msi file

7. .msi Files • Microsoft installer • All recent MS software includes .msi installer files • Much 3rd party software uses .msi • Tools available to build .msi files for apps that do not include them

8. Creating .msi files • WinINSTALL LE • Included with Windows 2000 • DISCOZ.EXE is used to build .msi • Requires “clean” computer • MakeMSI • Freeware tool • http://dennisbareis.com • InstallShield X • Commercial tool

9. Software Install Makers • My Inno Setup (Jordan Russell’s Software) • http://isx.wintax.nl/ • Advanced Installer 3.8.1 (Caphyon) • http://www.advancedinstaller.com/ • OnDemand Software $$ • Winstall & Winstall LE – 2003 • http://www.ondemandsoftware.com/PurchaseLE.asp

10. Demonstration • Creating a .msi file can take some time • Requires “clean” system to start • Make sure no other apps are running • Software takes “snapshot” of system before install • Installation proceeds as typical • Software takes “snapshot” of system after install • All changes are recorded and stored in the .msi • When newly created .msi file is run, all the recorded changes are applied to the target system

11. Problems creating .msi • Process not extremely reliable • Must be redone when software revisions are made • Time consuming

12. Group Policy Management Console (GPMC) • Included with Windows Server 2003 SP1 • Can be downloaded from Microsoft • Works with both Windows Server 2003 and 2000 Group Policies • Runs on Windows Server 2003 and Windows XP (currently will not run on 64 bit version)

13. GPMC Key Features • A unified graphical user interface (GUI) that makes Group Policy much easier to use. • Backup/restore of Group Policy objects (GPOs). • Import/export and copy/paste of GPOs and Windows Management Instrumentation (WMI) filters. • Simplified management of Group Policy–related security. • HTML reporting for GPO settings and Resultant Set of Policy (RSoP) data. • Scripting of Group Policy related tasks that are exposed within this tool (not scripting of settings within a GPO).

14. Network install point • Installer and related files must be on a publicly accessible share • Most .msi files have “administrative” install option that allows installing to a network share for mass deployment

15. Deploying Software through GPOs • Overview of process • Assigning vs. Publishing • Computer vs. User • Deployment Options • Transforms (.mst)

16. Overview of process • Create or open Group Policy Object • Determine if software installation will be by user or computer • Locate .msi package • Determine deployment method • Published (User only) • Assigned • Advanced (use for additional options) • Modify properties, security, etc.

17. Deployment Methods • Assign • Publish • Advanced • Choose to Assign or Publish • Set other options • Only way to specify transform (.mst) files

18. Assign vs. Publish • Assign • Automatically installs the software • Publish • software can be made available, but not installed • Not available for machine-based configuration

19. Computer vs User • Computer can only use “Assign” option • Software deployed based on Computer is installed upon computer boot • Software deployed based on User is installed upon user login

20. Deployment Options • Toggle Assign/Publish (User only) • Auto install by file ext (Publish only) • Uninstall when app falls out of scope of mgmt • Do not display in Add/Remove Prog • Install this app at logon (Assign only)

21. Transforms (.mst) • Used to apply customization • Different .mst files can be applied in different policies • Multiple transforms can be applied

22. Removing software • Right-click on package and select Remove • Option to remove immediately will remove software the next time the machine updates its policies • Option to remove package, but leave software installed • If option is checked to remove when app falls out of mgmt • Software will be removed when Policy is no longer linked • Software will be removed if machine is removed from OU where it is applied

23. Issues • Installer packages should not be used if user input is required • GPO software does not uninstall previously installed software (not installed by GPO) • Some app installers will remove old versions but this is not a feature of GPO

24. Installing through scripts • Software that includes an automated installer, but not a .msi file may be able to be installed using a startup or login script • Script should check if software is already installed to prevent unnecessary processing • Since scripts execute before user intervention is allowed, the installer must be fully automated • Possibly use install files (.inf or .ini for example) • Possibly use command line switches • Can still use GPO to deploy by including script in Startup/Shutdown/Logon/Logoff policy settings

25. Installing using imaging • Software can be deployed on software “images” using software such as Symantec Ghost • Install software using “traditional” method on “build” computer • Once all software is installed and tested for this configuration, run Sysprep • Follow manufacturer instructions for capturing the image and deploying to multiple systems

26. Software Restriction • Uses “hash signature” of app to identify • Can be used to specify “allowed” or “prohibited” software • New hash must be generated each time a new version of the app is installed • Use caution when saying only “allowed” software can be run

27. Process

28. Default Security Levels • If an administrator knows all of the software that should run, then a software restriction policy can be applied to control execution to only this list of trusted applications. • If all the applications that users might run are not known, then administrators can step in and disallow undesired applications or file types as needed.

29. 4 rules to identify software • Hash—A cryptographic fingerprint of the file • Certificate—A software publisher certificate used to digitally sign a file • Path—The local or universal naming convention (UNC) path of where the file is stored • Zone—Internet Zone

30. When to use each rule

31. Using Software Restriction Policies to Protect Against Unauthorized Software • Full detail & how-to from Microsoft • http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.mspx

32. Protect Against Unauthorized Software

33. MS KB article 324036 http://support.microsoft.com/kb/324036/en-us

34. Q&A Copy of Presentation: www.shiloh.k12.il.us/Presentations/SoftwareManagement Jim Pattenaude jpattenaude@marshall.k12.il.us Terry Sullivan tsulliva@comwares.net