About Packaging (and not virtualizing) Applications – Part II: First Approach for Silent InstallationsJanuary 14, 2014 at 9:39 pm | Posted in Application Packaging | Leave a comment
Tags: application packaging, best practices, MSI, silent installations
After the general overview about application packaging, benefits and best practices in Part I of this series, it is time to start working understanding existing installation packages, handle some examples and reviewing step-by-step processes we will need to start packaging applications.
In this second post, the focus will be packaging applications without the use of any 3rd party tool, basically achieving applications deployment with silent and customized installations. What we will review in this article:
1. MSI Files are your New Best Friends
a) Reviewing the Windows Installer
b) Using MSIEXEC.EXE
2. Understanding and Identifying Installer Vendors
a) InstallShield Overview
b) Wise Installation System Overview
c) Inno Setup Overview
d) SetupBuilder and ActualInstaller Overview
3. Packaging Examples for Silent and Customized Installations: First Approach
a) Finding our MSI when there’s no MSI
b) Creating and Using “.iss” Answer Files
c) Troubleshooting InstallShield Deployments
MSI Files are your New Best Friends
So, after we’ve decided that silent installations is going to be our first stop in packaging applications, we must know that MSI files provides the best way to achieve that.
An MSI file is a container that works with an embedded engine in the OS (Windows Installer service) in order to facilitate applications installations and uninstallations. This platform (MSI + Windows Installer service) contains all necessary instruments to accomplish a customized, automated and silent installation.
Later in the next following posts we will discuss on the components in an MSI file, but initially we can take a quick overview about the Windows Installer platform, the MSI files and how we should interact with them.
Reviewing the Windows Installer
The Windows Installer service appeared embedded in the Windows OS since Windows 2000 and with the solution to several problems about inconsistencies in the software vendors on how they were using the application installers, typically in setup.exe files.
The Windows Installer services function is to support the application life-cycle: installation and customization, maintenance (auto-repair and patching for example) and retirement. To process all of these steps is msiexec.exe. MSIEXEC takes all the information contained in the MSI file (installation database, a summary information stream, and data streams for various parts of the installation) and other optional (in most cases) files, to perform the installation or desired process.
These other files can be MST (Windows Installer Transform), which contains customizations for the installation (for example, features to be installed); MSP (Windows Installer Patch) representing application update/patch.
The complete list for installation files available:
It is important to remember that MSI files support silent installations natively; meaning that every application containing one will be suited for this type of installation.
We will take a closer look to the MSI components in the following posts when we start building our own. For now, we will focus on how to use them in silent installations.
As we were talking, msiexec.exe represents the engine from which the Windows Installer performs any of the life-cycle tasks of each application. Using msiexec, if you haven’t before, it’s simple and should not represent any problem.
Once we have our MSI file, using it for silent installations should be in most cases as the following example:
msiexec.exe /I <path_to_MSI.msi> /qn
- Using “/I” parameter at the beginning we are configuring MSIEXEC to install or configure the application (also known as “product”).
- The “/qn” parameter represents for a “quiet” (q) installation (no user interaction) and “No User Interface” (n). This way, the application will complete its installation without prompting any notification for the user.
If everything about packaging and deploying applications would be represented by MSI files, then these articles won’t be necessary. We’ll see that most of the times, we will have to deal with EXE files for deployment.
Also, using these EXE files could have different methods according the vendor that created the installer. In the following section we will review how to handle those situations.
Understanding and Identifying Installer Vendors
Even though there are plenty of EXE files which contain MSI files within (to be reviewed later in this post), there are other files with no MSI file available but supporting a silent installation method. To identify how we can silent install the application we must first understand which installer vendor (if any) was used for this app. Identifying is not always easy, the installer icon available could be helpful and sometimes we will just have to guess.
The most common vendors involved in installation files are:
- InstallShield, from Flexera Software
- Wise Installation System (formerly InstallMaster), from Symantec (previously from Wise)
- SetupBuilder, from LinderSoft
- ActualInstaller, from Softeza Development
- Inno Setup, from JR Software (open source project)
This is probably the most common vendor involved for developing installation files. We can easily identify their installers by reviewing the logo involved.
There are also two ways we can deploy InstallShield packages, which actually depends if the MSI file was included in the installation package:
1. If the MSI is included in the package, the InstallShield installer should support a silent installation using this example (the /v parameter is optional for verbose):
setup.exe /s /v"/qn"
2. If the MSI is not included there’s an interesting method for some legacy installers to use “answer files”, InstallShield calls this “Package for the Web”. We will need to run an installation with specific parameters to generate our answer file (“.iss”) that we can later use for deploying the application silently and with specific parameters. We will discuss the details later in this article.
The “Package for the Web” has been discontinued by Flexera Software, and it will no longer be available for InstallShield packages. But, most likely, in most organizations we can still find this alternative as a valid method.
To review the complete parameters available for InstallShield check this link: “Setup.exe Command Line Parameters”
Wise Installation System Overview
You will find this installation file type in some legacy applications in your environment. Wise Solutions was the creator of this platform, which originally started with CompuServe; later on was acquired by Altiris Inc, which also had been acquired by Symantec on 2007. The last release of this suite was 9.0 but has been already discontinued by Symantec.
The applications created with this platform support the classic “/s” parameter for silent installations.
But unfortunately there are no other options available for customization and the exit status when you executed the process was inconsistent, so it might get a little bit confusing.
Inno Setup Overview
This open source project has been receiving significant contribution of the community in all the years it has been available (since 1997), supports all Windows OS, including Windows 8 and Windows Server 2012.
The command line used for supporting silent installations in this suite are:
setup.exe /sp- /verysilent /norestart
- “/sp-“: Disables the “This will install… Do you wish to continue?” prompt at the beginning of Setup.
- “/verysilent”: Will execute silently the installation process. The “/silent” parameter is available but, even though it will not require users’ intervention will show a progress bar.
- “/norestart”: Prevents automatic restarts, which can be very useful if the “verysilent” parameter is used since it will automatically restart the OS without the user intervening.
For more information about Inno command lines available: “Setup Command Line Parameters”.
SetupBuilder and ActualInstaller Overview
SetupBuilder and ActualInstaller represent a couple of somehow new installation packagers’ vendors available in the market. Like many of these recent suites, both platforms support Windows 8 and Windows Server 2012.
One of the most common standards for recent installation packagers is the use of the same type of parameters for the silent and customized installations. SetupBuilder and ActualInstaller have the same silent installation method:
Among other providers we will find the same parameters that can be used, we have to be aware that sometimes the parameters are case-sensitive.
Packaging Examples for Silent and Customized Deployments: First Approach
Let’s review some of the examples we can find when we want to package applications using silent and customized deployments.
Finding our MSI when there’s no MSI
One common situation that we might find is that the application we are trying to deploy does not contain an MSI file, instead we are provided with an exe file that could not support silent installations. But, fortunately, most times there are some secrets hiding in plain sight.
When we are handling EXE installer files (usually as setup.exe), several times we are using an installer file that is actually a packaged set of files that contain an MSI, installation instructions and other optional files that could be used during the installation.
Companies use this alternative to have more scalable installation procedures that cannot be achieved with one MSI file. For example: Adding several MSI files which can be activated depending on the type of installation selected by the user. One example for this situation is Apple’s iTunes.
There are a two ways to extract the needed MSI file/s. Let’s review them using Google Earth as our application:
In the particular case of Google Earth, we need to download the standalone installer for the application available in this link.
1. Double click the EXE installer file and when the installation wizard starts access %TEMP% folder to locate our MSI. This process is called “expanding EXE packages”.
Most of the times, the files are located in a folder using a random name (in this case %TEMP%\._msige61).
2. Use 7-Zip File Manager to browse inside the EXE file. This free tool is quite useful, all we need to do is use the option “Open Inside” and we can browse around the installer and handle all the files within.
3. Some software vendors provide a command line to extract the files without the need to double click them or using 7-Zip File Manager.
Once we have our MSI, the process for a silent installation is simple:
msiexec /i “Google Earth.msi” /qn
Creating and Using “.iss” Answer Files
As we reviewed earlier in this article, InstallShield represents one of the vendors commonly used by software companies to create their installers. When we handle this type of installer, we get the simple option to use the “/s /qn” parameter or we might need to create an answer file.
This answer or response file is represented by our “.iss”. This file must be created running a command line which will install the software normally with all the desired options, but creating in the process the .iss file to be used in other deployments. Since every time we need to create an answer file we will need to install the software, using virtual machines and snapshots will be quite useful at this point.
InstallShield also supports the use of different compiled scripts, .ins files. Only applies for InstallScript and InstallScript MSI projects only, InstallShield version 12 and earlier.
The process for creating response files and then deploying the package is the following:
1. Locate your setup.exe (or the installer’s name) and a target machine to deploy the application (ideally a virtual machine).
2. Open a command line and execute the following to create the “setup.iss” response file:
The response file will be created in %WINDIR% (typically C:\Windows), but we can alternatively change the path by using the following command line:
setup.exe /r /f1”C:\setup.iss”
Note that there’s no space between –f1 and the “<>“ with the destination path.
3. Install the application with all the customization’s necessary.
4. Once is completed, locate the setup.iss file created.
5. To deploy the application, if we are using the .iss file with the default name (“setup.iss”) and is located in the same folder as the installer, we can deploy our package using the following command line:
setup.exe /s /v/qn
If we changed the name of the response file or we have it located in a different folder, the command line should be the following:
setup.exe /s /f1”<.iss name and location>”
Keep in mind that there’s no space between –f1 and the “<>“ with the file location.
6. [Optional] We can use /f2 as a parameter to create a log file for the deployment:
setup.exe /s /f1”<.iss name and location>” /f2”<.log name and location>
If we don’t set log file name and location, it will automatically generate “setup.log” file.
Troubleshooting InstallShield Deployments
In case there’s a deployment issue with our package, creating the setup.log would be mandatory in order to find out the exact problem we have.
The Setup.log file contains three sections.
- [InstallShield Silent]: Identifies the version of InstallShield Silent used in the silent installation.
- [Application]: Details Installed application’s name and version, and the company name.
- [ResponseResult]: The result code indicating whether or not the silent installation succeeded.
The result codes can be one of the following:
-1 General error.
-2 Invalid mode.
-3 Required data not found in the Setup.iss file.
-4 Not enough memory available.
-5 File does not exist.
-6 Cannot write to the response file.
-7 Unable to write to the log file.
-8 Invalid path to the InstallShield Silent response file.
-9 Not a valid list type (string or number).
-10 Data type is invalid.
-11 Unknown error during setup.
-12 Dialogs are out of order.
-51 Cannot create the specified folder.
-52 Cannot access the specified file or folder.
-53 Invalid option selected.
In the next article we will review more details about silent and customized deployment, including more examples in more complex scenarios.
Tags: application packaging, best practices, MSI, silent installations
It’s been a while since I don’t write new entries in my blog, so I decided to get back on track with a few articles about packaging applications. But, the approach won’t be from the virtual applications perspective, will be focusing on that strange matter of building the right installation, configuration and deployment process for your applications.
What We Will Cover
Packaging applications represents a very vast set of topics that we can discuss, even if we take the virtualization off the table. Here’s a short summary of what we will cover in this set of posts:
- Understanding Application Packaging
- Silent installations vs. MSI customized packages
- Benefits of Application Packaging
- Packaging Best Practices
- Packaging Applications without 3rd Party Tools (silent installations): Reviewing best practices; Packaging Examples; Troubleshooting .
- Packaging Application with 3rd Party Tools: Reviewing the Windows Installer; Reviewing best practices; Packaging Examples; Troubleshooting.
Understanding Application Packaging
Let’s take a moment to talk about application packaging and the statement I’m using about using or not 3rd party tools to achieve it.
Application packaging can actually have several definitions by itself, and it can definitely vary depending on each situation and the outcome we are looking for. But, in a simple manner, I can say that application packaging represents the process from which we can get an automated method to deploy applications with the proper configurations for our environment.
To achieve that, basically, we have two alternatives: Using silent and customized installations or using 3rd party tools (like AdminStudio or Advanced Installer). This second alternative can generate for us, from “capturing” a valid installation, a customized MSI file with the personalization we need for that application (keep in mind that MSI files are, by definition, installation files that can be silently installed).
Silent installations vs. MSI customized packages
Considering silent installations and MSI customized files as valid forms of packaging, we need to establish when we want silent installations or capturing MSI files for deployment.
The answer will depend on these two initial questions:
1. Does the software provider support silent installations and how many parameters can we introduce?
Many providers give us the opportunity to achieve silent installations with all the necessary configurations for our environment. Autodesk and Adobe are great examples, since they provide their own engine to generate “answer files” for the installation process and achieve automated and customized installations.
Many others include in their “User Guide” the right parameters we can use to get similar results in the installation process and some just not provide any method for an automated process.
This is what Autodesk offers us to create our own packages (applies for any suite). A simple wizard to follow and create a “deployment type”; the outcome we can later deploy automatically with all necessary customizations.
2. How many customizations I need to perform in my package in order to have it ready for deployment?
In some cases we have the possibility to perform silent installations with personalized configurations, but sometimes these are not enough. There are several examples of licensed software that require introducing licenses using a manual process; this could be an example of applications that might need for 3rd party tools for packages creation.
Take a closer look to the documentation available for the application and review the parameters we can use to deploy the applications without generating a customized MSI.
In my personal opinion I always try to use the silent installation method as the preferred one. This is because, if the software provider gives us the chance to install and customize the software automatically, then we have an official support and “guarantee” that this software is going to be installed in a proper manner.
If we decide to capture and create an MSI of our own, the package will depend on the software and type of “capture” we will be using for this application; and of course having the risk to exclude files and registries that will be required later using the app.
Benefits of Application Packaging
Let’s take a quick moment to analyze why application packaging is highly recommended in almost any company:
1. Customizing the application so it can fit to our company’s needs and policies: No matter if you are using silent installations or customized MSI, you should be looking for a way to configure your applications properly among all users.
2. Provides an easy, predictable and repeatable way to deploy our applications: Removing the complexity in deployments and the possibility of user misconfigurations not only saves us troubleshooting time but money we need to invest in admins for deployment and support.
3. Helps us standardize our users’ desktops: Related to the previous benefit mentioned, having the standard method to deploy applications also facilitates us in the OS and applications life-cycle; easier to maintain and update.
4. Gives you the possibility to limit the administration rights delegation: When you are using non-packaged apps, you will depend on users or delegated admins to install, reconfigure and/or uninstall applications. Having packaged applications and a deployment tool to deliver the applications, you can annul distributing admins rights to users or help desk personnel for example.
First Approach to Packaging Best Practices
Prior to get our hands into some examples of packaging applications, I want to take a moment to review some of the general best practices when we are packaging applications. When we start talking about some examples, we will take a deeper look into these best practices and some other specific for silent installations or using 3rd party tools for packaging.
1. Understand the application and the environment you are using.
Review applications requirements, documentation (if any) and the scenario you will need to deploy each application. Understand the purpose of the application and targeted users. Understand the environment you will be using for deploying the applications: The distribution method available, operating systems involved, and so on. We usually tend to use a comfortable and predictive environment for packaging the application, this most likely won’t be the environment you’ll be deploying it.
2. Review and write down common use cases for each application so you can test it properly.
Once we completed packaging an application we need, of course, to test it. And it is important to remember that we cannot complete a test just by verifying the installation has completed, we need to have a small group of tests to run on each application, consider having a talk earlier with each application owner to verify the tests you might need to run in order to validate the app functionality.
3. Don’t start packaging until you have the final OS image ready.
Operating systems represents an important part in the packaging process; applications behavior should vary depending on the Service Pack level installed, features implemented (a good example is .Net Framework), other basic components and software to be installed, configurations to be used (for instance, UAC enabled/disabled). If we are using an image as an assumption for the targeted operating systems, we could find several problems with packages not being able to install or applications malfunctions.
4. Prepare a virtual machine with OS “gold image” and use snapshots for packaging.
It is important to have a fresh OS image available whenever you are going to package a new application. And using the term “fresh” doesn’t refers on having a Windows OS without any application installed, should be the “gold image” from which the applications will be later deployed. Having the possibility to virtual machines and snapshots will be crucial to facilitate the process.
5. Try using silent installations as the first option for packaging.
Like I mentioned earlier, using silent installations is the preferred method to start packaging an application. With that, we are ensuring that our app will be installed and supported by the vendor involved. Using a customized MSI file we could have a higher level of personalization and even improving package size and deployment, but it could also result on having to later troubleshoot the application functionality because we excluded necessary files in the app environment.
Also keep in mind that several applications are not suited to be re-packaged into a new MSI and even though you can create a customized packaged, the deployment process won’t succeed.
6. Try not to think applications to be packaged as independent from their OS or other applications.
Since we are not virtualizing applications, these packages won’t exist in a “bubble”, they will have dependencies with OS components as well with other applications. We usually try to package an application in the best scenario, like a fresh installation using from a virtual machine snapshot. We must pay attention if the application could require a reboot for completion, if we are deploying several applications our process could be stopped waiting for a reboot from the previous package. Also, one application requirement could be conflicting with the requirement from a different application.
Try to think out-of-the-box and review any dependencies that could appear in production.
7. Be methodical in the application packaging process
Plan your packaging and deployment processes; document what you are going to do and the tests you perform; prepare checklists and any other thing that can help you and others along the process. If any constraints are found in the packaging process (for instance, applications that require a reboot to complete deployment) write it down and use that information to adjust your planning in the deployment process.
Having a predictable way to package applications will help you and colleagues in their jobs.
In the next post I’ll be reviewing some examples and hands-on processes for applications silent and customized installations.
Tags: Books, E-Books, Free Stuff, Windows 8
I haven’t got much time for publishing new articles in my blog, but I found this brand new publication and I thought it could be useful for a lot of people around there: “Introducing Windows 8, an overview for IT Professionals” (preview version).
This book has some quite important topics that every IT guy which is considering implement Windows 8 in their company should read it carefully. Here’s a short summary for the topics included (I’m just naming a few; the entire list is available in the download):
- 1. Overview
- 2. Experiencing Windows 8
- 3. Windows 8 for IT Pros
- Customizing and configuring Windows 8
- Client Hyper-V
- Redesign NTFS
- PowerShell 3.0
- 4. Preparing for Deployment
- Windows 8 SKUs
- Application compatibility
- User state migration
- Windows To Go
- 5. Deploying Windows 8
- Windows Assessment and Deployment Kit
- Deployment and Imaging
- User state migration tool
- MDT 2012 Update 1
- e. SCCM 2012 with SP1
- f. Desktop Virtualization
- 6. Delivering Windows Apps
- 7. Windows 8 Recovery
- 8. Windows 8 Management
- Group Policy Improvements
- Windows Intune
- Mobile device support
- 9. Windows 8 Security
- 10. Internet Explorer 10
- 11. Windows 8 virtualization
- Virtual Desktop Infrastructure
- Application Virtualization
- User State virtualization
I did not read it completely, but for what I’ve seen so far the content is not fully detailed with step-by-steps but contains valuable information and guidance that must be read it if you are implementing / managing Windows 8.
Tags: App-V, application virtualization, giveaway, Packt Publishing, winner
The giveaway contest for my latest book: Microsoft Application Virtualization Advanced Guide ended June 30th. Now, we can confirm that our happy winner received the book.
Rajesh Attaluri from the UK received is the winner for this contest and is sharing with us a pic. Thank you Rajesh!
Thank you all for participating in this contest and as a reminder, the book is available in the following stores:
Tags: App-V, application virtualization, Books, contests, Cool Stuff, Free Stuff, giveaway
As I did for my first book, celebrating the publication of my second App-V book: Microsoft Application Virtualization Advanced Guide, I’m giving away a free paperback copy among my readers.
Here’s a short summary for those who want to participate:
- Email me at email@example.com with the subject: “App-V Advanced Book”.
- Include in the email body your full name plus the address where you would like for us to send the copy.
- I’ll close up the contest on June 30 (2012, just in case). All the emails sent until that date will be included in the election, which will be completely random.
- I’ll notify the winner in the following days and we’ll ship a free copy of “Microsoft Application Virtualization Advanced Guide”.
To avoid any problems, here are some disclaimers:
- Only one email by person will be included. Do not use different mail accounts to participate several times.
- Emails that don’t include person’s full name and address will not be considered valid.
- We’ll cover the expenses regarding shipment but we are not responsible for extra fees or taxes other countries may include in the package.
- Please don’t send any email requesting exceptions to this contest (like asking for a digital copy of the book), I’m not allow to do any of those.
Tags: Interviews, Q&A, Question and Answer, System Center, System Center Configuration Manager
A while ago I started this Q&A series of posts interviewing Aaron Parker (App-V MVP and reviewer of both of my App-V books); and continuing with this series, this time is turn for Rod Trent (myITforum.com owner and CEO).
Rod has been contributing to the IT community in several ways: Evangelizing technical communities, books and articles written, and of course engaging with the large System Center community around the globe with myITforum.com.
You can find more about Rod following him on Twitter: @rodtrent.
Here’s the Q&A:
1. To start with the interview, can you give us a quick synopsis about yourself, your experience and myITforum.com?
I’m a father or four children, ranging from 3 years old to 21 years old and my wife and I, Megan, just recently celebrated our 22nd wedding anniversary. I am a faithful, church-going Christian, an avid gadget fan, a die-hard old television show and cartoon buff, a health and exercise freak, a long-time evangelist of System Center products, and a part-time missionary to the Chinese people.
I have written many books, thousands of articles, and speak at various conferences and User Groups during the year, but my main, professional focus is evangelizing technical community on the web and in “real life”.
I have been in IT for over 25 years. I actually got my start as a computer salesman, moved on to managing a computer repair center, and then finally migrated IT in the early 1990’s, working for a large accounting firm. I have been blessed with a real aptitude to be able to just “fix things.” IT is the perfect industry for that. So, while I’ve kept the techie side, over the years, due to working with myITforum.com, I’ve also become a marketing person. myITforum.com flourishes through the way we highlight and interact with our sponsors. We don’t charge to be part of the community, instead our sponsors help offset our costs, allowing everything on myITforum.com to be free. We don’t believe that support, community, or content should ever have a price tag. So, while it was never an intention of mine to become a marketer, my experience over the last 10 years has been vast, and has served of sponsors well enough to continue building a strong and large community.
Way back in the SMS 1.x days, the product was barely supported by Microsoft itself. So a grass-root, community for SMS 1.x was started on an old, BackOffice support site called, Swynk.com. I ran the SMS section of the web site. I posted articles and tips for SMS since I worked with it daily in my job in a top Accounting Firm. SMS 1.x actually saved our lives at work, giving us the ability to manage desktops with only a handful of support people. So, I simply started sharing my knowledge online. After a few months of success, I was offered a section manager job that paid something like $15 per month and a free technology book.
Traffic and popularity continued to increase, and the community grew larger and larger. Then, at the SMS and Windows 2000 conference (what MMS was called prior to being the Microsoft Management Summit) I was told that Swynk.com was going to be sold to Internet.com. This created a huge issue, as the community cried out with the knowledge that it could, potentially, be broken up.
So, with a little ingenuity and a great set of industry contacts, myITforum.com was born. The community was offline for maybe, 2 months, and then we unveiled myITforum.com 1.0. myITforum.com has gone through numerous changes over the years, but the basic premise has remained. We just help people – and give folks a central location for support, education, training, networking, and giving honest, direct feedback on System Center products.
There’s much, much more to it than that, but that’s the basics. And, the basics work. myITforum.com now receives a little over 145,000 visitors a day, all looking for help and all looking to learn how to manage their environments.
As many probably know our success with myITforum.com and great partnership with Microsoft has led to additional opportunities to be able to reach out and provide community support services for various Microsoft conferences like TechEd and the Microsoft Management Summit. We always look forward to having the great opportunity to “communitize” boring, technical events, and give them that something special to make them memorable and extra valuable.
2. You’ve been really close to System Center evolution over the past years, what do you think about the 2012 editions of this suite? Having all products with the 2012 editions will make a difference in the market?
Pulling the products together is a smart idea, and should really prove gains for Microsoft. ConfigMgr has been the real winner for so long, with very little uptake for the other products. Hopefully, by bringing the products together, particularly from a licensing standpoint, will allow the other products to catch hold. It will be interesting to watch as customers try-out products they would not have before simply because the products are now part of the license agreement.
3. In the past there weren’t many companies that decided to implement the full System Center suite (SCCM, SCVMM, SCDPM, and SCOM) and chose other technologies or simply did not use any tool for specific tasks. Which are the challenges a company should take note in order to consider implementing this complete suite (including also Service Manager)?
Glad you mentioned Service Manager as part of the question. There are pieces of the System Center suite that still seem a bit convoluted and still beta-esque. Service Manager is one of those components. But, whether it’s Service Manager, or some other product, education is the key. Those that have been familiar with specific products, and the way they work, will need to get up to speed quickly, and understand how they can all work together. Orchestrator, in my opinion, is the glue between all of the products, and that may be the single most important piece to understand first.
4. Which are the products and features that you think CTOs and IT decision makers should pay attention the most in the System Center 2012 suite?
From a CTO and decision maker standpoint, I believe the provisioning of the private cloud will be one of the most important aspects. As shown at MMS 2012, you can provision a private cloud in less than 30 seconds. This enables IT organizations to save time, money, and provide SLA and support at unimaginable levels.
5. In the System Center 2012 suite, is there a feature or product that you think might be improved or a missing functionality that should be included in a R2?
I hate to keep harping on Service Manager, but additional functionality is needed to make it easier to work with. Also, in ConfigMgr, Microsoft has to somehow get past the Exchange connector function when supporting mobile devices.
6. Regarding companies’ investments in IT (hardware, services, products, human resources), how do you feel the next few years would be like? Is the cloud model taking over company’s strategies?
The Cloud is on the horizon, but from what I hear in real circles, Microsoft believes it’s closer than anyone else does. It makes sense that they believe this, though, since they are putting so much behind development and marketing of the Cloud from the Microsoft perspective. I believe Microsoft will be highly successful in the private cloud – as to when, that’s up to the customer to decide.
7. With thousands of companies using iPads, iPhones, Android phones and tablets and so on; to maintain compliance, availability and security onto these devices, which is the best approach for client device management?
In line with what I mentioned previously, ConfigMgr and even Windows Intune help to better manage devices like iOS and Android. In fact, Windows Intune may actually do it a bit better than ConfigMgr right now, but I fully expect those functions to show up in ConfigMgr over the life of the 2012 product. If a company wants to manage these devices right now from a full management perspective, they will still need to source a 3rd party; one that provides full integration with ConfigMgr. Odyssey Software (now part of Symantec) is still the best 3rd party solution available.
8. About virtualization and particularly VDI, do you think this trend regarding virtualizing desktops will increase significantly in the following years?
I definitely believe this will happen. In fact, I believe this will become so seamless and so common that it becomes part of normal operating procedure. Right now, VDI gives organizations the ability to not have to worry about compatibility issues with corporate software as they migrate to new technologies. In the very near future, possibly, this will lead to PC operating systems supplied solely from the cloud.
I hope you enjoyed this interview; I’ll get back soon enough with more Q&A sessions.
Tags: App-V, application virtualization, Books, discounts, Packt Publishing
“Packt Microsoft Carnival” is a special offer released by Packt Publishing during May from which you can acquire several Microsoft’s titles with important discounts, including “Getting Started with Microsoft Application Virtualization 4.6” and “Microsoft Application Virtualization Advanced Guide”.
Packt’s Microsoft Carnival includes a variety of titles on App-V, BizTalk, SharePoint, SQL Server, Silverlight, .NET Framework stack, XNA, Forefront, System Center and more.
Packt has slashed the cover prices on its selected Microsoft titles by up to 30%. Some of the books include:
- Getting Started with Microsoft Application Virtualization 4.6
- Microsoft Application Virtualization Advanced Guide
- Microsoft SQL Server 2012 Performance Tuning Cookbook
- BizTalk Server 2010 Cookbook
- iPhone with Microsoft Exchange Server 2010: Business Integration and Deployment
- Microsoft System Center 2012 Endpoint Protection Cookbook
- Microsoft Data Protection Manager 2010
My two App-V books are also available in other stores, but the “Packt Microsoft Carnival” discount only applies in Packt Publishing site.
Tags: Deployment, Unattended Deployment, Unattended Files, WDS, Windows 8, Windows Deployment Services (WDS)
In the first post of this series we’ve already reviewed the initial steps for preparing Windows Deployment Services (WDS), adding boot and clean Windows 8 images into the environment, an also how to capture a reference Windows 8 image for deployment. Now, it is time to take a deeper look into the unattended process for deployment.
In this post we will complete our step-by-step guide for unattended deployment of Windows 8 images: Understanding unattended deployment process, generating our own unattended/answer files, reviewing some examples and deploying a full Windows 8 image using our unattended files.
Understanding Unattended Files
The process of automated and silent deployment of an operating system, as well as for any application, depends on parameterizing correctly our setup. These parameters are stored in what we call unattended or answer files.
Starting in Windows Vista / Windows Server 2008 (these two have the same OS kernel), Microsoft improved the setup process of operating systems making it highly scalable and simpler. That’s why these unattended files are presented in an XML.
Using XML as unattended files makes sense since this markup language is used to structure, store, and transport information. Structure is a key term because Windows setup is composed by “configuration passes” which are basically the phases of a Windows installation; and the answer file can structure the information in an efficient manner to offer answers for each phase.
Reviewing Configuration Passes
As we said, the configuration passes represents the phases included in a Windows installation; those phases are basically the same since Windows Vista, even though several of its components have changed over time.
To understand a little bit more about the unattended files we are about to create, let’s review the configuration passes included:
- windowsPE: In this phase we can find the configurations and parameters used in Windows Preinstallation environment (reviewed in Post I), for example handling the disk where we are going to install the OS.
- offlineServicing: This configuration pass is used to apply updates, drivers, or language packs to a Windows image.
- generalize: In this phase computer-specific information is removed from the Windows installation enabling you to capture and reapply the Windows image to different computers.
- specialize: In this stage we can find several Windows configurations like enabling features, network settings and domain settings.
- auditSystem: This phase is only used when we select to boot using audit mode. Settings apply here before a user logs onto the computer, for example to installing out-of-box drivers.
- auditUser: This phase also runs when audit mode is selected in the boot process. Here are settings applied when a user logs onto the computer.
- oobeSystem: In this configuration pass, settings are applied before the “Windows Welcome” message starts. Some options usually used are language or creating user accounts.
Here’s a short diagram, taken from Microsoft TechNet, to explain the configuration passes:
For more information, visit the following link: “How Configuration Passes Work”
Reviewing Unattended Files Best Practices
Before we jump into creating our own unattended files, let’s review some common best practices we need to know:
- Review and understand configuration passes: We need to have the installation phases clear as we explained above; understanding them will allow us to use the right components and settings.
- Always validate answer files: Windows System Image Manager (WISM) is the tool we are going to use to create our unattended files; this tool includes the option for “validation” which verifies that the settings we’ve configured are set correctly and there’s no inconsistency.
- If you have Windows Vista / Windows Server 2008 unattended files, do not try to use the same for Windows 7 or Windows 8: Even though all of them use XML files, there have been several changes in time. Take a look to the following link: “Changes in Unattended Setup Settings from Windows Vista and Windows Server 2008”.
- Don’t add unnecessary settings: Answer files could contain hundreds of settings, which translate in time to parse them and slow installation processes. Do not use unnecessary settings that could delay the OS deployment.
- When you are not sure about the setting value, try WISM help: All of components include a “help” option which describes the setting and provide some examples. If you are not sure what value to use or if you can leave the setting “empty”, check the help file to verify.
- Use separate answer files for separate images and architectures: It is not convenient to use same answer file to different OS architecture. Even though it is possible to include same settings for both architectures in the same file, it could lead us into deployment problems or failures.
6. Preparing Windows System Image Manager (WISM)
Windows System Image Manager (WISM) is included in the Windows Automated Installation Kit (AIK) as one of the tools offered to customize Windows OS deployments.
Using WISM we are going to be able, taking a selected OS image, to retrieve the configuration passes included and modify the settings available on each phase. To prepare it for creating our unattended files we only need a simple process:
6.1. Download and install Windows Automated Installation Kit (AIK).
6.2. Copy the “install.wim” file from Windows 8 media to a local folder (must be available to WISM for read/write operations).
If we don’t have the media available, we can still use the reference Windows 8 image we’ve uploaded in Post I. We need to use the “Export” option from WDS console.
6.3. Access Windows System Image Manager (WISM), “File” and “Select Windows Image” and select the WIM file we’ve copied or exported.
If WISM is not able to perform read/write operations to the file we selected we will receive an error message saying “Windows SIM was unable to generate catalog. Details: The specified image file did not contain a resource section”
6.4. Now we will have all the components available in the image. We are going to select several of these components and add those to the configuration passes.
Optionally we can use a “Distribution Share” in WISM; in here we can save drivers and other files to use them in the configuration passes.
7. Creating and Using WDSClientUnattend.xml
Now that we have WISM ready to start creating answer files, we are going to start with the first one used by WDS: WDSClientUnattend.xml. In this file, we will configure all necessary components related to our first configuration pass: windowsPE.
The components we will need to add are the following:
7.1. To start adding them, in “Components” right-click on the selected one and use “Add Setting to Pass 1 windowsPE”.
7.2. After adding all of those mentioned, the WISM console should be looking like this.
Now we need to start editing this components and adding some values.
7.3. For example: Selecting “amd64_Microsoft-Windows-International-Core-WinPE_6.2.8250.0_neutral”, we need to configure the options for “InputLocale”, “SystemLocale”, “UILanguage”, “UILanguageFallback” and “UserLocale”. In my case I’m selecting all of them as “en-US”.
To understand the option we are selecting, we can right-click the setting in WISM and select “Help”. In there, we will find a complete description to understand the setting and in some cases a few examples to use in the answer file.
7.4. The rest of values that need to be added can be reviewed in the following table:
- When we use the “CreatePartitions” and “ModifyPartitions” components, we need to first right-click on this option, select “Insert New CreatePartition” and then we will receive the options to edit.
- Value used in “Filename” name must be the WIM file located in WDS. For example “install.wim”.
- Also, in “ImageGroup” and “ImageName” we must use the values used in WDS console.
7.5. After completing the settings values, we need to validate the answer file. Select “Tools” and “Validate Answer File”.
7.6. Verify that in the lower section, “Messages”, there’s no warning / error appearing.
7.7. Save the file and place it in “%drive%\RemoteInstall\WdsClientUnattend”. This particular file must be located in this folder, and should not be moved.
7.8. To configure the unattended file, access the WDS console and right-click the name of the server selecting “Properties”.
7.9. Select the “Client” pane. Since in this example we’ve used the x64 architecture, browse for the XML file in the selected section.
IMPORTANT: Using WDS we can only assign one WdsClientUnattend file at a time (considering the same architecture for all clients). And as we can see, these file contains the image file we are going to install, so every time we need to change the image, to use a full unattended installation we are going to need to manually change the unattended file.
8. Creating and Using AutoAttend.xml
Here’s an example of AutoAttend.xml for Windows 8.
Our second unattended file is dedicated to the Windows customization, as well as providing some important settings to the computer, for example: Product key, computer name, joining it to domain or workgroup, and so on.
Using this answer file we are going to focus in two configuration passes: 4 specialize and 7 oobeSystem. Let’s take a look to the components we are going to use:
Cycle 4: specialize
Cycle 7: oobeSystem
8.1. Select “File”, “New Answer File” WISM to start creating the new unattended file.
8.2. Add the mentioned components to their particular cycles.
8.3. After it’s done, the WISM pane should look something like this.
8.4. Complete the settings using the values shown in the following table.
Here’s an example of AutoAttend.xml for Windows 8.
- In “ProductKey” setting, the value must be entered using the “-“ as separator between 5 digits. For example: 6RH4V-HNTWC-JQKG8-RFR3R-36498
- When we add “LocalAccount” component, as we did for disk partitions, we need to right-click the component and select “Insert New LocalAccount”. In my example, I’m adding the “Admin” user in the Administrators group.
8.5. Validate the answer file. Take note that using these components, there will be some warnings generated that we can actually ignore.
For example, some components that is deprecated and no longer used in Windows images like “StartPanelLinks”.
8.6. Save the answer file and place it in any location available for WDS Server. This particular file does not have to be saved with any special name nor location.
8.7. To associate this file with the reference Windows 8 image, access the WDS console and select “Properties” in the install image we would like to use the unattended file.
8.8. In the lower section, select the option “Allow image to install in unattended mode” and select the file we’ve just created.
9. Deploying Windows 8 Using Unattended Files
Once we have completed the unattended files and associate them in Windows Deployment Services (WDS) console, the rest is really simple: Just turn on a client machine and start a PXE boot.
9.1. Start the PXE boot in any client machine.
9.2. Make sure you select the Windows PE for booting an installation and not the capture process.
9.3. Review that the steps are completing without any user intervention.
When the normal installation is finished, in “Finalizing your settings” stage all the customizations in the image will be performed.
9.4. After the process is done, we should see in our case the OS ready for account login using domain credentials.
As we can see, the processes involved for a fully unattended deployment of Windows 8 are really simple:
- Installing and configuring Windows Deployment Services (WDS) only requires a couple of wizards.
- Adding clean boot and install images for Windows 8 to WDS does not require any complexity, just by using Windows media we can complete it.
- Capturing a reference Windows 8 basically requires running sysprep and boot the machine using a capture boot image.
- To create our own unattended files using WISM, we have all the support we need in the same tool.
Taking these aspects into account, I think all IT departments should consider using an automated and unattended deployment for Windows operating systems. Using this free tools offered by Microsoft can improve IT processes efficiency in large amounts.
Tags: Deployment, Unattended Deployment, Unattended Files, WAIK, WDS, Windows 8, Windows Deployment Services (WDS)
For a while now I’ve been preparing articles in this blog regarding deploying operating systems, and especially unattended deployments. I’ve started with Windows Vista deployments and the initial version of Windows Deployment Services (Post I, Post II and Post III); the moving forward with Windows 7 using also WDS (Post I and Post II), and also MDT 2010 adding Microsoft Office 2010 to the mix (Post I, Post II and Post III).
And of course, with the release of Windows 8 I had the necessity to prepare a new set, even though this new OS is just at “Consumer Preview” beta.
This set of posts is intended to provide step-by-step procedures to accomplish a full automated deployment of Windows 8 using WDS.
Overview of the Process
The main goal of this process we are going to review in detail is to provide an unattended deployment of Windows 8 using Windows Deployment Services (WDS).
In order to provide a complete guidance, we are going to capture an installed Windows 8 image, add it in WDS and then use this customized image to deploy it using unattended files.
In this set of posts we are going to examine:
- Reviewing requirements.
- Installing and configuring WDS Role.
- Adding Boot and clean Windows 8 images to WDS.
- Create a capture boot image in WDS.
- Capture the Windows 8 reference machine.
- Prepare Windows System Image Manager (WISM).
- Manage first unattended file: WDSClientUnattend.xml
- Manage second unattended file: AutoAttend.xml
- Deploy Windows 8 using Unattended Files.
1. Reviewing Requirements
For the scenario we are going to review, here are the pre requisites we must fulfill in order to complete the unattended deployment of Windows 8:
- Active Directory and DNS server in place. The computer running WDS must be a member of an Active Directory.
- An active DHCP server on the network
- An NTFS partition on the server with the WDS role to store your OS images.
- Windows 8 media. To download it, access this link “Windows 8 Consumer Preview”.
- Windows Automated Installation Kit (WAIK). This is an optional component that we can use to create unattended files.
The WAIK version we are going to use is the version released for Windows 7, which is available in the following link: “The Windows® Automated Installation Kit (AIK) for Windows® 7”
2. Installing and Configuring WDS Role
The steps necessary for this are really simple and covered in this previous post of mine: “Deploying Windows 7 Using Windows Deployment Services (WDS): Step-by-Step – Part I”.
3. Adding Boot and Clean Windows 8 Images to WDS
These steps are also simple if you ever manage WDS. Let’s review them:
3.1. Access the WDS Console and right click in “Boot Images” and select “Add boot image”.
3.2. Select the Windows 8 media and locate “%drive%\sources\boot.wim”.
The “boot.wim” file is the Windows Preinstallation Environment (Windows PE), which is a minimalistic OS in charge of preparing the environment prior the installation. For more information about Windows PE, check the following link: “What is Windows PE?”
3.3. Select the name we are going to use to identify the image, in my case “WinPE – Windows 8 (x64)”.
3.4. Click “Next” in the following screen and wait until the process completes.
3.5. Once it’s completed, in the WDS console the new image will appear.
3.6. Now, for adding a clean Windows 8 install image, in the WDS console right-click “Install Images” and select “Add Install Image”.
3.7. Create a new image group; in my case I’m using “Windows8”.
3.8. Select the installation file available in Windows 8 media in the following path: “%drive%\sources\install.wim”.
The “install.wim” file is where all the Windows operating system files are stored and compressed for optimization. In this new version, the Windows 8 files we have available in the media correspond to the specific version of Windows we’ve downloaded. In the previous versions (Windows Vista and Windows 7) the size of “install.wim” was a little bit bigger since it contained files from several OS versions.
Also, in Windows 8, the compression algorithm for this file has change in order to optimize the download process for installation.
3.9. Click “Next” in the image selection window.
3.10. Also click “Next” in the following step to confirm the new image to be added.
3.11. Once we click “Finish”, we will see the new image added to Windows Deployment Services.
An important part of the OS life cycle in our environment is to distinguish the base images we are using. This base image does not only refer to the OS, it also includes the applications and basic configurations we add to the operating system.
Even though we don’t need to capture a reference Windows 8 image to accomplish an unattended deployment, we are going to take this scenario to understand a little bit more about the possibilities in WDS.
4. Create a Capture Boot Image in WDS
In order to be able to capture a Windows 8 image using WDS, we must convert a boot image into a “Capture Boot Image”.
This type of image is basically a Windows PE modified to be in charge of capturing a prepared Windows 8 image, instead of providing the environment for an installation. The steps are really simple:
4.1. Copy the “boot.wim” file located in Windows 8 media to a local folder in WDS. Alternatively we can “Export” the boot image we’ve added in WDS.
4.2. Right-click in the existing boot image in WDS and select “Create Capture Image”.
4.3. Select the image name, description, and the location of the “boot.wim” file copied in the first step.
4.4. We’ll receive a warning regarding the image we are about to modify: “Image File with the same name already exists. Do you want to append to the existing file?”
Clicking “Yes” will keep the original WinPE image and add the capture WinPE; if we click “No”, the entire image will be overwritten with the new capture WinPE.
Take note that we are not going to replace the boot image we’ve added earlier in WDS; in these steps we are going to generate a new one.
4.5. Complete the steps and select “Add image to the Windows Deployment Server now”.
4.6. Confirm the location of the new boot.wim file.
4.7. Insert the boot image name, in my case “Capture (x64)”.
4.8. Complete the wizard and the new boot image should be added to WDS.
5. Capture the Windows 8 Reference Machine
The capturing process of a Windows image is performed by using a tool provided by Microsoft “sysprep”. Sysprep is the component Microsoft provides in order to IT teams be able to scale OS implementations.
With sysprep we are able to “generalize” an OS by removing some particular characteristics in Windows and transforming this new “generalized” image in a prepared OS ready for a massive deployment. If the image is not generalized we will not be able to capture it using the image we’ve selected earlier.
By applying sysprep we’ll be able to remove some specific data from the OS installation, for example:
- Computer name
- Owner and Company name
- Domain or workgroup membership
- TCP/IP Settings
- Regional and keyboard settings
- Specific hardware drivers. This refers to specific computer hardware, like video or audio drivers. But if you only applied drivers used on the Windows installation, the same will apply for the deployment, but any other external driver installed will be unavailable.
- Any saved network connections (wireless networks saved)
- OS product key. This is an important note, since no matter if your product has been activated; the key is reset after this process.
But of course, there are other several components that will be kept to maintain this as a base image. For example:
- Programs and features installed.
- Local Users and Groups created.
- Product Keys used for programs installed. Meaning if you have Microsoft Office installed, the key used will remain as the same on the deployments.
- Windows updates installed
- User Profiles: Since all the profiles configuration are basically data stored on the Users folders, all that information will be uploaded within the image.
- Printers installed.
For more information about sysprep, take a look to the following link: “What Is Sysprep?”
The process of preparing the image requires only running a specific command line; let’s take a look to the steps:
5.1. Access the reference Windows 8 image.
5.2. In a command prompt, locate the following folder: “C:\Windows\system32\sysprep”.
5.3. Run “sysprep /oobe /generalize /shutdown” (alternatively the /reboot parameter can be used). This command line will generalize the OS removing the specific components mentioned above and shutdown after the process is completed.
We must remember that, since this OS is going to be generalized, the next the normal boot process occurs, it will appear as Windows was just installed. And, of course, prior to that we must capture this image and store it as our base Windows 8 image in WDS.
For more information about this generalize process, take a look to the following link: “Prepare to Capture an Image for Deployment (Generalize)”
5.4. Configure the reference machine to boot from network. Usually by using F12 in the start of the boot process we will be able to select the network card as the preferred boot option.
5.5. Boot from network in the reference machine. Since we have two boot images available in WDS, we should see something like this.
Select the capture image.
5.6. Once the capture image is loaded, a new wizard will appear.
5.7. Select the volume to capture “C:\” and select an image name and description.
If no drive is available to select, this means that the image was not generalized properly. The only volumes that can be captured are those generalized with sysprep.
5.8. Select a local path for the image location and optionally we can upload the image we are going to create to WDS; for that we need to use the WDS Server FQDN (we will be prompt for credentials) and selecting the image group.
If the image is not uploaded to WDS, we can still retrieve it later in this machine and import it manually to the server using the WDS console.
The capturing process will start and is going to take a while to prepare the reference WIM file.
With that, we’ve completed the steps to prepare our environment and the reference image is uploaded in WDS.
In the next post, we are going to take a deep dive into the unattended files: Understanding how they work, some best practices and of course generating our own for a complete unattended Windows 8 installation using WDS.
Tags: App-V, application virtualization, Books, SCCM, SCCM 2012, System Center
In this second part of this series of posts, we are going to review some step-by-step processes about the integration of App-V with System Center Configuration Manager 2012 (SCCM), which is included in my book “Microsoft Application Virtualization Advanced Guide”.
The entire chapter can be downloaded for free in this link, where you can find more information about this integration.
Implementing SCCM and App-V Integration
And now, after reviewing all the benefits, requirements and considerations about the integration it is time to get our hands into the SCCM 2012 and App-V integration.
Distributing the App-V Client with SCCM 2012
Once the SCCM 2012 platform is installed and the client agents were deployed successfully, in this section we are going to review how to install the App-V Client in a given SCCM Collection.
In this example, we will use the “setup.exe” file which installs the pre-requisites in the same process. The file “setup.msi” can be used separately, but the pre-requisites must be installed also separately.
Distributing the App-V Client using SCCM is not necessary for the integration to take place; this is an optional step and should not be considered if the App-V Client is already installed in all clients.
Let’s review the process for adding and installing the App-V Client package:
1. Within “Software Library” pane, we have several options available. Since this “application” contains several files necessary to complete a successful installation; under “Application Management” right click “Packages” and select “Create Package”.
2. Specify the package name and enable the “This package contains source files” option.
3. In “Source Directory”, select the UNC path for the installation files.
One great improvement in SCCM usability is how we use the “Programs” assets, which are basically the command lines to be used for deploying packages or scripts.
Using SCCM 2012, soon as we try to add a package we will be asked to insert a new program (previously, this program had to be created separately).
4. In “Program Type”, select “Program for computers”.
5. Select the program command line and other parameters. Since I’m using the .exe file, the command line used is the following:
setup.exe /s /v"/qb-! SWICACHESIZE=\"6144\"
6. In “Requirements” we can configure several parameters prior to run this program; for example: The client platforms to be installed or the estimated disk space.
7. Complete the wizard.
8. Soon as the package is added, we can select the option “Deploy” in the SCCM 2012 console for that package.
9. In the “Deploy” option, we will receive a new wizard. The first option will let us select the “Collection” to be used for this deployment.
10. In “Deployment Settings” we can configure how to deploy this package: “Available” is used to let the package be available to the client and let the user decide when to install it; or “Required” which will automatically install the client.
11. In “Scheduling” we can configure the schedule options for this package to be installed. In my example I’m using “As soon as possible”.
12. In “User Experience” we can configure options about the possibilities each user receives when the installation or assignment is taking place.
13. In the next window, we will receive the options regarding the type of delivery methods: Streaming delivery or local delivery (download and execute).
a. “Download content from distribution point and run locally” represents the local delivery method.
b. “Stream content from distribution point” represents the streaming delivery.
c. Note also that we can configure a different type of delivery depending if the client is connecting from the same LAN or using a slow connection.
14. In “Summary” review the deployment settings for the package and finalize the deployment configuration.
Using the “Monitoring” pane we can review the current status of the deployment, including the “Completion Statistics” which retrieve a simple and easy report overview of the deployment without requiring running any specific report.
Also in this section we can modify the deployment properties configured recently for the same package.
Using Virtual Applications in SCCM 2012
Creating, handling and deploying virtual applications within SCCM 2012 has been simplified regarding what we needed to configured using SCCM 2007 R2. Virtual applications are supported by default without requiring any execution change in the platform.
Creating Virtual Applications
The concept of “Importing” virtual applications does not apply anymore in SCCM 2012; “creating” is the right word in this case. But the basic steps remain the same, to create a virtual application we need the basic component: The manifest (XML file).
Let’s review the step-by-step:
1. In “Software Library”, “Application Management”, right-click “Applications” and select “Create Application”.
2. Select the path for the application manifest using the UNC. In this example we will be using “Winamp” virtual application.
3. Complete the information about the application: Name, version, and so on.
4. Complete the wizard and the application will be added into SCCM.
Soon as the application is added we can configure its deployment using the same section in the console.
Deploying Virtual Applications
The deployment process of App-V packages is pretty much the same used in SCCM 2007, but some interesting options are added in the process.
Some of these new capabilities are not actually new but the usability of these features has been simplified in order to optimize our deployments. Some of the interesting capabilities are: Handling deployments types; or generating alerts depending on success and/or fail rate.
Let’s take a look at the deployment process in SCCM 2012 for virtual applications:
1. In the “Software Library” section, and using the applications list we can right-click the application we would like to deploy and select the option.
2. Select the “Collection” of devices where we would like to deploy this app, and also use the distribution point associated from which the clients will retrieve this application. In this example, “Distribution Point” is used with the SCCM 2012 Beta 2 installed “TESTDRIVEB2”.
3. In “Deployment Settings” we have the same options reviewed earlier, “Available” and “Required”.
4. In “Scheduling”, as seen before, we can define when this application will be available for deployment in client devices.
5. In “User Experience” we have similar options than the ones we’ve seen in the App-V Client package. In this section, we can configure to “Hide all notifications” for the users; this option is not selected as we will be reviewing the installation process in the client later.
6. Deploying software also includes the possibility to manage the alerts regarding this process. We can configure this deployment to elevate alerts for SCCM and/or System Center Operations Manager (SCOM).
In the SCCM section, we can configure the following options:
- Warning if deployment success rate is below selected percentage.
- Warning if deployment failure rate is below selected percentage.
And for SCOM, we must enable the option for generating alerts in Operations Manager. Enabling this option the SCCM client will communicate with the SCOM agent in the same machine to elevate this warning.
7. Review the “Summary” and complete the wizard.
Once the steps are completed, in “Software Library” section we can also review the “Deployment Types” records existing for the applications.
Double-clicking the deployment type, we will get the parameters configured earlier, plus a few more we should consider. Let’s take a look:
· In the “Content” tab, some of the options available:
- “Persist content in the client cache”: This option is used when we want to store this application in the cache and prevent an automatic deletion (which must be configured manually) for the files used.
- “Enable peer-to-peer content distribution”: This option is used for client machines to distribute the content with other client machines that are near. This parameter is not yet documented by Microsoft, so we cannot confirm about how does it works exactly.
- “Load content into AppV cache before launch”: Again, this option is not documented by Microsoft yet, but what we assume is that the package is loaded completely into App-V cache prior launch, instead that just the Feature Block 1.
- In the options below, as we reviewed earlier we can find the behavior of the delivery types: Streaming delivery or Local delivery (Download and Execute).
· In “Requirements” tab we can configure the dependencies about the deployment. In this case, there’s only selected an “Operating System”, but there are several other options like: Client’s memory, disk space, processor, existing registry path, and so on.
Here’s an example of creating a “Global Condition” (selecting a “Custom” requirement) to be included as a requirement in application deployment: Here, we will be using to be assessed by the client prior the deployment, if the file exists, the deployment continues.
As a reference, we will be using the “Program Files” App-V Client default installation folder, and selecting the App-V Client Management Console (“SftCMC.msc”).
· In “Dependencies” we can configure an existing application as a dependency to deploy the application.
· Each dependency can be configured with a selected “Priority”; this option is used with an “Auto Install” parameter. The application with higher priority will be installed first.
We cannot configure an existing SCCM package as a dependency. The only possibility is a previously added application.
The “Deployment Types” are basically a deployment profile configured for an application. Using this option in SCCM we are can configure different parameters for an application deployment to take place.
Take note that these “Deployment Types” are used to set parameters in the process of deployment behavior, but not parameters into the application settings.
On every application we can have different deployment types configured by just right-clicking the application and selecting “Create Deployment Type”.
Within the wizard, we will get the chance to configure all the necessary parameters for deployment. Completing this option and having different “Deployment Types” we can be certain to fit each deployment process in every scenario.
Here are some examples:
- We might need different “Requirements” for 32-bit and 64-bit clients: The App-V Client installs on a different “Program Files” folder and adds different drivers in each case.
- For roaming users, we would like to use the Local Delivery (Download and Execute) for client machines; guaranteeing users to run when the application is loaded locally and not depending on a streaming server.
Deploying Applications in Clients
Once we have configured the application and the deployment process, we just need to wait that the package is deployed in the SCCM client.
SCCM 2012 includes “Software Center” for every client machine deployed, using “Software Center” we can retrieve the latest status of applications available and installed for the client machine; as well as information about each package.
In this example, the client machine shows the virtual applications which are already installed, as well as virtual applications available to installation. For those applications marked as “Available” we must manually select “Install” to complete its installation.
The installation of the package depends on the package size and the deployment parameters we’ve configured.
Since we had configured earlier for not suppressing notifications, we should receive all the messages about the deployment processes.
Also, we can review in the App-V Client console about the current applications deployed. We can verify that the package URL for each application deployed using SCCM must be directed to the local SCCM cache (default location in C:\Windows\ccmcache).
With those verifications, we can confirm that our SCCM + App-V integration is working properly for deploying applications.
If we need to troubleshoot virtual applications deployments, the SCCM clients also includes a log file dedicated for virtual apps. This log file can be found, as the rest of SCCM logs, in “C:\Windows\CCM\Logs\VirtualApp.log”.
With that, we’ve completed the App-V and SCCM 2012 integration review. Remember that the entire chapter can be downloaded in this link.