Ivanti Blog: Posts by

Profile Containers – A Remedy, Not a Cure

Fri, 10 May 2019 21:19:55 Z

Introduction to User Profiles and Their Problems

First, some profile history and knowledge. To begin, let’s look at and understand the Windows Profile.

The Windows user profile holds user-based application and operating system files and settings. The ntuser.dat file is effectively the user’s registry hive loaded up to HKEY_Users at logon, and is represented in HKEY_Current_User within the user session. These profiles include settings such as your wallpaper preference and Windows Explorer layout. Application files specific to the user are stored in %appdata%, with files that need to roam between PCs under %appdata%\roaming, and data to stay local under %appdata%\local. Many applications cache a *lot* of data to the %appdata%\local folder in order to optimize the user experience—Chrome being a prime example.

There are several profile types. The main ones are local, roaming, and mandatory. Local profiles are now the most common, with mandatory being very similar to a local profile but typically customized for a better user experience and stored on a central file server. Both mandatory and roaming profiles come with their challenges—the main ones being that roaming profiles are prone to corruption and slow to logon when files are copied from the server. Mandatory profiles also present security risks and challenges around personal certificates, Skype for Business being a well-known offender.

If you want to read more about the history of profiles, please take a look at this popular blog written for Ivanti by James Rankin (Twitter: @james____rankin).

I first became aware of the problems with roaming profiles very early in my career, where 70% of my time on the helpdesk was spent resetting roaming profiles for users who had lost all settings and personalization in their Windows desktop. Normally there was a difficult problem to troubleshoot, or a device had unexpectedly powered off, leaving the profile corrupt. This was a common problem in the industry, and something needed to be done.

Profiles – Virtualized and Optimized by Ivanti

There were numerous attempts to solve this problem, but an early solutions leader was AppSense (now part of Ivanti as the User Workspace Management (UWM) group). The AppSense Environment Manager product not only solved the problem, it also optimized the user’s profile and user experience. And the solution wasn’t just a point product; it allowed easy management of profiles and developed into the gold standard for profile management. Competitors’ approaches stored profiles on file-server SMB shares, which might be acceptable for smaller deployments with 100% of users on virtual desktops and sessions, but these approaches didn’t fare so well for physical desktops, WAN links, and (looking to the future) cloud architectures requiring web services over HTTPS.

To learn more about how UWM is leading the march to the cloud in workspace management and tight integration with Azure, read this blog.

The New Contender: Profile Containers

I first became aware of the idea of profile containers in the very early days of Office 365, as an AppSense engineer at HPe (now DXC). We looked to Environment Manager as a way of retaining the user’s Office 365 Outlook cache so it did not need to be re-cached each time the user logged onto a new non-persistent desktop or session. If the cache is not immediately available, the user’s experience is poor as they wait for the mailbox to be rebuilt and are initially unable to search.

Why not just capture the Outlook cache file through Environment Manager, like any other personalized file? Well, the problem is size—these cache files quickly grow to multiple gigabytes, which isn’t suitable for transfer at app start or even logon. Using VHDs as an alternative approach (managed through Environment Manager) was discussed at the time, but the idea never really took off.

Around the time I joined Ivanti, the VHD idea was gaining popularity across the industry and we developed scripts for Environment Manager that allowed elements of the profile to be roamed in a VHD. These scripts worked nicely and, over time, evolved into the feature known as EM Cache Roaming, initially released in early 2018.

What does this have to do with profile containers? Well, this concept of using a VHD to solve a specific application cache problem can be extended to capture the entire user profile in one large VHD blob. It mounts quickly, ensures fast logons, and, compared to other approaches, doesn’t have the performance impact on the file server, which makes for exciting demos and appears simple. You could almost say that profile containers are Folder Redirection 2.0, or are at least trying to solve the same challenges.

UWM Virtualized Profiles vs Profile Containers

So how do profile containers differ from Ivanti’s profile management? First, the concept of a profile container actually dates back to Windows Server 2012, where it was known as “User Personal Disk” and was primarily used to solve Outlook roaming problems. It was buried deep in the UI and never got much love, leaving the door open for other vendors, including FSLogix, to advance the concept and extend it to capturing the entire user profile as well as other application caches.

So, do we need both approaches? Why does Environment Manager contain a mix of file and registry capture, and the option of VHD Cache Roaming for things like Office 365 caches? The key word is “Management”—if you place the entire profile into one large container then you lose so much of the ability to manage the user experience. Profile containers are a point solution to allow efficient redirection of a profile to a network share, that’s it. Below are some genuine examples of “asks” I’ve had this week that simply are not possible (or at least very difficult) with profile containers:

A large financial organization wants the experience on its Windows 10 virtual desktops to be the same on Windows 10 laptops. This is impossible with profile containers because delivering a huge VHD file over a WAN or VPN won’t work, especially when the laptop user goes offline. In addition, sharing a single profile container across multiple devices can result in lost profile data.
If you have a user roaming geographically to different VDI farms, then a profile container cannot stretch across the world through a WAN link, unless you replicate the entire file system. The GeoSync feature in User Workspace Manager synchronizes data between datacenters.
Here’s another example I heard today: An Office setting is causing problems for 3,000 users and the organization needs to delete it from each user’s profile. With Environment Manager, this is easy to apply in bulk and just relaunch the app. With profile containers, however, it requires each user to log on again so the changes can be applied.
When profile settings cause a problem, either the administrator or the user (if self-service is enabled) can easily roll back to an earlier version either the specific application or operating system setting, rather than blowing away the entire profile.

The short version is that with Environment Manager, you have granular, centralized control over every aspect of the user profile, combined with the benefits of using VHDs for roaming caches in situations where it makes sense. In other words, the best of both worlds.

Profile Containers and Performance

When IT teams look at deploying profile containers, the most common questions we receive relate to the anticipated IOPS load on the file server that will host the VHDs. This article is a good discussion based on real world experience.

By comparison with Ivanti, personalization only synchronizes data on demand when an application or session starts (although it can be pre-loaded and cached for offline devices). With a little configuration, it is possible to capture a relatively small amount of profile data (typically 15-20 MB per user) and still provide a full roaming experience.

Conclusion

When weighing up how you want to manage your user profiles across the Windows desktop, consider it from an administrative and user-experience perspective. I’ve provided a small snapshot of requirements that would be difficult/impossible to achieve with profile containers. With Environment Manager, you can reap the performance benefits of using VHD to containerize the parts of the profile that make sense without giving up management of the rest.

You can learn more about Environment Manager here.

Ivanti Performance Manager: Release Its Full Potential!

Mon, 02 Jul 2018 16:44:19 Z

Far too often I hear organizations are just using the out-of-the-box configurations supplied with Ivanti Performance Manager for controlling resources in their desktop and server environments. Sure, this brings many benefits, including fast time-to-value and reduced IT admin, but potentially, you may not be exploiting the true power of Performance Manager.

Common resource hungry applications such as Microsoft Office, Internet Explorer, Firefox and Chrome can all be managed more efficiently. This is especially useful in a Terminal Services scenario where controlling resource will allow you to increase the user density on a server.

In the short video below, you will see a simple demonstration of Performance Manager, showing how the unique feature of CPU Thread throttling works, how the base priority is changed, followed by a run through of recommended CPU resource planning.

In a future blog I’ll explain more on how to get the right figures for planning efficient resource levels. For now, rather than just relying on our out-of-box configurations, download an example Performance Manager config to help get you going!

Windows Intune, Autopilot, and Ivanti User Workspace Manager

Tue, 05 Sep 2017 15:55:12 Z

The Cloud is far more than just a datacenter in the sky. Cloud technologies and platforms enable a multitude of new ways to work and, for IT, new ways to deliver IT services to end users. Microsoft’s recent introduction of Windows Autopilot is a new example of how the Microsoft Cloud is evolving to support these new workstyles, and of the changing role of IT in the cloud era.

For many users, the traditional route to work computing is that IT orders computer equipment, configures it and delivers it to them. It’s often a week or more before a new employee has their laptop set up and running in most organizations. And what happens when they need to upgrade or replace that laptop? The employee is back where he started, waiting several days (or more) and possibly visiting IT once or twice while they set up and migrate applications and data to the new laptop.

This is where Windows Autopilot and Intune come in. When IT pre-registers any new Windows 10 device, that device will be automatically enrolled in both of these cloud-based services when first switched on by their new owner and connected to the Internet. Autopilot will present the user with a logon tailored to their organization, and will allow that user to log on using the account pre-assigned to them by IT. Further, if the laptop is pre-built with Windows 10 Professional it will be automatically upgraded and licensed for Enterprise.

After that initial logon, Intune will set basic policy, deliver applications, and give IT a high degree of control over the all-important Office 365 setup and the service branch the device is part of.

So far so good, this all sounds promising—but wait a minute! What does IT lose through this style of management? Well, first, there is an inconvenient feature gap between SCCM and Intune. But the biggest challenge is that with Windows 10 devices using Autopilot and Intune, the user is authenticated with AzureAD, not traditional Active Directory, so Windows 10 devices using Autopilot and Intune are not domain-joined, which knocks out a lot of traditional IT management tools—including Group Policy.

If you want the convenience of Autopilot and InTune plus the ability to apply policy, help is at hand from Ivanti’s User Workspace Management products. In particular, Ivanti Environment Manager can apply Group Policy-like policies to the endpoint, but with a far higher degree of performance, flexibility and granular targeting.

If you’re willing to give up that control to get a low-touch way to configure new laptops, you’re still faced with this question: how do you migrate the user’s persona (settings, local files, shortcuts, printers, credentials, regional settings, favorites, etc.) from their old Windows device to a new one? And how do you ensure that if a user loses or breaks her laptop, you can give her a new one—in minutes—that will look and feel exactly the same as the old one?

That’s something we at Ivanti call Personalization—the roaming of a user’s persona between devices—that is delivered by Environment Manager and Ivanti File Director as part of Ivanti’s User Workspace Management products. And, yes, before you ask, Environment Manager and File Director can be cloud-hosted.

Need to lock down those devices? Unfortunately, Intune policies don’t cover things like app blocking, whitelists and privilege control—but Ivanti Application Control has the answer with capabilities like Trusted Ownership™.

So—how would you put Autopilot, Intune and Ivanti products together to give IT full control of the user experience and workspace, while embracing the new world of Autopilot and Intune? What would the end-to-end workflow look like? Here’s a 3-minute video to show it all working together.

Using AppSense Application Manager to Secure Windows Server (Pt. 3 of 3)

Mon, 09 Jan 2017 17:48:19 Z

*This post originally appeared on the AppSense blog prior to the rebrand in January 2017, when AppSense, LANDESK, Shavlik, Wavelink, and HEAT Software merged under the new name Ivanti.

In Part 2 of this series, we provided the link to our new Server Lockdown Guide, which provided details on using Application Manager and Environment Manager to take control of admins logging onto your infrastructure servers so they can do their job without flouting critical process or security controls.

In this post, we’re pleased to provide the link to our videos that show you how it’s done. Video 1 shows a user logging onto a server as a non-admin and how the session is secured. Video 2 shows the Application Manager role-based access and optional kiosk mode applied by Environment Manager with a tighter lockdown.

Check them out—Video 1 is here and Video 2 is here.

Thanks for following this series—we’d love to see your feedback in the comments.

Using AppSense Application Manager to Secure Windows Server (Pt. 2 of 3)

Fri, 06 Jan 2017 10:52:20 Z

*This post originally appeared on the AppSense blog prior to the rebrand in January 2017, when AppSense, LANDESK, Shavlik, Wavelink, and HEAT Software merged under the new name Ivanti.

Part 1 in this series (Using AppSense to Secure a Server Estate, With Role-Based Access) covered how to use AppSense to do the following:

Take control of who is logging onto your infrastructure servers as an Administrator using Group Policy.
Use Application Manager to secure against unwanted file execution while allowing a user elevated admin privileges to the specified consoles/applications and commands required for their job role.
Use AppSense Environment Manager Secure a server user session and present consoles or applications in kiosk mode.

Here’s the link to download the Server Lockdown Guide and the .aemp and .aamp files needed to configure Application Manager and Environment Manager.

Using AppSense to Secure a Server Estate, With Role-Based Access (Pt. 1 of 3)

Wed, 04 Jan 2017 11:59:06 Z

*This post originally appeared on the AppSense blog prior to the rebrand in January 2017, when AppSense, LANDESK, Shavlik, Wavelink, and HEAT Software merged under the new name Ivanti.

AppSense Application Manager (AM) and AppSense Environment Manager (EM) are widely used for server hardening, security, user profile management and server configuration in a Terminal Services environment.

Surely the idea of using both for a role-based access solution is an extension of this proven background? The good news is, it is!

The construct of AM and EM both lend themselves very well to a server role-based access solution. It makes the process of removing administrative rights and then elevating a user to have the required administrative rights to specific consoles, applications, services and commands very straightforward.

A common example is the Internet Information Services Console (IIS), which requires that the user is an administrator on the server on which they are launching IIS. This means a user has full rights on the server just for the purposes of running the IIS console. Many other consoles also require that the user be an administrator on the server.

IT managers must hate the above scenario, especially if the server is multi-purpose (e.g. SQL and IIS), because they are effectively giving people the ability to restart my server, install/uninstall software, stop services, etc. In a controlled environment, where changes may require ITIL change control, it makes a mockery of the change control process and best security practice. There may also be regulatory code of conduct or governing body that stipulates that control of access on servers needs to be in place. Security compliance of this type is commonplace for public sector and financial organizations.

AppSense Application Manager is the key to compliance for these and other scenarios. In this post, an associated guide, and instructional videos, I’ll show you how you can:

Take control of the users logging on as administrators to your IT server estate.
Log a user on as a non-admin to a server and elevate them as an administrator to the consoles, applications, services, and commands they require for their role.
Benefit from the security enhancements Application Manager has to offer, including trusted ownership file checking.
Achieve a kiosk-style lockdown mode for users within role-based groups using Environment Manager, and apply further user session lockdown to a role using Environment Manager.

Taking control of who is logging onto your infrastructure servers as an Administrator using Group Policy.

When enhancing security related to IT administrative tasks, you can easily incorporate fundamental security principles using Application Manager and its Built-in Elevate function.

The only users that should be logging onto a server interactively as an administrator are IT System administrators (period). System administrators are in a position of trust and should operate within a change management ITIL framework. That is, if changes are made to a server they are performed within a designated planned maintenance window, under the approval of a change board. Nobody else should be an administrator. Bob, who needs to check the SQL backups on the SQL server, does not need to be an admin on the server to do this.

Service accounts requiring administrative privileges also need to be a member of the administrators group, but need to be prevented from logging on interactively. As an example, as the SCCM Administrator for an estate I am very likely to know the password SCCM ‘client push account’. This has to be a member of the local administrators group. I need to prevent the service account from being used to log on interactively using the policy to ‘not grant this account the right to log on locally’.

Finally, to allow the non-admins the ability to log on interactively to the server, we configure the remote desktop users group for the server using group policy.

For an in-depth explanation of how you can do this on your server estate, check this blog tomorrow for a link to download the Server Lockdown Guide. We’ll also provide video demos in the next couple of days—Video One will demonstrate using the Built-in Elevate function. Again, check this blog for a link to view the videos.

Secure using Application Manager and elevating access to the Consoles, Applications and Commands required.

With the Application Manager agent on the server we can reap the benefits of having a secure configuration. The users will be governed by an Application Manager restriction rule that will stop unauthorized execution of files. Users will not be considered Trusted owners and will be prevented from executing unauthorized files. We can then use the Application Manager configuration to elevate and provide the user with administrative privileges to a consoles/applications, and only the consoles/applications for their job role.

As the users are now logging on as standard users we also get all the natural benefits from the security of being a standard user. Being a non-admin user prevents the running of administrative command prompts, running consoles that require admin privileges, and removing/installing software. Essentially the user cannot make changes that require User Account Control (UAC) privileges. You are now leveraging Microsoft security controls rather than trying to defeat them.

In Video Two, which will be available later this week, I go in-depth explaining and showing how this can be set up for various job roles, including storage, web and network admins.

Using Environment Manager to further secure the device into Kiosk mode

Environment Manager is the final piece of the puzzle for really tightening security. I can use conditions and actions to allow a user to log on to a server as a non-admin and only get presented with the IIS console, so that user does not get the desktop experience and if he closes IIS it gets relaunched. Additionally, that user can’t gain access to Windows Explorer but can perform tasks like importing certificates from the file system. If you watch Video Two, which will be available later this week, I explain the entire Environment Manager configuration and the lockdown.