Windows User Profiles…The Mysteries Untold – Part 1

Featured

Happy New Year Everone…This is my first blog post of 2017. WooHoo!!  As aways, I love to blog about questions from the field.  This one came from a customer testing their new Virtual Desktop Infrustrure (VDI) on Nutanix and had 1 out of 50 users profiles be corrupt. He asked why did this happen and how can I avoid this in the future. Now, I would say that 1 corrupt profile out of 50 is fine during a test, but let understand why it happens. This topic is especially important to understand because directly relates to VDI and your end user experience in VDI.

Windows User Profiles

What is a Windows User Profile? It not just your desktop 🙂

Let’s do a quick primer…

Windows creates a user profile the first time that a user logs onto a physical computer or VDI session. At subsequent logons, the system loads the user’s profile, and then other system components configure the user’s environment according to the information in the profile.

A user profile consists of the following elements:

  • A registry hive. The registry hive is the file NTuser.dat. The hive is loaded by the system at user logon, and it is mapped to the HKEY_CURRENT_USER registry key. The user’s registry hive maintains the user’s registry-based preferences and configuration.
  • A set of profile folders stored in the file system. User-profile files are stored in the Profiles directory, on a folder per-user basis. The user-profile folder is a container for applications and other system components to populate with sub-folders and per-user data such as documents and configuration files. Windows Explorer uses the user-profile folders extensively for such items as the user’s Desktop, Start menu and Documents folder.

Type of User Profiles

  • Mandatory profiles:
    • Typically one pre-configured profile for many users.
    • Although during a session changes can be made, they are discarded. When the user logs on the next time, the locally cached copy of the mandatory profile is reset (replaced with the network copy).
    • The path to the mandatory profile needs to be assigned to users
    • Useful mainly for kiosk systems.
  • Local profiles:
    • One profile per user per machine.
    • No dependency on the network.
    • Since the profile is available locally, logons are very fast.
    • No configuration is necessary, local profiles are assigned to users automatically.
    • Backing up local profiles is often a challenge because the profiles are distributed across many machines with potentially slow and/or only intermittent network connectivity.
    • Another difficulty is how to transfer local profiles between computers, which becomes necessary when machines are replaced.
    • Useful for users who do not switch computers often or for computers without permanent network connectivity, like laptops. In VDI environments local profiles should not be used since users are directed to an arbitrary (the least loaded) server when they launch a new session.
  • Roaming profiles:
    • One profile per user.
    • The master copy of the profile is stored on a file server. During logon, it is copied to the local machine, which may slow down logons considerably depending on profile size and network speed.
    • During logoff, changed files are copied back to the master copy on the file server. Since a user’s registry hive is stored in a single file, this approach creates the “last writer wins” problem.
    • The path to the roaming profile needs to be assigned to users.
    • Useful for most setups where local profiles cannot be used.
  • Temporary User Profiles.
    • A temporary profile is issued each time that an error condition prevents the user’s profile from loading. Temporary profiles are deleted at the end of each session, and changes made by the user to desktop settings and files are lost when the user logs off.

Windows User Profiles

Windows User Profiles – The Reality

Ok, now let me paint a picture….A user calls the help desk to report a strange issue on an application running on their VDI Desktop. What does the help desk technician do? Analyze the root cause of the problem? Probably not. Most likely, the user’s profile will be deleted and the problem will have gone away. Happy ending? Not at all!

Deleting entire user profiles because of malfunctions caused by small data inconsistencies reveals a great deal of helplessness. While the user can work with the faulting application again, the user has lost thousands of personal settings configured both implicitly and explicitly. The help desk technician, on the other hand, has learned nothing from the case, except a brute force way of closing a call. The next time a user rings with a weird problem the technician will be all the more eager to repeat the procedure.

Deleting is cheap. Who is to blame?  Nobody, really. Given the prehistoric user profile design Windows still uses in its latest incarnations, the help desk technician has no other choice but to delete the profile. Trying to get to the root cause is way too difficult and time-consuming a task to perform routinely several times a day. It is so much cheaper to just delete everything and have the user start from scratch.

Why is it like this? Finding a “Needle in a Haystack” is expensive. User profiles are a mess, a chaotic agglomeration of data. Applications can write what they want, where they want, in what way they want into the profile. Among the piles of data junk each Windows user profile stores, there are, however, quite a few hidden gems: the settings a user actually has configured. That is the stuff users care about.

Take your favorite web browser, for example. It comes with hundreds or thousands of factory presets, most of which you could not care about less. But I bet there are a few tweaks in your configuration you would not like to live without. Unfortunately, those settings dear to your heart are buried among all the other default stuff.

Configuration Craziness with some Applications

And it gets worse. Not only are the valuable settings from individual applications intermingled with worthless data, some applications store their configuration all over the place, effectively creating a mix of settings from multiple programs. This makes it virtually impossible to easily identify and extract a single program’s settings. By the way, Microsoft is especially good at this mixing business. Try to identify all storage locations for (Internet) Explorer settings on your own. LOL 😉

Untangling the Knot – How?

The inadequacies of Windows user profiles have led to the development of quite a few profile management products and technologies.  My next post will dive into Best Practices and some of the solutions that help solve this problem.

Finally, at the beginning of the post I mentioned that this series was inspired by a customer in the field. Well, in the end, the problem was a bad registry setting loaded by the NTUSER.DAT, by a third party application. ;(

Until next time,  Rob.

Microsoft Azure Cloud Series – Azure Resource Manager – Part 3

Hello everybody, time to get in-depth with Azure Resource Manager.  But, before I dive into the Azure Resource Manager, I would like to quickly review some of the basics in Azure.  I will start with a rundown of the Azure Global Footprint.  Then, I will go into how Azure charges are incurred.  And finally, I will dive into the Azure Resource Manager V2 and comparing it to the older Azure Service Manager V1.  Sit tight and let’s go for an Azure Ride 😉

Azure Global Footprint
Azure Resource Manager

Microsoft Azure itself is deployed around the world and involves the concept of regions, which is where you select to place and run your code.  Each region has a Microsoft Azure data center.  These data centers are massive facilities that host tens of thousands or, in some cases, hundreds of thousands of servers.  Currently, Microsoft has:

  • Four regions in North America
  • Two regions in Europe
  • Two regions in Asia
  • One region in Japan

As shown above, Microsoft also has a number of Content Delivery Network (CDN) edge points.  They can be used to cache your content and deliver it even faster to end users.

Once you build an application, you can choose any location in the world where you want to run it and you can move your workloads from region to region.  You can also run your application in multiple regions simultaneously or just direct traffic and end users to whichever version of the app is closest to them

How are Azure Charges Incurred?

This may be different for many of you who are familiar with hosting providers and on-premises systems

Simply, with Microsoft Azure, you pay only for what you use:

  • There are no upfront costs
  • There is no need to buy any upfront server licenses; this is included in the price
  • VMs (IaaS and web/worker role) usage is by the minute
  • VMs (IaaS only) that are stopped in Microsoft Azure, only storage charges apply
  • Likewise, if you use a SQL database, through the SQL Database feature in Microsoft Azure, you do not have to buy a SQL Server license—this is also included in the price
  • For compute services, such as VMs and websites you only pay by the hour

This gives you the flexibility to run your applications very cost effectively
You can scale up and scale down your solutions or even turn them on and off as necessary. This also opens up a wide range of possibilities in terms of the new types of apps you can build.

Managing Azure Deployments

Microsoft Azure currently have two management models:

  • Azure Service Manager (ASM) has been around since 2009 and has been due for an upgrade..
  • Azure Resource Manager (ARM), released last summer, supports modern deployment practices. It is designed to be extensible to all current and future services.

Azure Service Manager V1

  • Traditional way to deploy and manage applications hosted in Azure
  • Azure Portal https://manage.windowsazure.com
  • PowerShell / CLI (default mode)
  • REST API

Azure Resource Manager V2

  • Modern way to deploy and manage applications hosted in Azure
  • Azure Portal https://portal.azure.com
  • PowerShell / CLI (ARM mode)
  • REST API
  • Azure Resource Management Library for .NET

Why and what is Azure Resource Manager?

Today’s challenge with Azure Service Manager V1– it’s difficult to…

  • Set and manage permissions – only co-admin and service admin
  • Monitor and have alerting rules – limited to Management Services and basic KPI in portal
  • Billing – through the billing portal
  • Deployment – complex PowerShell to gather all components for an application
  • Visualize a group of resources in a logical view, including monitoring/billing

ASM V1 Portal – Resource Centric Views

Azure Resource Manager

After working with the current ASM V1 for a number of years now, here’s the breakdown:

  • Resources are provisioned in isolation
  • Finding resources is not so easy
  • Deployment is more complex than on-premise
  • Management of app is challenging
  • Proper use of resources becomes more abstract
  • Isolation makes communications a challenge

Ok, Rob, then why does Microsoft still keep ASM V1 in production?  

Answer:  As of the writing of this blog post, not all features have been ported over to Azure Resource Manager V2.  Once all features and services have been ported over, I expect Microsoft to end of life Azure Service Manager V1.

Azure Resource Manager Overview

Azure Resource Manager

Azure Resource Manager enables you to work with the resources in your solution as a group.  You can deploy, update or delete all of the resources for your solution in a single, coordinated operation.  You use a template for deployment and that template can work for different environments such as testing, staging and production.  Resource Manager provides security, auditing, and tagging features to help you manage your resources after deployment.

Benefits of ARM

  • Desired-state deployment
    • ARM does desired-state deployment of resources. It does not do desired-state configuration inside these resources (e.g., VMs), although it can initiate the process of desired-state configuration.
  • Faster deployments
    • ARM can deploy in true parallel as compared to semi-sequential in ASM
  • Role-based access control (RBAC)
    • RBAC is fully integrated with Azure Active Directory
  • Resource-provider model
    • Resource-provider model is intended to be fully extensible.
  • Common interface for Azure and Azure Stack
    • When Azure Stack is released, same API model for on-premises and Cloud

ARM Definitions and what they mean?

  • Resource – Atomic unit of deployment
  • Resource group – Collection of resources
  • Resource provider – Manages specific kinds of resources
  • Resource type – Specifies the type of resource

Ok, let’s dive into the details of each now.

Resource Group (RG)
Azure Resource Manager

A Resource Group is a Unit of Management providing:

  • Application Lifecycle Containment – Deployment, update, delete and status
    • You can deploy everything included in a resource group together, thereby maintaining versions of an application along with it’s resources
  • Declarative solution for Deployment – “Config as Code”
    • Resource Group’s are .json, declarative/configuration code
  • Grouping – Metering, billing, quote: applied and rolled up to the group
    • Resource groups provide a logical grouping of resources
  • Consistent Management Layer
    • In the V2 portal, everything is controlled in a RG. RGs can be accessed via REST APIs and resource providers
  • Access Control – Scope for RBAC permissions
    • You can only use RBAC in the new portal and the highest level generally used for RBAC is the resource group level.

But, Rob, that sounds great, but should these resources (VM’s, DB’s, Storage, etc) be in the same Resource Group or in a different one?

Hint:  Do they have common life cycle and management?
Azure Resource ManagerAnswer: It’s up to you

Resource Groups Best Practices

  • Tightly coupled containers of multiple resources of similar or different types
    • When resources are in the container, they have a common life cycle. You can deploy these things together, put RBAC on them together with one request and they can know about each other
  • Every resource *must* exist in one and only one resource group
    • Every resource must be in ONE resource group, important for RBAC
  • Resource groups can span regions
    • Don’t have to live in same location, can deploy to multiple regions

A few final thoughts on Resource Groups and their deployment scenarios before we move on.

  • Most significant question is of lifecycle and what to place in a resource group
  • Can apply RBAC, but is this right for a particular resource group?
  • Sometimes resources are shared across multiple applications, in other words a VM could be stored in a storage account in a different resource group
  • Lifecycle is distinct and managed by different people
  • There is no hard and fast rule

Resource Providers

A Resource Provider is used by the Azure Resource Manager to manage distinct types of resources – in your JSON template, you will have code that shows what the resource provider expects to see in order for the resource provider (sitting out in Azure) to build the resource that you want…for example a SQL Server or SQL DB or VM.

Resource providers are an extensibility point allowing new resource providers to be added in a consistent manner as new services are added to Azure – anyone can write their own provider

Resource Provider Types Examples
Azure Resource Manager

Ok, Rob, how do I know what resources providers are available?

Using PowerShell, log in to your Azure account and then run
Get-AzureRmResourceProvider
Azure Resource Manager

Tools typically used with ARM

  • PowerShellBlog Post coming soon
    • PowerShell is used to deploy the ARM templates and can be used to download log files from the Resource Group to analyze issues
  • Troubleshooting in the portal – Blog Post coming soon
  • Visual Studio
    • Although not required, will more than likely be the tool of choice for creating the ARM templates – Blog Post coming soon

Well, that wraps up my blog post on Azure Resource Manager.  We covered a lot and have much more to go.  Stay tuned…..Until next time, Rob.