anyweb

Introduction This is Part 3 in a new series of guides about getting started with Windows 365. This series of guides will help you to learn all about Windows 365 in a clear and insightful way. This series is co-written by Niall & Paul, both of whom are Enterprise Mobility MVP’s with broad experience in the area of modern management. At the time of writing, Paul is a 6 times Enterprise Mobility MVP based in the UK and Niall is a 12 times Enterprise Mobility MVP based in Sweden. In this series we aim to cover everything we learn about Windows 365 and share it with you to help you to deploy it safely and securely within your own organization. In Part 1 we introduced you to Windows 365, selecting the right edition with the level of management that you need, choosing the plan that suits your users needs at a cost you can afford, or modifying the configuration to make it more suited to your individual needs, purchasing licenses and saving money for your organization via the Windows Hybrid Benefit. In Part 2 you learned how to provision an Azure Ad joined Cloud PC and take a look at the different network options available when provisioning an Azure Ad joined Cloud PC. In this part we'll learn about the steps needed to successfully provision a Hybrid Azure Ad Joined Cloud PC. Please allow yourself plenty of time to complete this part as there is a lot to do. Below you can find all parts in this series: Getting started with Windows 365 - Part 1. Introduction Getting started with Windows 365 - Part 2. Provisioning an Azure Ad Joined Cloud PC Getting started with Windows 365 - Part 3. Provisioning a Hybrid Azure Ad Joined Cloud PC <- you are here Getting started with Windows 365 - Part 4. Connecting to your Cloud PC Getting started with Windows 365 - Part 5. Managing your Cloud PC Getting started with Windows 365 - Part 6. Point in time restore Getting started with Windows 365 - Part 7. Patching your Cloud PCs with Windows Autopatch Getting started with Windows 365 - Part 8. Windows 365 boot Getting started with Windows 365 - Part 9. Windows 365 switch Getting started with Windows 365 - Part 10. Windows 365 offline In this part we'll cover the following: Create an Azure Resource Group Create a Virtual Network Configure DNS Create a Virtual Network Gateway Take note of the Public IP address Create a Local Network Gateway Add connection between the local and virtual network gateway Setup static routes Install Routing and Remote Access Configure Routing and Remote Access Configure demand-dial interface Create static route Configure persistent connection Configure preshared key Verify connection Create Azure network connection Provision a Hybrid Azure Ad joined Cloud PC Create an Azure Resource Group Windows 365 uses Resource Groups in Azure to store certain resources, such as Virtual networking, a Virtual Network Gateway or an Azure network connection (ANC). You could use the previously created Resource Group we created in part 2, or keep things orderly and create a brand new one for this part. Let's go ahead and create a new Resource Group in Azure. Login to https://portal.azure.com and click on Create a resource, select Resource Groups, Select Create and create a new resource group in an Azure region close to you. Give the resource group a suitable name like W365HybridResourceGroup Click Review + create to complete the wizard. Create a Virtual Network Windows 365 hybrid azure ad joined Cloud PC's need working DNS to access both the on-premises environment and Internet resources too. After the creation of this virtual network, we'll specify Custom DNS settings to resolve those DNS requirements. Login to https://portal.azure.com and click on Create a resource, select Virtual Network, When the wizard appears, select the previously created W365HybridResourceGroup, select the nearest region, give the virtual network a suitable name such as W365HybridVirtualNetwork and click on Review + Create Once created, select the virtual network, and expand the DNS servers node. Click on Custom and add one or more DNS address of your on-premises DNS server, you should probably also (as a best practice) add 168.63.129.16 which is Azure status DNS as described here = What is IP address 168.63.129.16? | Microsoft Learn. Once you have added your Custom DNS settings, click Save. Create a Virtual Network Gateway In portal.azure.com click on Create a resource, select Virtual Network Gateway and then click on Create. Next, proceed to fill in the following settings, be careful how you enter them as it's not fun trying to delete them afterwards. Also keep in mind that it takes time to create a Virtual Network Gateway: Subscription: <Your Subscription> Resource Group: W365HybridResourceGroup Name: W365HybridVirtualNetworkGateway Region: <Your region> Gateway type: VPN VPN type: Route-Based SKU: Basic Generation: Generation 1 Virtual Network: W365HybridVirtualNetwork Gateway subnet address range: 10.4.1.0/24 Public IP address: Create new Public IP address name: W365HybridVNGPublicIP Public IP address SKU: Basic Enable active-active mode: Disabled Configure BGP: Disabled Finally, click on Review + Create and then click on Create to complete the process. Note: You can click the following link if you'd like to learn more about Azure VPN Gateway settings - About Azure VPN Gateway | Microsoft Learn Take note of the Public IP Next, take note of the Virtual Network Gateway connections Public IP address, you'll need it for later. Create a Local Network Gateway We also need a Local Network Gateway to bridge the gap between cloud and on-premises, and for that to succeed we need a publicly accessible IP address on your on-premises network. In portal.azure.com click on Create a resource, select Local Network Gateway and then click on Create. Note that if your public IP changes over time, you can look at configuring with a FDQN and use a dynamic DNS provider to handle the change in address. Fill in the following values Subscription: <Your Subscription> Resource Group: W365HybridResourceGroup Region: <Your region> Name: W365HybridLocalNetworkGateway Endpoint: IP address IP address: <publicly available IP address on your on-premises network> Address space: IP range of your on-premises IP Finally, click on Review + Create to complete the process. Add connection between the local and virtual network gateway Now that you have configured two network gateways (virtual+local) it's time to create a connection between them. To do that, select the W365HybridLocalNetworkGateway and click on Connections. Click +Add and fill in the following details. Name: W365AzureVPNconnection Connection type: Site-to-site (IPsec) Virtual network gateway: W365HybridVirtualNetworkGateway Local network gateway: W365HybridLocalNetworkGateway Shared key (PSK): <some unique key> IKE protocol: IKEv2 Note: if the Azure portal doesn't allow you to set either the Virtual network gateway or the Local network gateway for this (and it didn't for us), then use the CloudShell with the following PowerShell script. $gateway1 = Get-AzVirtualNetworkGateway -Name W365HybridVirtualNetworkGateway -ResourceGroupName W365HybridResourceGroup $local = Get-AzLocalNetworkGateway -Name W365HybridLocalNetworkGateway -ResourceGroupName W365HybridResourceGroup New-AzVirtualNetworkGatewayConnection -Name W365AzureVPNconnection -ResourceGroupName W365HybridResourceGroup -Location 'North Europe' -VirtualNetworkGateway1 $gateway1 -LocalNetworkGateway2 $local -ConnectionType IPsec -SharedKey 'windowsnoob' To use the Cloud shell go to https://portal.azure.com/#cloudshell/ Note: Make sure to modify the values contained within this script to match your chosen values, and paste in each of the 3 lines one at a time. Once completed without errors, you can review the created local network gateway in Azure. Setup static routes Normally this would be handled by your network team and configured on the network switches. To get this working in a lab you can manually add static routes on each server that you want to access resources from. Below is an example of that on the server hosting the DNS role. route -p add 10.4.0.0 MASK 255.255.255.0 192.168.5.21 Obviously you will need to modify the IP addresses and network mask to suit your setup, in the above example, 10.4.0.0/255.255.255.0 is the ip range in Azure hosting our Cloud PC's and 192.168.5.21 is the IP address of our on-premises Routing and Remote Access (RRAS) server. Note: For the purposes of this guide we are providing this info to get you up and running in a lab. In production adding these routes to each on-premises resource is not scalable, and should instead be configured at the network SWITCH or FIREWALL level in your organization. Install Routing and Remote Access Next, you will install Routing and Remote Access (RRAS) on a workgroup joined server. This is needed to setup a VPN between your on-premises network and the cloud hosting your Cloud PC's. On a server that you'll use for this role, select Add roles and features, click next, next, next, and in the Select server roles screen select the Remote Access role and click Next Click Next at the Features screen, then in the Remote Access screen, in the Role Services screen select Routing which will in turn prompt you to add features that are required for Routing, make sure to select Add Features. Click Next and you'll see that both DirectAccess and VPN (RAS) are now selected, click Next to continue. Click Next at Web Server Role (IIS) and Next again at the Role Services screen. Proceed to Confirmation and then click Install. After the installation is complete, click Close. Configuring RRAS On the server hosting the Remote Access role, click on Tools and select Routing and Remote Access. Right click your RRAS server, select Configure and Enable Routing and Remote Access. Click Next at the introduction and select Secure connection between two private networks. Select the following values: Demand-dial connections: Yes IP Address Assignment: Automatically and then click Finish to close the wizard. Configure demand-dial Interface After clicking Finish above, it will start RRAS associated services and then launch the Demand-dial wizard. Give the demand-dial Interface name a useful name like W365 Hybrid Azure VPN Select the following options for the next screens: Connection Type: Connect using virtual private networking (VPN) VPN Type: IKEv2 and then enter the Public IP address of the Azure Virtual Network Gateway (W365HybridVirtualNetworkGateway) that you captured earlier on. Click Next and enter the following: Protocols and Security: Route IP packets on this interface Next you will be prompted to enter Static Routes for Remote Networks, don't bother as you cannot select the W365 Hybrid Azure VPN you just created (a bug in the UI). You will fill this in later. Just click Next. There is no need to enter any data for the Dial-Out Credentials screen so click Next and then click Finish to complete the Demand-dial wizard. Create Static Route Next, expand the IPv4 node, and select Static Routes. Right click and choose New Static Route. From the drop down menu, select your W365 Hybrid Azure VPN and enter the IP address details of that connection. Configure persistent connection Next, select the W365 Hybrid Azure VPN connection and bring up its properties, set the connection to Persistent connection as below. Configure preshared key On the security tab, select Use preshare key for authentication and enter the key used when we created the W365AzureVPNconnection Close the W365 Hybrid Azure VPN properties. Verify connection Next, select the Network Interfaces node, select your W365 Hybrid Azure VPN and verify the Connection Status. If it says connected, congratulations, if not, you need to verify your IP address settings used earlier. You can also review this connection state in Azure by checking the status of the connection for your W365HybridAzureNetworkGateway. Create Azure network connection Windows 365 in a Hybrid Azure AD Join scenario uses an Azure network connection to allow your Cloud PC's to access your on-premises network resources. To create your own Azure Network connection, open the Microsoft Endpoint Manager console, select the Windows 365 node, and then select Azure network connection. Keep in mind that each tenant has a limit of 10 Azure network connections, if you need more than that you must contact Microsoft support. Next, click on + Create and select Hybrid Azure AD Join from the two available options. Next give the Azure network connection (ANC) a suitable name, before selecting the Resource Group (that you created previously) and the Virtual Network (which you also created earlier). Next enter your on-premises connection info as appropriate. The UPN account specified needs to have permission to allow a Cloud PC to join the on-premises Active Directory Domain. After creating the W365 North Europe HAAD ANC, it will show a status of Running checks and this can take some time to complete. and after some time, if all went well the status will change to Checks successful Note: If you see Checks failed, click on it to review what failed. More than likely DNS settings (and static route) to your on-premises infrastructure is not correct or not working, below is an example of that. Thanks to Donna and Richard Hicks for their help with troubleshooting. We found that the best way to troubleshoot issues like this is to spin up an Azure Virtual Machine in the same Resource Group and Virtual Network as you are working with. If that VM cannot access your on-premises DNS then the ANC checks will fail. Provision a Hybrid Azure Ad joined Cloud PC Once the ANC above is created successfully you should be ready to provision your Hybrid Azure Ad joined Cloud PC. To do that, in Endpoint Manager click on the Devices, select the Windows 365 node, and then select Provisioning Policies. Next, click on + Create policy and select Hybrid Azure AD Join as the Join type and select the W365 North Europe HAAD ANC from the Network drop down menu. fill in your image details, and continue through the wizard until completion. Now all that's required is to add one or more licensed users into the target Azure AD group and access your Hybrid Azure AD Joined Cloud PC. Below is a screenshot of that. The provisioning of that users Cloud PC should begin and if all goes well, succeed ! Logging on to the Cloud PC should also reveal its ability to use to on-premises resources (such as DNS) and the ability to access network shares on another server in the on-premises Domain. Remember that domain join account ? Well you can also see that the Cloud PC is domain joined Job done ! Recommended reading Windows 365 networking deployment options- https://learn.microsoft.com/en-us/windows-365/enterprise/deployment-options?WT.mc_id=windowsnoob.com Windows 365 network requirements - https://docs.microsoft.com/en-us/windows-365/enterprise/requirements-network About VPN devices for connections - Azure VPN Gateway | Microsoft Docs Tutorial - Connect an on-premises network and a virtual network: S2S VPN: Azure portal - Azure VPN Gateway | Microsoft Docs https://charbelnemnom.com/create-site-to-site-vpn-between-azure-and-windows-rras-server/

great stuff ! which maintenance task did you configure for this (so others will know)

you can review the discovery logs listed in my earlier blog to determine which discovery method is finding those computers. Open them in CMTrace and do some digging. Also, this depends on how you've configured your discovery methods, you can test this by manually deleting some MININT-xxxxxx records in SCCM, then triggering one discovery method by right clicking it and choose Run full discovery now..., then reviewing the logs, and verifying if they populate again in SCCM, below is an example of that...

ok in my lab i had 11 minint-xxxxxx devices, and for a test I configured the following maintenance tasks, these settings are not suitable for production, it's only a TEST lab, you need to configure the settings to work with your production setup... Delete Aged Discovery Data https://docs.microsoft.com/en-us/mem/configmgr/core/servers/manage/reference-for-maintenance-tasks and... after running this test in my lab, it deleted all but one active minint-xxxxxx devices, so I thought that I had solved it, but... I did retry this on the same lab after restoring it from a snapshot of BEFORE I configured the maintenance tasks and this time it only removed 2 devices, so give it a try yourself and let me know how it goes you may have to additionally configure the following maintenance tasks, I'd suggest you test in your lab and then provide feedback Delete Inactive Client Discovery Data (was 90, was disabled) now every 1 days Delete Aged Unknown Computers Properties (was 30, eveyr saturday) now every 1 days Delete Aged Inventory history (was 90 days every day, now 1, every day) Delete Aged Discovery data (was 90, every saturday, now 1, every day)

why not change yours to one day and see what happens

the removal of these discovered devices is governed by the maintenance tasks which i showed above, there are several, you'll have to experiment with the settings

discovery is based on how you configure Discovery as explained here you should also review your Maintenance tasks for deleting aged data, check if and when they are enabled and when they run

this looks like the failure, what anti virus is running on this box ? have you excluded paths according to the recommendations here ? https://docs.microsoft.com/en-us/troubleshoot/mem/configmgr/recommended-antivirus-exclusions also try rebooting the server before running the upgrade again

when you PXE boot an unknown computer into WinPE, the Windows subsystem assigns a random MININT-XXXXX computer name to the device, read here for more details and how to fix it

you forgot to post any actual info about the failure, what has failed exactly ? screenshots and logs helps

i don't have a guide but if you ping me via messenger i'll share some steps that you can follow

1/ to integrate MDT with ConfigMgr do as follows but use the latest version of MDT, this blog post is old https://www.windows-noob.com/forums/topic/5131-using-sccm-2012-rc-in-a-lab-part-16-integrating-mdt-with-configuration-manager-2012/ 2/ i'm not following your question, what exactly do you need help with ?

after you deploy that one device it will no longer be unknown, as it is now a known computer, so if you pxe boot that same computer it won't 'see' the task sequence, you'd have to add this computer to a collection where the task sequence is deployed to,

unfortunately I cannot read Chinese so your screenshot does not help, when I look at your smspxe log, the unknown device is not seeing any deployment according to this, so please double check that you've deployed a task sequence (as available) to All Unknown Computers

how is the task sequence deployed, is it deployed to All Unknown Computers ?

Introduction This is Part 2 in a new series of guides about getting started with Windows 365. This series of guides will help you to learn all about Windows 365 in a clear and insightful way. This series is co-written by Niall & Paul, both of whom are Enterprise Mobility MVP’s with broad experience in the area of modern management. At the time of writing, Paul is a 6 times Enterprise Mobility MVP based in the UK and Niall is a 12 times Enterprise Mobility MVP based in Sweden. In this series we aim to cover everything we learn about Windows 365 and share it with you to help you to deploy it safely and securely within your own organization. In Part 1, we introduced you to what Windows 365 actually is, selecting the right edition with the level of management that you need, choosing the plan that suits your users needs at a cost you can afford, or modifying the configuration to make it more suited to your individual needs, purchasing licenses and saving money for your organization via the Windows Hybrid Benefit. In this part, we'll learn how to provision an Azure Ad joined Cloud PC and take a look at the different network options available when provisioning an Azure Ad joined Cloud PC. Below you can find all parts in this series: Getting started with Windows 365 - Part 1. Introduction Getting started with Windows 365 - Part 2. Provisioning an Azure Ad Joined Cloud PC <- you are here Getting started with Windows 365 - Part 3. Provisioning a Hybrid Azure Ad Joined Cloud PC Getting started with Windows 365 - Part 4. Connecting to your Cloud PC Getting started with Windows 365 - Part 5. Managing your Cloud PC Getting started with Windows 365 - Part 6. Point in time restore Getting started with Windows 365 - Part 7. Patching your Cloud PCs with Windows Autopatch Getting started with Windows 365 - Part 8. Windows 365 boot Getting started with Windows 365 - Part 9. Windows 365 switch Getting started with Windows 365 - Part 10. Windows 365 offline In this part we'll cover the following: Azure AD join capabilities for Windows 365 Cloud PCs Assigning licenses to users Adding licensed users to an Azure AD group Decide which network your Azure AD Joined Cloud PCs will use Create or reuse resource group (optional) Create or reuse a virtual network (optional) Create azure network connection (optional) Create provisioning policy Azure ad join capabilities for Windows 365 Cloud PCs When Windows 365 was originally released (July 2021), it initially supported the Hybrid Azure AD join scenario. Based on customer feedback, Microsoft announced support for Azure AD joined Cloud PCs in Windows 365 Enterprise November 2021 and that went through a private preview before it was initially released in February 14th, 2022, and Globally Available in May 2022. Note: Azure AD Join doesn't require connectivity to a Windows Server Active Directory (AD) domain unlike Hybrid Azure AD Join, which does require that connectivity. Azure ad joined Cloud PCs have the following benefits: You can create Azure AD joined Cloud PCs without bringing any additional Azure infrastructure. You can create Azure AD joined Cloud PCs on your own network, by using an on-premises network connection. You can provide Cloud PCs for cloud-only users in your organization. Gain more flexibility to sign in to your Cloud PC using Windows Hello for Business. Assigning licenses to users You need to assign a Windows 365 license to your user(s) in order for them to use the service, much as you would with any Microsoft 365 product. To do this, open the Microsoft 365 admin center and expand the Billing node, select Licenses, and choose the appropriate Windows 365 product from those you've purchased. Next click on + Assign licenses and select the user(s) you wish to apply the license to in the Assign licenses to users window. Finally click on Assign. You will get a confirmation of the action showing the type of Windows 365 license. Adding licensed users to an Azure AD group Next, you need to add the licensed user(s) to an Azure AD group, you can name the group whatever you want but it would be a good idea to match the name of your Azure AD group to the Provisioning policy that we will create later in this guide by using a naming convention. In this example, we have created an Azure AD group called W365 North Europe AAD W11 and we've added the licensed user(s) to that group. That way we can quickly determine that members of this group will get a Windows 365 Cloud PC configured for Northern Europe, using Azure AD Join and running Windows 11. Decide which network your Azure AD joined Cloud PCs will use You need to decide which network type your Cloud PC's will use for the Azure AD Join scenario. There are 2 choices listed below. A Microsoft-hosted network Your own network (using an Azure network connection) Tip: If you want your Azure AD Joined Windows 365 Cloud PCs to be 100% Cloud Only then select the built-in Microsoft-hosted network. If you select that choice then you can skip the next three optional steps. If however you want to control the region where your network is located (in relation to your users) and which DNS settings your Cloud PC's will use plus many other additional network settings, then you should configure the next three steps. Create or reuse a Resource Group (optional) Windows 365 uses Resource Groups in Azure to store certain resources, such as Virtual networking. When creating a provisioning policy for a Cloud PC you can select to use the Microsoft hosted network (cloud only) or use a previously created Azure network connection (ANC). If you choose the option to use your own network via an Azure network connection, that ANC needs to be in a Resource Group. To prepare for that, we'll create a new Resource Group in Azure. Note: If you want your Azure AD Join based Windows 365 Cloud PC's to be cloud only you can skip this step. Login to https://portal.azure.com and click on Create a resource, select Resource Groups, select Create and create a new resource group in an Azure region close to you. Click Review + create to complete the wizard. Create or reuse a Virtual Network (optional) Windows 365 in an Azure AD Join scenario can use a Microsoft Hosted Network to be completely cloud only, or can use Virtual Networks to allow your Cloud PC's to use specific network settings that you define. Note: If you want your Azure AD Join based Windows 365 Cloud PC's to be cloud only you can skip this step. To use your own network and provision Azure AD joined Cloud PCs, you must meet the following requirements: Azure virtual network: You must have a virtual network (vNET) in your Azure subscription in the same region as where the Windows 365 desktops are created. Network bandwidth: See Azure’s Network guidelines. A subnet within the vNet and available IP address space. In your newly created Resource Group, click on Create and select Virtual Network. Here you can define the ip addresses to use if that's your preference. define the IP Addresses and additional network info for the virtual network, followed by Create. Create Azure network connection (optional) Windows 365 in an Azure AD Join scenario can use a Microsoft Hosted Network to be completely cloud only, or can use an Azure network connection to allow your Cloud PC's to access your on-premises network resources. Note: If you want your Azure AD Join based Windows 365 Cloud PC's to be cloud only you can skip this step. To create your own Azure Network connection, open the Microsoft Endpoint Manager console, select the Windows 365 node, and then select Azure network connection. Keep in mind that each tenant has a limit of 10 Azure network connections, if you need more than that you must contact Microsoft support. Next, click on + Create and select Azure AD Join from the two available options. Next give the Azure network connection (ANC) a suitable name, before selecting the Resource Group (that you created above) and the Virtual Network (that you also created above). Click on Next and then click on Review + Create. The ANC status will initially be running checks and if all goes well it'll change status to Checks Successful after approximately 30 minutes. Create provisioning policy Next you need to create a provisioning policy. In the Windows 365 node, click on the Provisioning policies tab. Click on + Create policy and start filling in the details. In the General screen once you select Azure AD Join as Join type,that you'll have the choice of selecting the Microsoft hosted network or to use an Azure network connection (ANC) that you created previously. If you want your Windows 365 Cloud PC's to be cloud only select the Microsoft hosted network, otherwise select the ANC that is applicable to your region. On the Image screen, you can select the type of image from built-in images provided by Microsoft (Gallery image) to using one you make yourself (Custom image). If you select Gallery image you'll need to click on Select to select from a list of created images. In this example we'll go with the Windows 11 Enterprise + Microsoft 365 apps image On the Configuration screen, select your desired Language + Region (preview) and whether or not you want to use the new Windows Autopatch feature. On the Assignments screen, select one or more groups that you want to target with this Provisioning Policy. We'll use the previously created W365 North Europe AAD W11 Azure AD Group for this purpose. when done click on Review + Create and your provisioning policy is complete. At this point all the hard work is done and you can select the All Cloud PCs tab. This will reveal the status of any Windows 365 licensed users targeted by the provisioning policy. This process can take some time to deploy the actual Cloud PC, so you'll have to refresh this view in order to see when everything is complete. While you are waiting, please up-vote the following Windows 365 feedback so that we can get an email notification once the provisioning process is completed. Note that if the licensed user(s) opens the Windows 365 web page https://windows365.microsoft.com at this point, they'll see something liked the following (after satisfying MFA). This is another reason why an email notification to both the Admin and the User would be great. Note: During this process we did not create any User settings to define Local administrator settings, or Point in time restore options. If you need to configure them, then do so in the User settings tab. You can always add those settings after provisioning a Cloud PC, just ensure that the Cloud PC restarts to get the new policy. After some time, the Cloud PC will be provisioned and you can see that in the MEM console, in addition to details of its provisioning policy, the device name, PC Type, Azure network connection and image. At this point, the licensed user(s) can access their Cloud PC directly at the Windows 365 web page. After clicking on Open in browser, the user will be prompted for credentials, MFA prompt and they are in. Job done ! That's it for this part, please join us in Part 3 where we'll learn how to provision a Hybrid Azure AD Join Cloud PC. Recommended reading Windows 365 networking deployment options- https://learn.microsoft.com/en-us/windows-365/enterprise/deployment-options?WT.mc_id=windowsnoob.com Windows 365 requirements - https://docs.microsoft.com/en-us/windows-365/enterprise/requirements Azure Virtual Network requirements - https://docs.microsoft.com/en-us/windows-365/enterprise/requirements-network Azure Network guidelines - https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/network-guidance Azure network connections (ANC) - https://docs.microsoft.com/en-us/windows-365/enterprise/azure-network-connections

the chances of two computers with the same name joining the domain at exactly the same time are slim surely, have you had problems with this or ?

did you verify that the source version 3 of the package is on your dp(s) ? did you distribute BOTH the x86 and x64 boot images to your dp(s) ? if not, please do that before assuming something is wrong with your site, let's rule out one thing at a time, cheers niall

the mail function is used when a failure occurs to send logs to a shared email inbox, you can search the script and rem it out however you will need it sooner or later, that's why it's there i think it's in the somethingfailed function (not looking at the scripts right now)

if you are not using SCCM, then you need to rem out the RemoveSCCMClient call, I think it's in the takeaction function, just place a # in front of it and that'll help, otherwise it will fail, start with that, then try again

I'll have to investigate that, have you tried first of all verifying the version of Azure AD connect you are using and update to the latest, see does that resolve things if not, look into adding a pass-through auth agent, if that works great, if not, uninstall it

I noticed a change with Azure AD Connect sync recently in one of my labs, password sync also failed, after looking in AAD in the Azure AD Connect node, I saw that it also wants agents installed, i've highlighted it here, you can check the status in Azure Active Directory, if you have none of these agents installed, then install at least one and verify it's listed in AAD, once I had done this my passwords synced correctly you can download the agent required via the Pass-through authentication download link here

normally you should always have both the X64 and X86 versions of the boot image on your PXE enabled Distribution Point. you can also check the source version, you can add that column to your SCCM view, for package RPI00002:3, RPI00002 is the packageID, 3 is the source version, you need to confirm that the source version 3 is indeed on the dp's mentioned in the log

Introduction Windows 365 gives you the power to do your job anywhere, and when you install the Remote Desktop app (available for Windows, iOS, Android, Mac) you'll be able to get your job done using multiple monitors. I'm a great believer in multiple monitor setups and like to use 3 monitors when working from home. In this blog post you'll see how you can use multiple monitors with Windows 365 whether you are using Windows or an Apple Mac as the base OS that you connect from. Step 1. Get the Remote Desktop app When you login to https://windows365.microsoft.com you'll be presented with a web page similar to below showing one or more Cloud PC's assigned to you. Click on the download icon. Next, select the Remote Desktop app download that matches your operating system and architecture, in this example I download the 64 bit Windows Remote Desktop app. Step 2. Configuring remote desktop for Windows After downloading the app, install it. Once the app is installed (and subscribed), it will launch. You will then see your Cloud PCs in tiled format. You can change that to list format if you want to see the specs of each Cloud PC easily. To modify the display settings for the Windows version of the Remote Desktop app, right click on your Cloud PC and Settings will appear as shown below. By default the Use default settings is enabled. Turn if Off to see more options. After turning default settings Off, you will see some nice Display Settings options, click on the Display Configuration drop down menu. In my example, I want to use all three monitors and arrange them to my liking, so I select the Select Displays option, from there i can identify the order of my monitors and select how many I wish to use, I selected all 3. After enabling this, I close the settings option and launch the remote desktop app. Here is the result, my Windows 365 Cloud PC is using all 3 monitors. Awesome or what ! If you take the display out of full screen you can right click the Remote Desktop toolbar and you'll have some additional options with Display Settings. Step 3. Configuring remote desktop for Apple Mac On an Intel based Macbook Pro with DisplayLink drivers installed, the experience is similar except you first have to have configured your desired display settings in Mac System Preferences by clicking on the Display icon. And then configure your desired preferences there. Next, open the Windows 365 Remote Desktop app and on your selected Cloud PC, use the 2 finger click on the touchpad and then select Edit. Make your desired choice for how you want the monitors to display things by clicking on both the Apple Mac and the External monitors listed. Once you are happy with the configured settings close that window by clicking on Done and launch your Cloud PC, here's a view of the same thing via the Mac. So there you have it, you can really maximise the benifit of multiple monitors when using your Cloud PC as long as you are using either a Windows PC with the app or an Apple Mac + Displaylink + the RD app and a compatible USB-C docking solution. Currently (at the time of writing) Linux doesn't have an app that works with Windows 365 and multiple monitors. Android does have an app as does iOS but I don't have a docking solution available for either platform to test multiple monitors with them. cheers niall Related reading Get started with the Windows Desktop client | Microsoft Docs

what version of SCCM is this ? are you using Configuration Manager to manage bitlocker or MBAM on another server ?