Case Studies in Application Management

1. Case Studies in Application Management David Cristini Microsoft Technology Solutions Professional

2. Why are we here?

3. Why Application Management? Applications introduced into your environment, by default, have the following characteristics: • Inconsistent, proprietary, closed legacy formats • Built for a single-user interactive install • Not customized for your environment • Not thoroughly tested for your environment • Do not reflect your organizational standards • Do not support Windows 2000/XP architecture • Provide no means for mass targeted deployments

4. Why software delivery tools? • Plan, test, deploy, and analyze • Enables the complete lifecycle of application deployment from planning through verification • Provides complete inventory and usage tracking to be able to plan for such a rollout • Reliably and easily • Deploys successfully and reliably to locked down Windows environments • Enables rich targeting • Reduces overall costs • Right place at the right time. • Delivers all of these applications to highly distributed and complex enterprise environments

5. Customer Data Point: A Powerful Combination • AMS/SMS solution was very flexible when it came to the Bank’s needs • 60,000 users • 750,000 groups • Moved replication to their own customized DFS process

6. Application Management - Today Win 2000 SP 4 Win 95a ESD Solutions Setup.exe Other 3rd-party tools Manual Process Win NT 4 SP6 Win NT 3.51 snAPPShot file FTP Win 98 SE WinINSTALL Home Brew System Win Me SMS 1.0 file Email Win 95b Win XP “Sneaker net” Internal Applications Mobile Users Self-serve External Applications Current & Legacy Platforms • Inconsistent, Proprietary, & Closed Legacy Formats • Tedious Manual Verification of Application Conflicts and Application Compatibility • No Tools Available to Automate Conflict Testing • Disparate Application Packages Require Add-on Modules and Adapters to Integrate • Multiple Operating Systems • No Lockdown in Legacy Operating Systems • Multiple Conflict Tests

7. Application Management – where we’d like to be ISV Applications Centralized Conflict Database Internal Applications Robust Enterprise-Wide Application Library and Conflict Database Enterprise-Wide Management Solution Win 2000/XP MSI Legacy Applications • Common Industry Standard • Open & Editable Format • Self-Repairing • Standardized set of packaging and validation rules • Conflicts Identified & Removed • Shared Files Isolated • Integrated Management and Deployment System • Automatic Deployment Package Generation • Reliable Software Push • Uniform Operating System • Role-Based Application Deployment • Locked Down PCs • Lowest TCO

8. Customer Data Point: Deploying in a distributed environment • You never really understand your own infrastructure, in someone else’s region • Infrastructure is always the same, but business process is different in every region. • AMS bolting on to SMS was beneficial, because at the end of the workflow process they were just distributing an SMS package

9. Common Customer Scenarios

10. The reality of today What administrators tell us they deal with • Vendor installations seem to be getting worse, more complex • Not uncommon to spend a week trying to figure out package • Find themselves doing the same actions time and time again • Repetitive actions on every package • General lack of understanding about the installation contents • No way to gauge impact to environment • Fight constant balancing act of quality testing versus end user demands • No time to test but always time to fix failed deployment • Very little understanding from senior management regarding packaging • “Why can’t you just install the thing”?

11. What do administrators REALLY want? • Exercise complete control over the installation package • Truly deploy a package that meets all internal install standards • Common elements across packages automatically applied • Standards applied across each and every package • Detailed application impact analysis performed • How will adding this new application affect my production environment • Understand what shared components exist across the enterprise • If I change this DLL, what applications are affected • Shorten testing cycles while improving quality • Test more of the application while knowing less about it • Document efforts to show value to organization • Help educate management about the impact they have

12. And if they DON’T get what they want?... • Applications fail to coexist • Applications compete for different version of the same resource • Unstable systems • Critical LOB applications stop working • Productivity Lost • IT credibility is damaged • Support costs escalate

13. Some ideas to get started

14. Packaging Goals • Improve the Reliability of Applications • Decrease Costly Deployment Failures • Reduce Software Rollout Times • Standardize the Application Preparation Process • Increase Employee Productivity

15. Benefits of standardization Windows Installer (MSI) • A standard installation system to support the installation of all packages and software on Windows systems Advantages • Almost all vendors have begun to move their own installations to this format • Easy to use tools such as AdminStudio to repackage installations into this format • Staff only needs to be familiar with a single installation format MSI features • Self healing • Standardization of file versioning rules • Standard customization approaches to installations

16. Simplifying software packaging Use a clean system for packaging • Only base OS and service packs • Leverage virtual environments Packaging environment closely mirror production • Reduction in number of base images Utilize a template • Reduces repetitive tasks • Enforces corporate standards • Embeds required standards into package Utilize global exclusions • Reduces the time spent removing unwanted, unnecessary data

17. Common Customization Requests Resource modification • Files, registry entries, shortcuts • Configure ODBC • Environment variables Apply company standards • Add/Remove program behavior • Implement templates Custom Actions • Extend the functionality of the installation • Launch an executable during the installation

18. How to handle customization requests • Use Transforms for existing MSI packages • Simplified Windows Installer database with extension .MST • Modifies the MSI “as it is being installed” • Requires command line options or EXE-Style launcher • Nearly all aspects of the install can be modified • Never “repackage” vendor authored MSI

19. Package Testing • Tester may not know the application • Testing instructions are typically incomplete • What instructions were provided up front to packager • Application too complex • Time is always a factor • Never time to completely test but always time to react to problems • UAT • Some say single biggest challenge to complete testing • No control of user availability • Often times unwilling to “sign-off” on completed application

20. Customer Data Point – End Result • The net benefit was AMS + SMS was far more efficient and cost effective, and a huge enabler (doing more with less) • Having a workflow meant right information at right time • Gating step a to step b made sure all information was present)

21. Divide and Conquer

22. Customer Data Point: Segregation of Responsibility • Easy to outsource parts of the process • Packaging to MSI • Quality Control • UAT in a read only area • Handoff back to internal teams for distribution

23. AMS – Managing People and Process

24. Putting metrics in place

25. SLA – Report Summary

26. Software delivery progress

27. Detailed software delivery status

28. Looking forward

29. What’s next? – A Customer View • “Entitlement” • IT needs to be able to look at lifecycle of application • What’s the best way to determine if a user needs an application? • When a user falls out of entitlement, what is the next step? • How do we manage the removal process – uninstall? Reimage? Group Policy? • Software asset management – how to track usage? • Can I turn it off for a week, if they don’t complain, do I leave it off? • IT needs to think about managing software as an investment, and the most efficient way to do that. • Often more of a political battle than a technical one…how can technology ease the process?

30. Summary • Applications have changed over the years to become much more standardized • Software deployment tools will only be as successful as your packages • You can significantly reduce TCO by implementing some basic workflow management and tools to support software packaging & deployment and leveraging the OS for lockdown. Additionally, there is a lot of Microsoft guidance with MOF in this area for ITIL.

31. Thank you! davidcri@microsoft.com