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.
Tags: App-V, application virtualization, Books, SCCM, SCCM 2012, System Center, System Center Configuration Manager
My second App-V book was finally published, “Microsoft Application Virtualization Advanced Guide” and as for my previous book, there’s one sample chapter available for download.
The chapter selected in this case is “Integrating App-V with System Center Configuration Manager 2012”, from where we review all that needs to be known about SCCM integration with virtual applications.
In these two posts I’m going to take a tour around that content as a quick overview and also some step-by-step guidance to accomplish this integration.
Understanding SCCM and App-V Integration
Integrating System Center Configuration Manager with App-V is a far much simpler with the new versions of these two platforms. Let’s review some of the benefits, considerations, delivery methods and components required.
Benefits of Integrating SCCM and App-V
There are several benefits we can review about using SCCM and App-V as an integrated platform instead of separate technologies. Let’s review some of the most important ones:
- Optimizing our Infrastructure: If we have already implemented SCCM in our environment, not integrating with App-V could translate into larger costs of management, troubleshooting, complexity and hardware; since you will need to implement Streaming Server functionality separately from Distribution Points. This role in Configuration Manager can fulfill the streaming process without acquiring big changes in our implementation.
- Improving client targeting: System Center Configuration Manager brings the possibility to deploy normal and virtual applications with an enhanced level of targeting, depending on collections and capabilities of the systems involved.
- Complementing App-V with SCCM assessments: App-V includes user targeting for their packages; integrating with Configuration Manager we can combine these possibilities with software metering, asset intelligence and wake-on-lan features for the virtual applications deployment.
- Virtual Applications delivery as a complement in Operating System Deployment: One of the most important features in SCCM is Operating System Deployment (OSD), which can be combined and scaled up with other features like Software Updates, software and hardware inventory, targeting for implementing operating system’s drivers, etc. Using App-V we can deliver applications as soon as the operating system is deployed, saving considerable time to deliver a ready-to-go operating system.
- Background delivery of App-V applications: In unstable or slow networks BITS protocol can be leveraged allowing application delivery as network connections permit. The SCCM client performs the download of the App-V application into the SCCM cache where it is then imported into the App-V cache. This offers much more flexible application delivery but comes with a storage penalty on the client. The application will exist in both the SCCM and App-V client cache and cannot be purged from the SCCM client cache. This means in this delivery model that there is at least a doubling of the storage required on the client for this delivery model.
Some Considerations about the Integration
SCCM does not provide the exact functionalities we can find in the native App-V components implemented. The idea of SCCM integration is to complement with the App-V platform. But, because of the Configuration Manager architecture, there are some considerations we should review.
Most of the integration features remain undocumented by Microsoft at the moment; but analyzing the infrastructure using the Beta and Release Candidate version of SCCM 2012 appears to maintain basic architecture definitions than from the previous version – SCCM 2007 R2/R3. Here are some of the considerations we can find so far:
- We must re-advertise an application when there’s an active upgrade: “Active Upgrade” is the process that we run in an App-V package to update the application using a service pack or any other of modification; the App-V Full Infrastructure Model automatically delivers the new version to clients. SCCM does not handle updates in the same package as a delta that must be delivered to clients, so we will need to make a new advertisement every time there’s a virtual application update.
- Reduced reporting: App-V Full Infrastructure provides a very important set of reports we can execute and retrieve about our virtual application; Configuration Manager does not provide the same level of reporting. Using the “Local Delivery” as the preferred method for delivering applications it is not possible to report on how many times an application has been used.
- Targeting applications for Remote Desktop Services requires that users must logoff and logon in their sessions: This is not a limitation only for virtual applications, applies for all Configuration Manager Clients’ user targeted and /or user interaction with the SCCM client. The SCCM client only allows software distribution to the console session of a terminal server system (mstsc.exe /console). Therefore, if an application delivery is targeted to users that are using a remote session on the terminal services system; they will not be able to execute the advertisement.
- Asset Intelligence (in charge of reporting and inventory features) requires Feature Block 1 present in the virtual application streamed to clients: Asset Intelligence cannot inventory virtual applications applications that co-exist with the same version of an application installed locally. As we mentioned, virtual applications live within their own environment; making it possible for the same application working as installed locally and virtually deployed. If that’s the scenario, Asset Intelligence won’t inventory the App-V package.
- In order to use Dynamic Suite Composition (DSC) in virtual applications both interconnected packages must be advertised and registered with the App-V Client. That’s why using the delivery method Local Delivery (Download and Execute), later to be discussed, is the recommended option when we are using DSC.
We can also use “Dependencies” in SCCM to guarantee that both packages can be delivered normally.
In this integration, we must understand which components are interacting in these two platforms:
- App-V Sequencer: The process of capturing it is the same and we don’t need to introduce any changes in that phase.
- SCCM Site Server: In charge of managing and handling the actions performed by the SCCM Distribution Points.
- SCCM Distribution Point: Storing and distributing the App-V applications.
- SCCM Client: Client agent agent that communicates with System Center Configuration Manager and receives the virtual applications.
- App-V Client: SCCM Client and App-V Client work together: The SCCM Client delivers the virtual application to the App-V Client Client, which has the responsibility of executing it.
Understanding Delivery Methods
Using SCCM to deploy virtual applications includes two types of delivery methods we can use to fit any specific scenario. These two delivery methods are the same that appeared in the App-V + SCCM 2007 integration.
The delivery methods remains the same, but SCCM 2012 adds some twists in the configurations that we can achieve, using some options that we are going to review later like “Persist content in the client cache” and “Enable peer-to-peer content distribution”.
Applying the different delivery methods will basically depend on the type of connectivity the client machine has with the SCCM distribution point; converting this integration into a highly scalable one since we can discriminate the type of user with a specific type of streaming delivery.
Let’s go through each type: Streaming delivery and Local delivery (Download and Execute).
When using this delivery method, the App-V Client will be configured to receive applications using HTTP/HTTPS (Standard Distribution Point) or SMB (Branch Distribution Point) streaming.
This is how the delivery works in the streaming mode:
In this process we can evaluate the entire workflow in the Streaming Delivery from the moment the application is sequenced. These set of steps should be familiar to us if we already know and understand how a Streaming Server works with virtual applications, but note the following:
- The App-V Client does not stream an application until one of the shortcuts of this application is double-clicked.
- Once the streaming process started, the same behavior occurs at first: The Feature Block 1 is delivered from the SCCM Distribution Point to the App-V Client cache.
- Once the application is running, the rest of the package is streamed down by the App-V Client.
The streaming delivery method must be considered when the clients and servers live in the same LAN; remember that the streaming process requires high-bandwidth connections. Another good example of using this method is when we have applications which are constantly updated, the updates occurs in the Distribution Point which delivers the new package to clients.
Avoid using this method when we have several offline users.
Local Delivery (Download and Execute)
The Local Delivery (download and execute) method explains itself; the initial task executed by the client is downloading the application, the complete package, and then executes it.
In this downloading process, the application is delivered to the SCCM client cache and then the SFT file is streamed from the SCCM clients’ cache into App-V clients’ cache. Basically the SCCM Client works as a local streaming server for the App-V Client.
This is how the delivery works in this mode:
In this process workflow we can see clearly how the SCCM Client is in charge of downloading the entire content of the package as soon as it’s advertised. But only when the user clicks on any of the shortcuts from the application, the App-V Client streams the application to the cache from the SCCM Client cache; and then it completes the launch process.
The application stays in App-V cache, ready to be launched, as long as the advertisements in Configuration Manager maintains.
The Local Delivery is the best approach when we are using slow networks between servers and clients, and of course for offline users; who can work normally with the application even when they are not connected to the network.
The Local Delivery also needs considerable amount of storage: Three times the size of the applications package: One for the SCCM Client; another for the App-V Client; and the third one is stored for calculating differentials when the application receives an update.
App-V Client and the “OverrideURL” Setting
As we reviewed, in both delivery methods the SCCM client streams down to the App-V client cache the applications published; to accomplish this, the App-V Client includes a new registry value “OverrideURL”.
This value can be changed to use an alternate server in charge of delivering the virtual applications. All this process is transparent for the user, the value is changed by the SCCM client and the streaming process is redirected to the Configuration Manager Distribution Point in charge of the delivery.
This is a simple diagram where we can see the interaction between the SCCM Client and the App-V Client.
Even though this concept appeared in the integration of App-V and SCCM 2007 R2, the basic functionality remains in this new version SCCM. Reviewing the deployment of App-V applications using SCCM we can confirm that the OverrideURL behavior is maintained, there’s an example of the Winamp virtual application (deployment reviewed later in this chapter) and the registry settings in the App-V Client.
The “OriginalURL” setting displays the configuration used in the OSD, and the “OverrideURL” use the SFT location in the SCCM Client cache.
Requirements for the SCCM + App-V Integration
In order to accomplish this smooth integration and without adding significant load into our operations, we must understand each of the requirements involved.
The requirements do not differ much from what we’ve seen earlier in SCCM 2007 R2, which is an important advantage if we already have this platform implemented and we are considering migrating to SCCM 2012.
The two important requirements we are going to analyze are: Platform requirements in SCCM 2012 and storage requirements for sizing the SCCM client cache.
SCCM 2012 Platform Requirements
Even though it could sound pretty obvious at this point, remember always that having a healthy environment in SCCM represents an important note before starting with changes in the environment.
Regarding System Center Configuration Manager 2012 components, the basic platform is needed:
· Primary Site.
· Site Server: A Site Server with the following roles installed:
- Site System.
- Site Server.
- Component Server.
- Distribution Point.
- Fallback Status Point.
- Management Point.
- Reporting Point.
· Distribution Points: At least one available and working with IIS and streaming enabled for BITS application delivery. This server will be in charge, of course, of the packages distribution.
· Clients: SCCM clients installed and working properly. We’ll review later in this chapter how to push clients’ agents in SCCM 2012.
For more information about Site System Servers and Site System Roles review the following link in Microsoft TechNet: “Fundamentals of Configuration Manager” http://technet.microsoft.com/en-us/library/gg682106.aspx.
These considerations depend primarily on the type of the delivery method chosen in the environment. As for the App-V environment, we must size the storage considering clients, App-V cache; and server, Distribution Points in SCCM. Here’s a general guideline about the storage requirements:
- SCCM Clients cache must be configured considering the full size of the App-V packages to be distributed.
- App-V Clients cache is recommended to size it considering the SCCM clients cache defined. The App-V client cache should be configured with free disk space threshold option, adding 1GB more to the SCCM client cache value.
Using an SCCM Clients cache with 4GB, the App-V Client cache should be configured with a free disk space threshold of 9GB.
- SCCM Distribution Points should allocate space considering the size of the package multiplied by 3 . The triple sizing consideration, as said depends on the delivery method, current version of the package, upgrade version, App-V clients cache version, or differential files while constructing an upgraded version of the package.
In the next post we will continue evaluating the App-V and SCCM 2012 integration with the step-by-step processes to complete the integration.
Remember that the entire chapter “Integrating App-V with System Center Configuration Manager 2012” can be downloaded from this link.