User Profile
MahmoudAtallah
MCT
Joined 8 years ago
User Widgets
Recent Discussions
Re: Microsoft Office 365 Issue on AVD
This error message occurs because the Microsoft Office 365 license you have on the Azure Virtual Desktop machine is not designed for shared computer activation. This means that you cannot use the same license for multiple users to access the same machine at the same time. To resolve this issue, you can try the following: 1. To use shared computer activation, you must have an Office 365 (or Microsoft 365) plan that includes Microsoft 365 Apps and that supports shared computer activation. 2. Verify that shared computer activation is enabled for Microsoft 365 Apps: https://learn.microsoft.com/en-us/deployoffice/troubleshoot-shared-computer-activation#verify-that-shared-computer-activation-is-enabled-for-microsoft-365-apps 3. If you have a volume license agreement with Microsoft, you can use the Microsoft Office Deployment Tool to deploy Office to your virtual machines and activate the software using a Key Management Service (KMS) host. I hope this helps!7.9KViews0likes0CommentsBuilding A Highly Available Remote Desktop Gateway Farm integrated with Azure MFA
Build High Available Remote Desktop Gateway integrated with Azure MFA Many people are being forced to work from home for the first time during the coronavirus outbreak. That could have negative impacts on our productivity. Microsoft and many other Tech vendors start to provide different aspects to help people to work from home with more productivity. We as Partner trying to utilize the tools and solutions to provide our customers with the best secure remote work with some added value which giving the users the same feeling as the office environment for higher productivity Hence we started building RD Gateway with Azure MFA for secure work and familiar experience across a variety of devices or web browsers. Table Of Contents Implemented parts Solution Requirements Prerequisites Network requirements Certificate requirements System requirements Authentication Flow Deploy High-Available RD Gateway Server Farm Accounts Environment Install RD Gateway servers farm Install RD Gateway server role on both RD Servers farm Deploy NPS Role for NPS Extension server Accounts Environment NPS Extension for Azure installation Get Azure AD ID Install the NPS extension Configure certificates for use with the NPS extension Configure NPS components on RD Gateway server Configure RD Gateway connection authorization policies to use a central store Configure RADIUS client on RD Gateway NPS NPS service Configure RADIUS timeout value on RD Gateway NPS Configure connection request policies on RD Gateway 1 Create "From MFA" connection request policy Create "To MFA" connection request policy Disable default connection request policy Verify connection request policies list Register server in Active Directory Create RADIUS client Create RADIUS server group Create connection request policies Create "From RD Gateway" connection request policy Create "To RD Gateway" connection request policy Verify connection request policies list Configure Network Policy Verify configuration References Implemented parts The following parts have been implemented: On-Premises Infrastructure Microsoft Windows Server 2016 Standard Edition (3 Servers) A Highly Available Load Balanced RD Gateway Server Farm (RDG). Network Policy Server (Centralized NPS). Enterprise Mobility + Security E3 Microsoft Azure Multi-Factor Authentication Solution Requirements Prerequisites Remote Desktop Gateway (RD Gateway) infrastructure Azure MFA License Windows Server software Network Policy and Access Services (NPS) role Azure Active Directory synched with on-premises Active Directory Azure Active Directory GUID ID Network requirements The following table shows the required ports between RD Gateway, NPS Server, Internal network and WAN, and these ports must be opened for outbound and inbound Source Destination Protocol/Port Internet Gateway WAN NIC TCP: 443, 80 UDP: 3391 (You have to enable UDP on the RD Gateway) Gateway LAN NIC Internal network TCP / UDP: 3389 TCP: 5504 TCP: 5985 Gateway LAN NIC Domain Controllers TCP / UDP: 88 TCP: 135 UDP: 123 UDP 137 TCP: 139 TCP / UDP: 389 TCP: 3268 TCP / UDP: 53 TCP / UDP: 445 TCP: 5985 TCP Dynamic Ports (NTDS RPC service) RD Gateway NPS Server UDP: 1812 UDP: 1813 RD Gateway Perimeter network, should be opened for allowing HTTPS traffic from the client sitting on the Internet to the RD Gateway server in the perimeter network. TCP/ 443, 80 Certificate requirements Public Certificate will be required that should contain the following SAN Names. Item SAN Names Domain Certificate RDS.3TALLAH.COM System requirements The following table shows the required subscription and license that should be provided by the time of the deployment: Product Name QTY Microsoft 365 subscription (E3 plan) or equivalent (MFA License) All users Microsoft Windows Server 2016 Standard Edition 3 The following table summarizes Microsoft products that will be deployed Product Name QTY Microsoft Windows Server 2016 Standard Edition 3 Network Policy and Access Services (NPS) role 2 Remote Desktop Gateway (RD Gateway) infrastructure 2 Authentication Flow F5 or any load balancer receives an Access request from a remote desktop user. F5 or any load balancer route the request to one of the RD Gateway serves. The Remote Desktop Gateway server receives an authentication request to connect to a resource, such as a Remote Desktop session. Acting as a RADIUS client, the Remote Desktop Gateway server converts the request to a RADIUS Access-Request message and sends the message to the RADIUS (NPS) server where the NPS extension is installed. The username and password combination are verified in Active Directory and the user is authenticated. If all the conditions as specified in the NPS Connection Request and the Network Policies are met (for example, time of day or group membership restrictions), the NPS extension triggers a request for secondary authentication with Azure MFA. Azure MFA communicates with Azure AD, retrieves the user's details, and performs the secondary authentication using supported methods. Upon success of the MFA challenge, Azure MFA communicates the result to the NPS extension. The NPS server, where the extension is installed, sends a RADIUS Access-Accept message for the RD CAP policy to the Remote Desktop Gateway server. The user is granted access to the requested network resource through the RD Gateway. Deploy High-Available RD Gateway Server Farm Remote Desktop Gateway Server enables users to connect to remote computers on a corporate network from any external computer. The RD Gateway uses the Remote Desktop Protocol & the HTTPS Protocol to create a secure encrypted connection. RD Gateway server uses port 443 (HTTPS), which provides a secure connection using a Secure Sockets Layer (SSL) tunnel. Accounts All the following accounts have been used. Account or group name Source Description Guest001 Local AD Account for RD Gateway Access Office365 - EndUsers Local AD M365 Users License group Guest001@3tallah.Com Local AD Account to connect with Azure AD Environment Server details. Server Name IP Address Role RDG01P 192.168.1.16 Remote Desktop Gateway server role Network Policy Server (NPS) role RDG02P 192.168.1.17 Remote Desktop Gateway server role Network Policy Server (NPS) role Install RD Gateway servers farm Install RD Gateway server role on both RD Servers farm Deploy NPS Role for NPS Extension server The Network Policy Server (NPS) extension for Azure Multi-Factor-Authentication (Azure MFA) provides a simple way to add cloud-based MFA capabilities to your authentication infrastructure using your existing NPS servers. With the NPS extension, you'll be able to add phone call, SMS, or phone app MFA to your existing authentication flow without having to significantly increase your existing authentication infrastructure. Environment Server details. Server Name IP Address Role NPSEx01 192.168.1.18 Network Policy Server (NPS) role NPS Extension for Azure MFA The next steps will install the NPS role in your new server: NPS Extension for Azure installation As a part of the configuration of the NPS extension, you need to supply admin credentials and the Azure AD ID for your Azure AD tenant. The following steps show you how to get the tenant ID: Get Azure AD ID Install the NPS extension Download the NPS extension from this website. Copy the setup executable file to the NPS server. On the NPS server, double-click the executable. If prompted, click Run. In the NPS Extension for Azure MFA dialog box, review the software license terms, check I agree to the license terms and conditions, and click Install. On the NPS Extension for Azure MFA dialog box, click Close. Configure certificates for use with the NPS extension In this step, you need to configure certificates for the NPS extension to ensure secure communications. The NPS components include a Windows PowerShell script that configures a self-signed certificate for use with NPS. This script performs the following actions: Creates a self-signed certificate Associates public key of certificate to service principal on Azure AD Stores the cert in the local machine store Grants access to the certificate's private key to the network user Restarts Network Policy Server service To use the script, provide the extension with your Azure AD Admin credentials and the Azure AD tenant ID that you copied earlier. Run the script on each NPS server where you installed the NPS extension. Then do the following: Configure NPS components on RD Gateway server Once you have an NPS server running on your RDS environment, you need to configure the RD Gateway connection authorization policies to work with the NPS server. The authentication flow requires that RADIUS messages be exchanged between the RD Gateway and the NPS server. This means that RADIUS client settings must be configured on both RD Gateway and NPS server. Configure RD Gateway connection authorization policies to use a central store Remote Desktop connection authorization policies (RD CAPs) specify the requirements for connecting to a RD Gateway server. By default, RD CAPs are stored locally, and MFA requires that they be stored in a central RD CAP store that is running NPS. Follow the steps below to configure the use of a central store. On the RD Gateway server, open Server Manager. Configure RADIUS client on RD Gateway NPS NPS service The NPS server with the NPS extension for Azure needs to be able to exchange messages with the RD Gateway. To enable this message exchange, you need to configure the NPS components on the NPS server. Hence you must define an NPS client on the RD Gateway server to allow it to communicate to the NPS server with the NPS extension. Configure RADIUS timeout value on RD Gateway NPS To ensure there is time to validate users' credentials, perform two-step verification, receive responses, respond to RADIUS messages, and if necessary, adjust the RADIUS timeout value. In the NPS (Local) console, expand RADIUS Clients and Servers, and select Remote RADIUS Server Groups. In the details page, double-click TS GATEWAY SERVER GROUP. Click OK two times to close the dialog boxes. Configure connection request policies on RD Gateway 1 By default, when you configure the RD Gateway to use a central policy store for connection authorization policies, the RD Gateway is configured to forward CAP requests to the NPS server. The NPS server, along with the Azure MFA extension, processes the RADIUS access request. You need to perform the following tasks: Create from MFA policy to determine what happens when you receive a request from the NPS server. Create to MFA policy to determine when to forward a request to the NPS server Disable the default connection request policy. Verify policies' status and processing order. Create "From MFA" connection request policy Create "To MFA" connection request policy Disable default connection request policy Verify connection request policies list Once you have added the two new policies and disabled the default one, you need to ensure that the policies' status and processing order are correct. Your policy list should look like the picture below: Configure Connection and Resource Authorization policies on RD Gateway 2 Register server in Active Directory For the NPS server to function properly in this scenario, it needs to be registered in Active Directory. Create RADIUS client The RD Gateway needs to be configured as a RADIUS client to the NPS server. Create RADIUS server group You need a RADIUS server group to establish communication with the RD Gateway server. Create connection request policies Just like with the RD Gateway server, you must define policies to handle messaging exchange to/from the RD Gateway server. Create "From RD Gateway" connection request policy Create "To RD Gateway" connection request policy Verify connection request policies list Once you have added the two new policies, you need to ensure that the policies' status and processing order are correct. Your policy list should look like the picture below: Configure Network Policy Because the NPS server with the MFA extension was designated as the central policy store for RD CAPs, you need to implement a new policy on the NPS server to authorize valid connections requests. Verify configuration To verify the configuration, you need to connect to your RD deployment through the RD Gateway server. Be sure to use an account that is allowed by your RD CAP. Open any of the available resources It may ask you to enter your credentials. References PDF Copy: Here The following articles are references used in this design document: Title Reference Azure Active Directory https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-whatis Custom Domain Name https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/add-custom-domain Integrate your Remote Desktop Gateway infrastructure using the Network Policy Server (NPS) extension and Azure AD https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension-rdg Remote Desktop Services - Multi-Factor Authentication https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-plan-mfa Add high availability to the RD Web and Gateway web front https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-rdweb-gateway-ha Remote Desktop Services - High availability https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-plan-high-availability Integrate your existing NPS infrastructure with Azure Multi-Factor Authentication https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension END OF DOCUMENT25KViews1like3CommentsRe: Microsoft remote desktop: something went wrong we couldn't authenticate you - 0x80270301
This error message usually indicates an issue the connection between the client and server. Some steps that can be taken to resolve the issue are: Make sure that Remote Desktop client is up to date make sure your firewall is allowing communication towards azure virtual desktop services If the issue persists, try using another device or network to connect to the remote computer. If nothing works, try reinstalling the Remote Desktop app on both or use web client11KViews0likes0CommentsRe: users kicking each other off sessions - Azure Virtual Desktop
It sounds like the issue is related to the max session limit of 1, and windows version is not multi session, When multiple users are trying to log in to the same pool simultaneously, the earlier sessions are being disconnected, which results in the end users being kicked off. To resolve this issue, you can consider increasing the max session limit, and change the load balancing algorithm to breadth-first, and change the windows version to multi session, By increasing the limit, you will allow multiple users to log in to the pool simultaneously, and each user will have their own session on the same host unless you need each user to utilize detected host.4.2KViews0likes2CommentsAzure Virtual Desktop (AVD) | Scaling plans and Autoscaling
Just notice that I have a new tab under my AVD Portal for Scaling Plan. Before I just explore it, I checked Microsoft DOCs to understand the new feature and see how I can enable it, but I didn't find any relevant info even when I google it I end up with the same result... did I stop here.. Absolutely not, created a temp host pool and followed the wizard to enable and configure the new feature and here is my test result AVD Scaling plans Autoscaling is a demanded feature and has been waiting for so long, we used to automatically scale host sessions using PowerShell scripts and Azure Automation, but it was long and complicated procedures involving a lot of components, Now with AVD Scaling plans you can define ramp-up hours, peak hours, ramp-down hours, and off-peak hours for weekdays and specify autoscaling triggers. but you can only add one schedule per day and a Scaling plan must include an associated schedule for at least one day of the week. Requirements Create a Custom RBAC role Assign the custom role to Windows Virtual Desktop App Create a Custom RBAC role Open a subscription or resource group Click on Access control (IAM) Click on Add Custom role Click on JSON Tab Click on Edit Tab Past the following JSON template { "properties": { "roleName": "Autoscale", "description": "Friendly description.", "assignableScopes": [ "/subscriptions/<SubscriptionID>" ], "permissions": [ { "actions": [ "Microsoft.Insights/eventtypes/values/read", "Microsoft.Compute/virtualMachines/deallocate/action", "Microsoft.Compute/virtualMachines/restart/action", "Microsoft.Compute/virtualMachines/powerOff/action", "Microsoft.Compute/virtualMachines/start/action", "Microsoft.Compute/virtualMachines/read", "Microsoft.DesktopVirtualization/hostpools/read", "Microsoft.DesktopVirtualization/hostpools/write", "Microsoft.DesktopVirtualization/hostpools/sessionhosts/read", "Microsoft.DesktopVirtualization/hostpools/sessionhosts/write", "Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/delete", "Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read", "Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/sendMessage/action", "Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read" ], "notActions": [], "dataActions": [], "notDataActions": [] } ] } } Change <SubscriptionID> with your SubscriptionID Save the template Click Review + Create. Last, Click Create. Assign the custom role to Windows Virtual Desktop App: Open a subscription or resource group Click on Access control (IAM) Select Add role assignments. Select the role you just created (AutoScale) Next, Click on Select members In the search bar, enter and select Windows Virtual Desktop, as shown in the following screenshot. Last, Click Review + Assign. Create a scaling plan As usual, we have to select Subscription, Resource Group, Name, and Location for the new resource. Time Zone is important as the whole Autoscaling activity will be triggered and executed to Start/Stop host sessions based on the time zone you select here. Next, you have to add a new Schedule and specify the Repeats on Start time: you have to Enter a start time for the scaling plan, the specified time will be also the end time for off-peak hours. Load-balancing algorithm: as you are going to use Autoscaling so the Depth-first load balancing option would be more relevant to your needs as its distributing the new user sessions to the available session host with the highest number of connections but has not reached its maximum session limit threshold which leads to minimizing the number of powered host sessions. Minimum percentage of session hosts: Specify the minimum percentage of session hosts to start for ramp-up and peak hours, the percentage is based on the total number of session hosts in your host pool, so if the host pool includes 10 VMs and the percentage is 20% as in the above image, autoscale will ensure a minimum of 2 session host is available to take user connections. Capacity threshold (%): This percentage evaluates whether to turn on/off VMs during the ramp-up and peak hours. So if your total host pool capacity is 100 sessions, and you specify a 60% Capacity threshold, once you exceed it, then autoscale will turn on additional session hosts. As you can see the below step is almost the same as the previous one, so just to clarify the difference: Peak hours and Ramp-up: Usually, every application has its own peak hours where concurrent users tend to increase slowly before the start of peak time. same for AVD users start getting in slowing to the host sessions and at a specific time most of the users will start hitting the services (this is the peak hour) Start time: Enter a start time for the scaling plan to reduce the number of virtual machines prior to the off-peak or non-business hours. This is also the end time for peak hours. Load-balancing algorithm: as you are going to use Autoscaling so the Depth-first load balancing option would be more relevant to your needs as its distributing the new user sessions to the available session host with the highest number of connections but has not reached its maximum session limit threshold which leads to minimizing the number of powered host sessions. Minimum percentage of session hosts: Specify the minimum percentage of session hosts to start for ramp-down and off-peak hours, the percentage is based on the total number of session hosts in your host pool, so if the host pool includes 10 VMs and the percentage is 10% as in the below image, autoscale will ensure a minimum of 1 session host is available to take user connections. Capacity threshold (%): This percentage evaluates whether to turn on/off VMs during the ramp-down and off-peak hours. So if your total host pool capacity is 100 sessions, and you specify a 90% Capacity threshold, once you exceed it, then autoscale will turn on additional session hosts. Delay time before logging out users and shutting down VMs (min): This option will set the session host VMs to drain mode, notify any currently signed-in users to save their work, and wait the configured amount of time before forcing the users to log off. Once all user sessions on the session host VM have been logged off, Autoscale will shut down the VM. Notification message: As shown in the above image you can set your message to be pushed for your end-users to log off. Start time (24-hour system): This is the start time for off-peak or non-business hours. This is also the end time for ramp-down. Then Create.. In the next step, we have to assign the host pool that we will apply this schedule on, scaling plan can be assigned to any number of host pools. Review and Create.. --- Testing And Validation After a few minutes of creating the scaling plan.. Jump to the running AVD virtual machine and check the activity log, you should get an activity stating that the VM was started and this event initiated by WindowsVirtal Desktop App.Solved52KViews3likes56Commentsbulk Pre-registration for Azure MFA for more Seamless Single Sign on and smooth for MFA roll out
We’ve been asked many times to do a bulk pre-registration for Azure Active Directory MFA to provide our customers’ users more Seamless Single Sign on and smooth for MFA rolling out. This script helping you to: Configure MFA Strong Authentication Methods Set a default MFA authentication method for all users or number of users. Update Mobile Number for a List of users. Update Strong Authentication Methods for List of users Get MFA Strong Authentication Details for all users. Get MFA Authentication contact info where the phone number is Null Update Mobile Number Only If user Mobile is not exist NOTE : Before we proceed with MFA and SSPR Enablement and configuration, Users will be able to change their Authentication mobile phone number whenever they need to, Admins won’t have a control on Authentication mobile phone number however they can pre-define them but still users will be able to change it. Keep in mind: If you have provided a value for Mobile phone or Alternate email, users can immediately use those values to reset their passwords, even if they haven't registered for the service. In addition, users see those values when they register for the first time, and they can modify them if they want to. After they register successfully, these values are persisted in the Authentication Phone and Authentication Email fields, respectively. If the Phonefield is populated and Mobile phone is enabled in the SSPR policy, the user sees that number on the password reset registration page and during the password reset workflow. The Alternate phonefield isn't used for password reset. If the Emailfield is populated and Email is enabled in the SSPR policy, the user sees that email on the password reset registration page and during the password reset workflow. If the Alternate emailfield is populated and Email is enabled in the SSPR policy, the user won't see that email on the password reset registration page, but they see it during the password reset workflow. Download here. Script In details. Parameters $UsersCSV = "<Users CSV File Path>" # Example C:\Temp\UsersMFA.csv $OutPutFolder = "C:\Temp" # Example C:\Temp If User Mobile is exist (AD users with specific AD attribute NOT null) Get-AzureADUser | select UserPrincipalName, Mobile | Where-Object { $_.Mobile -ne $null } If User Mobile is exist (AD users with specific AD attribute is null) Get-AzureADUser | select UserPrincipalName, Mobile | Where-Object { $_.Mobile -eq $null } #Get All Users Details Get-AzureADUser | select DisplayName, UserPrincipalName, otherMails, Mobile, TelephoneNumber | Format-Table List users "Authentication contact info" attributes from AzureAD Get-MsolUser -All | select DisplayName -ExpandProperty StrongAuthenticationUserDetails | ft DisplayName, PhoneNumber, Email | Out-File $OutPutFolder"\StrongAuthenticationUserDetails.csv" -Verbose List users "Authentication contact info where Phone number is Null" attributes from AzureAD Get-Msol User -All | select DisplayName -ExpandProperty StrongAuthenticationUserDetails | Where-Object { $_.PhoneNumber -eq $null } | ft DisplayName, PhoneNumber, Email | Out-File $OutPutFolder"\StrongAuthenticationUserPhoneNumberNull.csv" -Verbose StrongAuthenticationUserPhoneNumber File Details List users "Strong Authentication Methods" attributes from AzureAD Get-MsolUser -All | select DisplayName, UserPrincipalName -ExpandProperty StrongAuthenticationMethods | select UserPrincipalName, IsDefault, MethodType All users who have signed up for SSPR. (get-msoluser -All | Where { $_.StrongAuthenticationUserDetails -ne $null }) All users who have not signed up for SSPR (get-msoluser -All | Where { $_.StrongAuthenticationUserDetails -eq $null }) Update Mobile Number for List of users Import-CSV -Path $UsersCSV | ForEach-Object { Set-AzureADUser -ObjectId $_.UserPrincipalName -Mobile $_.Mobile -ErrorAction SilentlyContinue} Microsoft StrongAuthenticationMethod Parameters $OneWaySMS = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationMethod $OneWaySMS.IsDefault = $false $OneWaySMS.MethodType = "OneWaySMS" $TwoWayVoiceMobile = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationMethod $TwoWayVoiceMobile.IsDefault = $true $TwoWayVoiceMobile.MethodType = "TwoWayVoiceMobile" $PhoneAppNotification = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationMethod $PhoneAppNotification.IsDefault = $false $PhoneAppNotification.MethodType = "PhoneAppNotification" $PhoneAppOTP = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationMethod $PhoneAppOTP.IsDefault = $false $PhoneAppOTP.MethodType = "PhoneAppOTP" $methods = @($OneWaySMS, $TwoWayVoiceMobile, $PhoneAppNotification, $PhoneAppOTP) Set Default Strong Authentication Methods for List of users Import-CSV -Path $UsersCSV | Foreach-Object { Set-MsolUser -UserPrincipalName $_.UserPrincipalName -StrongAuthenticationMethods $methods} -ErrorAction SilentlyContinue Pre-register authentication Info for List of users. Import-CSV -Path $UsersCSV | ForEach-Object { Set-AzureADUser -ObjectId $_.UserPrincipalName -OtherMails $_.OtherMails -Mobile $_.Mobile -TelephoneNumber $_.TelephoneNumber -ErrorAction SilentlyContinue}Re: Building A Highly Available Remote Desktop Gateway Farm integrated with Azure MFA
Hi evon3 For RD Gateway usually, I'm hosting them in the same subnet with the default RDG windows firewall rules ( 3390, 3391), refer to the blow post https://redmondmag.com/Articles/2013/12/24/RD-Gateway-in-Windows-Server.aspx?Page=122KViews0likes0CommentsRe: How to install Teams in WVD?
Interesting article Thanks for sharing patrickkoehler, By the way, now Microsoft Teams is now available in preview for Windows Virtual Desktop media optimization https://azure.microsoft.com/en-us/updates/windows-virtual-desktop-media-optimization-for-microsoft-teams-is-now-available-in-public-preview/22KViews1like0CommentsRe: How to install Teams in WVD?
Dear Jgq85, You just have to Download Teams to your downloads folder then run the below commands. reg add "HKLM\SOFTWARE\Microsoft\Teams" /v IsWVDEnvironment /t REG_DWORD /d 1 /f cd Downloads msiexec /i Teams_windows_x64 /l*v teams_install.log ALLUSER=123KViews1like2CommentsRe: Users with Multiple Devices - Groups Best Practice
StuartK73 As the best approach is to create device categories, by using the deviceCategory attribute. For example: device.deviceCategory -eq “Personal Device“. When users of iOS and Android devices enroll their device, they must choose a category from the list of categories you configured. After they choose a category and finish enrollment, their device is added to the Intune device group, or the Active Directory security group that corresponds with the category they chose.2.8KViews0likes1CommentRe: Users with Multiple Devices - Groups Best Practice
Hi StuartK73 , I had the same scenario for one of our customers, in that case, what I would suggest, Just create a Dynamic Groups. Example: Windows 10 laptop (device.deviceOSVersion -startsWith "10.0") and (device.deviceOwnership -eq "Company") (device.deviceOSVersion -startsWith "10.0") and (device.deviceOwnership -eq "Personal") iOS Personal phone (device.deviceOwnership-eq "Personal") iOS DEP / Corp phone (device.enrollmentProfileName -eq "DEP iPhones") Android Enterprise Work Profile (device.deviceOSType -contains "AndroidEnterprise") (device.deviceOSType -eq "AndroidForWork") MacOS (device.deviceModel -eq "iPad Air") And then simply create your Intune Management Profiles and Categories based on those created groups. And don't forget to benefit of using device categories.2.8KViews1like3Comments
Recent Blog Articles
No content to show