Welcome to this module on assessing existing physical and virtual environments. In this module, we'll cover the following topics. Proof of concept and how these can help you assess various elements of your existing infrastructure and how they will perform in the cloud. Assess Azure Virtual Desktop deployments where we'll go into detail on those various elements you should assess and why. The different type of user personas and why they are important to understand. And understanding your application groups and how they function in a cloud environment.

A proof of concept is when you deploy services outside your production environment to allow you to understand what application, network and performance requirements will be before it moves into production. There are traditionally three stages in a proof of concept. The first stage is assess. The data you obtain from assessing the different applications and workloads will allow you to understand the number of simultaneous user sessions and the number of virtual machines you would need to facilitate those sessions.

Stage two is to migrate. You use the data obtained from the assess stage to provision new host pools and integrate the additional services, including FSLogix profile containers and RemoteApp application groups. The third stage is release. It is at this stage that you start to run performance testing to better understand network and application latency and start to allow users onto the environment to gain better feedback.

In this next part of the module, we'll take a more in depth look at the assessment element of Azure Virtual Desktop. There are multiple components that are evaluated during the assessment stage, including: User personas, which we'll talk about in further detail shortly. Virtual Machines to understand size requirements as well as user session capacity. Applications to understand which ones need to be part of the Windows image, and which ones can be deployed outside of the Windows image. 

Data, which we'll discuss in more detail shortly. User profiles, which are grouping users into different categories based on their workloads. One of the most important components to assess is data. When we talk about data, we do not just mean files and folders, but more information on various elements. The first of those elements is obtaining data on desktops. What applications do users have installed on their desktop and what are their requirements? We then have data on users. Which department are they in? Where do they access shares from? What applications do they individually use? 

Finally, we have data on workloads where we can have light, medium, heavy or power user workloads. We need to understand these users that are classed under each of these type of categories. We mentioned user personas earlier. Specifying personas will happen by categorizing user based on the following criteria: Personal pools. We need to understand if users require their own personal virtual machine, or if they're able to use pooled compute resources. There could be various reasons for requiring a personal VM, for example, compliance reasons. Density. Do certain users need greater performance density? An example of this would be having less users per CPU. We need to understand density information to ensure we size host pools correctly. Performance. Do certain users need to have higher performing virtual machines? For example, because they use an app that requires higher memory usage? Graphical processing. Better known as GPU, do specific users need to have graphics-intensive virtual machines due to their job role? Business function. Are you able to group a set of users under a single business area to allow easier cost management? Azure region. If you have a global user base, do they need to operate within that specific geographic location? Or for latency reasons is it better provisioning specific resources in closer locations for certain users? User count. We need to understand how many users will fit under each persona. Maximum session count. We'll need to understand how many users will be connecting concurrently and from which region The final part of the assessment, but just as important as the other parts is the application groups. We need to understand which applications need to be part of a golden image that will be deployed to the session hosts. Which users will need to use Office applications? Or will they only need access to specific Office apps? Will applications be compatible with the virtual desktop environment? Which business critical apps will need to be part of the image or which ones can be published outside the image?