Home > Sample chapters > Windows > Windows client

Supporting the Operating System and Application Installation for Windows 8.1

Objective 1.2: Support desktop apps

Although Windows 8.1 comes with a set of default apps on the Start screen, these aren’t widely used in large enterprises by end users who need to perform work. Instead, administrators often opt to install traditional desktop apps. This isn’t to say that apps aren’t used at all; they are. In fact, administrators can (and do) create their own apps and make them available using a process known as sideloading, detailed later in Objective 1.3. However, this objective focuses on supporting only desktop apps.

Quite a few issues can arise while supporting desktop apps. The desktop app might not be compatible, period. Because you need to know this sooner rather than later, you use the Application Compatibility Toolkit (ACT) to determine how widespread the problem is and learn how to fix it before proceeding with an organization-wide installation of Windows 8.1 or the application after the fact. Other issues include the need to run two or more versions of an app side by side, and in these cases and similar scenarios you might opt for technologies such as Hyper-V, RemoteApp, and AppV. You might also opt to run a problematic or noncompliant app virtually or remotely. Other options available for additional desktop app scenarios and functionality include User Experience Virtualization (UE-V) and Windows Intune, which also are discussed in this section.

Supporting desktop app compatibility by using ACT

ACT is included with the Windows ADK and can be used to detect which enterprise applications, devices, and computers will likely be incompatible (or cause problems) with Windows 8.1 after installation. ACT can also help you find solutions to those problems.

ACT is used in stages:

  1. You have to install all of the required software and set up or have previously set up an ACT database.
  2. You need to inventory computers and applications in your enterprise. This lets ACT know what to test.
  3. You need to gather compatibility information based on what’s found by testing for compatibility on the desired platform and comparing that to known issues.
  4. You need to test applications and obtain compatibility results.
  5. You need to analyze the data.
  6. You finally can implement solutions and test again.

Before you dive into the inventory process (the first step to using ACT), look at what ACT includes.

Understanding ACT tools and how to get started

You should be familiar with several ACT tools before working with the program:

  • The Windows Assessment Console is a graphical user interface that enables you to group assessments, create and run jobs, and view and manage the results of those jobs.
  • Assessments are a combination of files that induce specific states on a computer for the purpose of measuring activities during testing. These assessments provide a starting point for necessary remediation.
  • The Assessment Platform comprises the items necessary to develop assessments, extend assessments, and reliably run jobs and display results.

As noted previously, you have to set up or have previously set up an ACT database before you can use ACT. The requirements for doing so include having in place a SQL Server database that stores your enterprise inventory, as well as .NET Framework 4. If you have all of that, you can begin to work through the wizard available from the Microsoft Application Compatibility Manager, which guides you through the setup process. The wizard also helps you create an ACT log share, where the collected log files can be stored, and set up an ACT Log Processing Service user account, which has read and write access. To get started, at the Start screen type application compat, and click Application Compatibility Manager. (You need to run this with elevated privileges.)

Creating an inventory collector package

You create an inventory collector package to collect information about the computers in your enterprise. The data collected includes hardware information such as memory capacity and processor speed, as well as information about the make and model of those PCs. Of course, it also inventories the installed software so that you can later determine whether that software is compatible with the Windows edition you want to install. (If you have hundreds of computers, you can likely inventory them all; however, if you have thousands, you can opt to inventory representative groups of computers. You can do this only if you have groups of computers on similar platforms and with similar installations.)

To create an inventory collector package, follow these steps:

  1. Open the Microsoft Application Compatibility Manager.
  2. Click File, and then click New.
  3. Click Inventory Collection Package.
  4. Input the required information (name, output location, and label) and click Create.
  5. Browse to the location to save the required Windows Installer (.msi) file for the package. You might opt for a network share that can be reached by client computers.
  6. Type a name for the file and click Save.
  7. Click Finish.

Deploying the inventory collector package

Now you must deploy the package you created. If your network isn’t too large and your users are computer-savvy, you might opt to send an email with a link to the deployment folder and let the users install the package themselves. You could also burn the .msi file to a DVD or other removable media and pass that around. Users need administrator privileges either way. Alternatively, you can opt for a Group Policy software installation. This requires more infrastructure, but you would probably already have the required items in place in a large organization. For Group Policy to work, the computers you want to inventory need to be part of the Active Directory forest; you’ll need to create a Group Policy Object (GPO) for publishing; you’ll need to assign the GPO to the appropriate organizational units (OUs); and you’ll need to create and publish the software installation.

More complicated ways require scripting or using additional hardware. You can, for instance, assign a logon script. You can also deploy the package by using System Center Configuration Manager.

Creating a runtime-analysis package

The testing compatibility process involves a few steps, all of which must be completed before creating the runtime-analysis package:

  1. Decide which applications to test. You can use information gathered from the previous steps to make those decisions.
  2. Use the Microsoft Compatibility Exchange to get the latest compatibility ratings.
  3. Organize the applications you want to test.

With that complete, you are ready to create your runtime-analysis package:

  1. In ACM, click Collect.
  2. Click File, and then click New.
  3. Click Runtime Analysis Package.
  4. Provide the required information (name, output location, and label) and click Create.
  5. Browse to the location to save the required Windows Installer (.msi) file for the package.
  6. Type a file name for the .msi file, and then click Save.
  7. Click Finish.

Deploying a runtime-analysis package

You can now deploy the package. You can use Group Policy, Configuration Manager, a logon script, removable media, a network share, and so on to do so. If you opt to let users work with the package, they’ll need to run Microsoft Compatibility Monitor. However you opt to deploy, Compatibility Monitor needs to be run.

To run a deployed runtime-analysis package, follow these steps:

  1. On the target computer, open Microsoft Compatibility Monitor. Note that if you run the .msi file Microsoft Compatibility Monitor installs automatically.
  2. Click Start Monitoring.
  3. Use each application that you want to test for a few minutes.
  4. After you test the required applications, click Stop Monitoring. Data is sent automatically to the ACT database.

Reviewing report data

You view application compatibility reports from the ACM. Several types of reports are available, with names such as Computers, Devices, and Internet Explorer Add-ons. What you’re interested in here is the Applications report. To open this report, follow these steps:

  1. Open ACM.
  2. In the Quick Reports pane, click Analyze.
  3. In the same pane, under the operating system heading, click Applications.

Here are a few things you’ll see in this report:

  • Application names
  • Application vendors
  • Application versions
  • The count of active issues for the application
  • Whether the information for the application is included in the synchronization process with the Microsoft Compatibility Exchange
  • Compatibility ratings unique to your organization
  • Compatibility ratings provided by the vendor
  • The number of computers that have the application installed

Fixing problems

When application compatibility problems are uncovered, you have to decide how you will deal with them. It might be time to move from a little-known office application suite to something more mainstream, such as Microsoft Office. It might be time to simply retire an application. Or, you might decide (and likely will in most cases) to fix the problem and continue to use the application. Fixing the problem can involve modifying the code or applying shims.

A common way to fix a compatibility issue is to alter the code. Microsoft recommends this over changing Registry settings or trying other risky or short-term workarounds. Changing the code requires resources (like money and time) on the front end, but the result might be worth it in the end, at least for a while. If you change the source code for Windows, however, you do create a long-term challenge for yourself and future administrators on many levels, including a risk of causing unexpected problems with other applications you run, with Windows Updates, and so on. A better option to consider is to create shims.

Understanding Shims

If you opt to use the Shim Infrastructure, you can apply the fix (shim) to a specific application and application version only. Shims you create remain independent of the core Windows functions. (If you’re unsure of what the word “shim” means, consider this real-life example: When you fold up a piece of paper and place it under a single table leg that is uneven and causing the table to wobble, you’re creating a shim.)

Technically, but on a high level, Shim Infrastructure involves application programming interface (API) hooking; the shim redirects API calls from Windows to some other code, which is the shim itself. Windows manages and secures shims just as it would the original application code. Thus, you can’t use shims to work around security mechanisms already in place by the operating system, including User Account Control (UAC) prompts. You also can’t use a shim to fix kernel-mode code, specifically to fix issues with device drivers. Shims can fix compatibility issues, though, and are often applied as the desired solutions to compatibility problems.

Knowing When to Use Shims

Deciding to use shims is a process, like anything else. You must first decide whether the problem merits a shim and is worth the time it takes to create it. Here are a few reasons you might opt for a shim:

  • The vendor who created the application is out of business and no updates are available. The source code isn’t available either, so shims are the only option.
  • Your company created the application. If you don’t have the time available to rewrite the code, a shim is the next best alternative.
  • The vendor is still in business but has yet to create an update or fix, or a company-created application can be modified in the future, but no immediate update is available. In these cases, a shim can work temporarily, until an update or fix becomes available in the future.
Creating Shims

Teaching you how to create a shim for an application is beyond the scope of this book; besides, the number of applications that might need shims is seemingly endless. So, rather than try to address this specifically, this section offers an overview and then points you to a few TechNet articles that can offer overviews and provide solution options.

One tool you might opt to use to resolve application compatibility issues is Compatibility Administrator, available from ACT (see Figure 1-11).

FIGURE 1-11

FIGURE 1-11 Compatibility Administrator enables you to create and apply application compatibility fixes.

This tool provides

  • Compatibility fixes, compatibility modes, and AppHelp messages that you use to resolve specific compatibility issues
  • Tools that enable you to create your own customized compatibility fixes, compatibility modes, AppHelp messages, and compatibility databases
  • A tool that you can use to query and search for installed compatibility fixes on your organization’s computers

To use this tool, you first create a new compatibility database (.sdb), select your problematic application, and then select and apply the desired fix. You then test that fix and, when you’re ready, deploy it throughout your organization. To learn how to use this tool, refer to the Compatibility Administrator Users’ Guide at http://technet.microsoft.com/en-us/library/hh825182.aspx.

The following TechNet articles provide more detail:

Supporting desktop application coexistence

You can further test and run applications on new operating systems by using technologies such as Client Hyper-V, RemoteApp, and App-V. Client Hyper-V lets you run applications on virtual machines (VMs) in a dedicated space you can easily manage. RemoteApp lets you access applications remotely through Remote Desktop Services, and the apps themselves are housed and managed on network servers. App-V lets you virtualize applications so that you can use the applications side by side on the same system. All three options let you test applications in various scenarios before deployment. You can then make decisions based on what solution and environment works best in your enterprise.

Understanding and supporting Client Hyper-V

With Windows 8.1 Pro and Windows 8.1 Enterprise, you can create virtual machines that are housed inside a single operating system on a single computer. These virtual machines can run their own operating systems, and you can separate and secure them with virtual switches. A hypervisor keeps these “child” operating systems separate from the parent operating system. This enables network administrators to combine multiple machines into one, which saves money, power consumption, resources, space, and so on. In Windows 8.1, this technology is called Client Hyper-V and is a free element. With regard to supporting applications, you will install applications that you want to test in these environments to check compatibility, perhaps after shims or other fixes are applied.

To use Client Hyper-V, you’ll need the following:

  • Windows 8.1 Pro or Windows 8.1 Enterprise, 64-bit
  • Second Level Address Translation (SLAT) processor
  • 4 GB of RAM
  • BIOS-level hardware virtualization support

If you have a compatible computer, you can create and configure a virtual machine. However, you must first enable Client Hyper-V from Control Panel, under Programs And Features. Click Turn Windows Features On Or Off, locate Hyper-V, and select all related entries (see Figure 1-12). When it’s enabled, click OK and restart the computer. After restarting, you’ll have access to two new tiles when you log on as an administrator: Hyper-V Manager and Hyper-V Virtual Machine Connection.

FIGURE 1-12

FIGURE 1-12 Enable Hyper-V.

How to create, configure, and then install virtual machines by using the Hyper-V Manager is covered in the book, Exam Ref 70-687: Configuring Windows 8.1. This book also covers the types of virtual switches available and how to create them. You can create three types of virtual switches (from the Action pane, click Virtual Switch Manager):

  • External, to let the VM connect to a network interface controller (NIC) on the computer to communicate with the external network, perhaps for the purpose of connecting to the Internet. If you want, it can also be configured to connect to the host computer. The physical NIC can connect to only one network in this scenario.
  • Internal, to let the VM communicate with other VMs and to the host computer.
  • Private, to let the VM communicate with other VMs but not the host computer.

Because creating and installing VMs were objectives for Exam 70-687, you wouldn’t think you would need to know how to do these things for Exam 70-688. But as you learned earlier in this chapter, the exams will likely have quite a bit of overlap. So learning how to perform these tasks is in your best interest, specifically creating a VM, installing a VM, running a VM, and creating a virtual switch. This section, however, focuses only on supporting application compatibility with Client Hyper-V.

You can install applications on a virtual machine the same way you would install one in any other circumstance. You open Hyper-V Manager, right-click the desired VM and select Connect, in the VM window click Action and then Start, and then perform the desired application installation. During the testing process you can use the Hyper-V snapshot feature to take a snapshot of the original state of the VM so that you can return to a known state after application testing. (Snapshots are now called checkpoints.) You manually create a checkpoint to save the state of a virtual machine. This saves all the hard disk’s contents, including application data files, settings, and configurations. When you’re sure you don’t need the checkpoint anymore, you can delete it (because these files can be quite large). Also, checkpoints are portable.

To create a checkpoint, follow these steps:

  1. In Hyper-V Manager, click the new VM you just created and configured.
  2. As needed, click Action and then Start, or click Action and then Connect.
  3. Right-click the VM and select Checkpoint.
  4. In the Checkpoints pane, right-click the new checkpoint and select Rename.
  5. Name the checkpoint appropriately (Day1AfterInstall, for instance).

To test a checkpoint, follow these steps:

  1. Inside the virtual machine, make a change, such as the desktop background.
  2. In Hyper-V Manager in the Virtual Machines pane, right-click the VM and select Revert.
  3. Click Revert again to verify.
  4. Return to the running VM and note that the change has been undone.

Understanding and supporting RemoteApp

Remote Desktop Services (RDS) lets you virtualize a computing session. You can opt to virtualize the entire desktop or, in this chapter, only individual applications. You use RemoteApp tools and technologies to virtualize applications. When you do, applications look and feel as though they’re running on the computer a user is sitting in front of, but in reality the app is being hosted elsewhere. As you might guess, this could be used to resolve compatibility problems with specific apps, as well as provide another means to test the apps before deployment. You can use RemoteApp with local apps, and they can be added to the Start screen.

RemoteApp programs are stored on an RD Session Host server; virtual desktops are hosted on an RD Virtualization Host server. These virtual environments can be accessed remotely from a configured client machine. The Windows server running the RDS role must have the following services configured and available:

  • RD Session Host enables a server to host the desired applications (and perhaps full desktops). Users connect to this server to run the programs. Users also save files and access other network resources available on the server, as applicable.
  • RD Virtualization Host, with Hyper-V, hosts the virtual machines and makes them available to users as virtual desktops. These virtual desktops can be provided in a pool on a first-come, first-served basis, or you can assign a specific desktop to a specific user.
  • RD Web Access enables users to access RemoteApp and Desktop Connection through their computer’s Start screen.
  • RD Licensing is used to manage the RDS client access licenses. A license must exist for a user to connect to the RD Session Host server.
  • RD Gateway enables users to access the internal enterprise network remotely from an Internet-connected device such as a tablet or laptop.
  • RD Connection Broker helps manage session load balancing and reconnection. It also provides access to the RemoteApp programs and virtual desktops.

Beyond the reasons stated already are other reasons to use RDS:

  • You can consolidate all apps to manage them more easily. When an app needs to be updated or otherwise serviced, you can perform the needed work on the RD Session Host server instead of on every client desktop.
  • You can simplify deployment when applications are difficult to manage, perhaps because they are updated often or prone to problems.
  • You can use fewer resources on client computers and simplify management by hosting rarely used applications.
  • You can allow access to company applications remotely, for instance, from home, from tablets or other limited hardware, or while traveling on business.

Windows 8.1 Enterprise offers a Control Panel icon when you opt to view by large or small icons: RemoteApp And Desktop Connections. Users click this icon to access available remote desktops or remote applications. Figure 1-13 shows Control Panel and this icon (in the right column), the RemoteApp And Desktops Connections window, and the area where users type an email address or connection URL. (You can put icons on the desktop or tiles on the Start screen so that users can directly access virtualized apps.)

FIGURE 1-13

FIGURE 1-13 RemoteApp And Desktop Connections lets users connect to RemoteApp.

Understanding and supporting App-V

In some instances, you might need to run several applications side by side on a single computer. Doing so is generally okay, unless those applications conflict with one another. Such a conflict almost always occurs when you need to run multiple versions of the same application. This could certainly happen and is common in testing environments. In other cases, applications simply don’t play well together; this might not have anything to do with versioning and could be caused by something completely different and difficult to diagnose. App-V helps you resolve these kinds of problems. Specifically, App-V lets you virtualize an application so that it remains independent of others but can still live on the same machine without causing conflict.

Application virtualization, as you’ve already learned, can also mean that users can access an application that’s installed elsewhere from almost anywhere an Internet connection and compatible hardware can be used, and both users and administrators gain many benefits in doing so. Virtualization keeps applications off client machines, which means that the users’ computers remain “clean” and administrators can manage the apps centrally (rather than have to manage every client in the enterprise). After App-V is set up and configured for use, a Windows 8.1 Enterprise user can install App-V client software to access and use the desired applications. As with other virtualization technologies, the running apps appear to the user to be installed and running on their own machines.

You must perform plenty of steps before end users can access virtualized applications. Setting up the actual infrastructure is beyond the scope of this book and is best left to experienced network administrators, but you must understand the fundamental task sequence and the hardware, software, and services required.

Using Microsoft Desktop Optimization Pack (MDOP)

App-V is available from Microsoft Desktop Optimization Pack (MDOP). MDOP is available as a subscription for Software Assurance (SA) customers, although you can download an evaluation to experiment with if you are an MSDN or TechNet subscriber. If you want to work through this part of the chapter, you’ll want to download and install MDOP before continuing. Specifically, you need these elements, which are all part of App-V Server:

  • App-V Management Server for managing App-V
  • App-V Publishing Server to host virtual applications
  • App-V Reporting Server to run and view applicable reports
  • App-V Reporting Database Server to work with database deployments and report management

Beyond the required software, the hardware also must meet minimum requirements. The computer on which MDOP is installed must have the following:

  • Microsoft .NET Framework 4.5
  • Windows PowerShell 3.0
  • Update for Windows KB2533623

Each element also must meet specific requirements. For example, the App-V client, Remote Desktop Services client, and the App-V server must all have the applicable Microsoft Visual C++ Redistributable Package installed. To see all requirements, refer to this article on TechNet: http://technet.microsoft.com/en-us/library/jj713458.aspx.

Installing the App-V Sequencer and getting ready for sequencing

You should install MDOP and the App-V Sequencer on a 64-bit Windows 8.1 Enterprise computer. From the MDOP installation folder, navigate to App-V, Installers, 5.0_SP2 (or applicable version), and then run the setup program. As soon as it’s installed, obtain the installer files for the application that you want to sequence. Copy those files to the computer that’s running the sequencer. Create a new VM to use for the sequencing tasks, and make a backup copy of it before you start.

When you’re ready, locate the Microsoft Application Virtualization Sequencer from the All Apps screen on your Windows 8.1 Enterprise computer. Click to open. Figure 1-14 shows the Microsoft Application Virtualization Sequencer as well as an open VM.

FIGURE 1-14

FIGURE 1-14 The Microsoft Application Virtualization Sequencer window helps you create or modify a new virtual application package.

You can now do the following:

  • Create virtual packages that can be deployed to computers that run the App-V 5.0 client.
  • Upgrade and edit configuration information for packages you’ve already created.
  • Convert virtual packages.

Creating a package also creates the following files:

  • An .msi file that you’ll use to install the virtual package on client computers
  • A Report.xml file that contains all issues, warnings, and errors that were discovered during sequencing, in case you need to troubleshoot the package
  • An .appv file, which is the virtual application file
  • A deployment configuration file that regulates how virtual application is deployed
  • A user configuration file that regulates how the virtual application runs

Sequencing an application

You can create virtualized application packages for standard applications, add-ons or plug-ins, and middleware. Creating packages for standard applications is the most common and what is detailed here. The following steps create one of the simplest types of packages. They don’t configure every aspect available, including the option to stream the virtualized application; that experimentation is up to you. From the computer that has the sequencer installed, perform these steps:

  1. At the Start screen, type App-V, and in the results click Microsoft Application Virtualization Sequencer.
  2. Click Create A New Virtual Application Package. You can see this option in Figure 1-14.
  3. Select Create Package (Default), and then click Next.
  4. Resolve all listed issues that can cause the creation of the package to fail (see Figure 1-15).

    FIGURE 1-15

    FIGURE 1-15 Prepare the computer for application sequencing.

  5. Click Refresh and, if all problems are resolved, click Next.
  6. Select the Standard Application (Default) check box, and then click Next.
  7. Click Browse to find the installation file for the application. (If the application doesn’t have an associated installer file, select the Perform A Custom Installation check box, and then click Next. Continue as prompted.)
  8. Type a name for the package.
  9. Click Browse to find the Primary Virtual Application Directory. Navigate to the location where the file would be installed by default, perhaps c:\ProgramFiles\<application name>. Note that you are navigating to this in the VM you already created.
  10. Click Next three times. At the Create A Basic Package Or Customize Further page (see Figure 1-16), select Customize, and then click Next.

    FIGURE 1-16

    FIGURE 1-16 Opt to customize your package.

  11. Click Next to bypass the option to run the program briefly.
  12. Select Allow This Package To Run Only On The Following Operating Systems, and then select Windows 8.1 32-bit and Windows 8.1 64-bit. Notice the other options, such as the option to Allow The Package To Run On Any Operating System.
  13. Click Next.
  14. Click Create.
  15. When the Package Completed page appears, click Close.

With the package created, you are now ready for deployment. You can deploy App-V packages by using an Electronic Software Distribution (ESD) solution. When you opt for an ESD, you eliminate the need for an App-V 5.0 management server, management database, and publishing server. Alternatively, you can use Windows PowerShell to deploy a virtualized application. You can, for example, also opt to install the virtual application on a single computer, deploy it through Group Policy, or use it with Configuration Manager.

Supporting installation and configuration of User Experience Virtualization (UE-V)

Users are more mobile than ever, and the trend will continue. Making the user experience the same no matter where the users log on—whether it’s on a laptop, desktop, or tablet—would be valuable to users and enhance productivity. Network administrators have been doing so for quite some time by incorporating roaming user profiles, making the user’s files and folders available offline, configuring syncing when a user reconnects to the network, and incorporating folder redirection. Quite a bit of this was covered in my previous book, Exam Ref 70-687: Configuring Windows 8.1. This exam doesn’t focus on these technologies from what I’ve seen via the list of objectives; instead, it focuses on User Experience Virtualization (UE-V).

Microsoft UE-V monitors the Windows operating system, monitors apps and application settings that are applied when users are at their computers, and captures those settings. The information is saved to a defined storage location such as a network share folder. (This data isn’t saved to OneDrive, a USB drive, or similar mechanism.) The settings are then applied (or can be applied) to the different computers and devices assigned to the user. What is synchronized (and where) and what apps and applications are included (or not) is determined by the settings location templates (XML files) that the network administrator creates and configures, in combination with what the applications’ developers make available for synchronization.

Here are a few additional things to understand about UE-V:

  • A user can change personal settings from any device included in the UE-V synchronization group. Those changes will be applied to the other computers the next time the user logs on to them.
  • The user can use UE-V with a Windows 7 or Windows 8 computer. Applicable and compatible settings will sync automatically.
  • Changes are saved to a file, and the file is synced on log on. Nothing is actually “virtualized.”
  • Application settings that can be synced can come from applications installed on the device, applications that are sequenced with App-V, and RemoteApp applications.
  • Settings can be used as part of a recovery process when a machine is reimaged or reinstalled.
  • You can incorporate Windows PowerShell and WMI to configure and deploy UE-V agents. Refer to this article to learn more: http://technet.microsoft.com/en-us/library/dn458904.aspx.
  • UE-V includes application settings templates for various editions of Microsoft Office, Internet Explorer, Windows Accessories, desktop settings, ease of use settings, and more.

Several elements must be in place for UE-V to work. A UE-V Agent must be used. This agent watches what changes and saves those changes as applicable. A settings package is also necessary to store the application and operating system settings and application template information. Finally, a UE-V Generator must exist where you can create your own custom templates. This might seem a little vague because it is. A lot of planning and resources are required to put this technology into place. Looking at it from a high level, deployment includes the following:

  1. Deploy the Settings Storage Location.
  2. Deploy the UE-V Agent.
  3. Install the Group Policy templates.
  4. Install the Agent Generator.
  5. Deploy the Settings Template Catalog.
  6. Deploy Settings Location Templates.
  7. Administer UE-V, including but not limited to understanding how to

    • Manage frequency of scheduled tasks.
    • Restore application and Windows settings.
    • Configure applicable Group Policy objects.
    • Manage settings packages.
    • Incorporate App-V applications.
    • Incorporate Configuration Manager as applicable.

Deploying desktop apps by using Windows Intune

Not all companies have the money, time, or resources to set up and maintain an intricate server infrastructure, the ability or know-how to set up personal VMs, or the ability to set up a UE-V substructure to synchronize various user settings. However, those same companies might still want to virtualize applications. Keeping applications off users’ desktops, especially with so many of them mobile and using multiple devices, can lighten the load required of network administrators (as well as support staff). This is where Windows Intune really shines. Any size company can use Windows Intune to virtualize applications.

In this section you’ll learn just enough about Windows Intune to understand what it is and how you can use it. Later in this chapter and book you’ll learn a lot more. Here are the highlights. With Windows Intune, a company can:

  • Use a single web-based administrator console to manage computers and mobile devices via the cloud.
  • Simplify the management of various devices, including Windows laptops, desktops, tablets, and phones—and even Apple iOS and Android devices.
  • Make following company guidelines easier by using the cloud to manage all devices.
  • Download Windows Intune client software when necessary, using a Microsoft account and password, from the administration page. (Client software can be deployed in many ways, including manually, through Group Policy and by using Configuration Manager.)
  • Make software available to users, requiring all users to have the software or making it optional, while at the same time requiring no user interaction for installing it.
  • Make software available through the company portal so that Windows RT users can install applications as needed.
  • Create, upload, publish, and deploy software packages; configure and manage security policies; manage inventory; and create inventory reports when combined with Configuration Manager.

Unlike most of what you’ve seen so far in this objective, you can get a free 30-day trial of Windows Intune even if you don’t have a Software Assurance plan or a subscription to TechNet or MSDN. After you set it up (and possibly install Microsoft Silverlight if you didn’t have it already), go to https://manage.microsoft.com/WindowsIntune, log on, and work through the setup processes. Your logon name should look something like administrator@yourname.onmicrosoft.com. Figure 1-17 shows the Windows Intune Administrator Console, with System Overview selected. Notice the alerts, system status, updates, agent health, and more, just from this one tab.

FIGURE 1-17

FIGURE 1-17 The Windows Intune Administrator Console consolidates the available tools and makes them easy to work with.

From the other tabs available in the Windows Intune Administrator Console, you can manage clients easily. Table 1-4 details the tabs available.

TABLE 1-4 Tabs available in the Windows Intune Administrator Console

Windows Intune tab

Available tools and options

System Overview

Read notices regarding the functionality of Windows Intune; view summaries of Alerts, Endpoint Protection, Agent Health, Policy, Device Health, Software, and Updates; view Computer Summary and Mobile Device Summary

Groups

Create groups; view hardware reports; see a Mobile Device Summary that includes Alerts, Update Status, Policy, Software Status, and Device Health Status; view information on available disk space, top five manufacturers, and top five operating systems used in your enterprise

Updates

View Update Status and Cloud Storage Status; perform update tasks; sort updates by type (Critical, Security, Definition, and so on)

Endpoint Protection

Review Malware Status and Computer Status to see if any issues exist; see Top Malware Instances

Alerts

See a list of Alerts that you can sort in various ways, including View By Date

Software

Review Software Status and Cloud Storage Status; manage cloud storage; perform tasks such as adding software and managing software deployment

Licenses

Review Licenses Overview specific to your organization; add agreements; create a License Group; view Purchase Report; view Installation Report

Policy

Configure policies to manage settings on computers and mobile devices (after it’s configured, you can deploy the policy to groups of devices, or deploy mobile device policies to mobile users)

Reports

View various reports: Update, Detected Software, Computer Inventory, Mobile Device Inventory, License Purchase, and License Installation

Administrator

Access Administration Overview, including the name of the account, status, number of enrolled devices, and Cloud Storage Status; learn more about these items

If you’ve set up a free trial of Windows Intune, click the Software tab. Under Tasks, click Add Software. Download and install the Microsoft Intune Software Publisher, log on, and read the introductory screen. This should give you an idea of how to publish software with Windows Intune. Click Next; you see the screen shown in Figure 1-18, except the path to the location of the software setup files is blank. You learn how to complete this process later in the chapter.

FIGURE 1-18

FIGURE 1-18 Use the Windows Intune Software Publisher to publish software.

Objective summary

  • You can determine application compatibility and deal with problems that arise in many ways, including using ACT and creating shims.
  • Applications can coexist with others that would usually cause compatibility issues or simply aren’t compatible with the current operating system. The technologies to consider include Client Hyper-V, RemoteApp, and App-V. Each offers something unique and is used in specific circumstances to provide solutions.
  • You can give users a consistent desktop and user experience with UE-V.
  • You can use Windows Intune to host applications and manage computer inventory, even if you don’t have a server structure in place.

Objective review

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

  1. You are planning for a Windows 8.1 deployment and have learned that one desktop application your company relies on heavily isn’t compatible. The application vendor is still in business and promised an update soon, but you don’t want to wait for that update. What can you do to make the application compatible until an update is available? Choose all that apply.

    1. Create a shim for the application.
    2. Create and deploy a runtime-analysis package.
    3. Run the program in Program Compatibility mode.
    4. Use RemoteApp for the application.
  2. You have discovered that an application is incompatible with Windows 8.1 and the issue involves User Account Control. Which of the following tools can you use to resolve the issue?

    1. Create a shim with ACT.
    2. Use the Standard User Analyzer Wizard.
    3. Create a shim with App-V.
    4. None of the above; you can’t resolve this kind of issue.
  3. Which of the following lets you store and manage applications on your own network servers while also making them available to users?

    1. Client Hyper-V
    2. App-V
    3. RemoteApp
    4. Windows Intune
  4. You try to enable Client Hyper-V on a workstation and can select Hyper-V and the Hyper-V Management tools, but you can’t select Hyper-V Platform. Why?

    1. You aren’t logged on as an administrator.
    2. The computer’s processor isn’t SLAT.
    3. The computer’s architecture is 32 bit.
    4. The computer is running Windows 8.1, but not the Pro or Enterprise edition.
  5. RemoteApp programs are stored on a(n) ____________ and virtual desktops are hosted on a(n) ____________.

    1. RD Virtualization Host server; RD Session Host server
    2. App-V Publishing Server; App-V Management Server
    3. App-V Management Server; App-V Publishing Server
    4. RD Session Host server; RD Virtualization Host server
  6. You want to monitor Windows operating system, app, and application settings that are applied when users are at their computers. You want to capture those settings and then allow users to access those settings to provide a consistent user experience no matter where they log on. Which of the following are parts of the solution you will put into place to make this happen?

    1. A working Active Directory and network share
    2. A UE-V Agent
    3. A UE-V Generator
    4. A Settings Storage Location
    5. All of the above
    6. Only B and C
  7. When you deploy UE-V, which of the following is the first thing you must do?

    1. Deploy the Settings Storage Location.
    2. Deploy the UE-V Agent.
    3. Install the Group Policy templates.
    4. Install the Agent Generator.
    5. Deploy the Settings Template Catalog.
    6. Deploy Settings Location Templates.
  8. For Windows Intune, what does Endpoint Protection refer to?

    1. Malware
    2. Updates
    3. Policy
    4. Licensing