anyweb

Join our Autonomous Endpoint Patch Virtual Launch Event to see the most significant advancement in 3rd party patching. October 25th,2022 7:30-9:00 AM PST (90 Mins) Kevin Mitnick and Bryan Seely, world-famous hackers, bestselling authors, and cybersecurity experts, will host and keynote our virtual launch event. As industry thought leaders, they'll discuss the newest and most relevant threats and tactics that real hackers will exploit. Mitnick will even demonstrate how simple it is to hack an EDR Sensor vulnerability and 2F authentication in real-time. Whether you’re on SCCM or using a “psuedo-automated” patching tool you won't want to miss the launch of our revolutionary, fully autonomous 3rd party patching solution. Autonomous patching allows you to fully automate one of IT’s most manual and laborious tasks from initial identification to enterprise-wide deployment. With Adaptiva’s new Endpoint Patch you can quickly build custom patching strategies for your unique applications, business units, and users, then sit back and let it automatically execute your patching over and over again. Tune in to: See a real-time demonstration of hackers exploiting common enterprise application vulnerabilities. Learn what makes Adaptiva's Endpoint Patch so visionary compared to existing patching products on the market today. Discover how Endpoint Patch will save your organization hundreds of human hours. And more... Save your seat today!

Introduction Satya Nadella just announced the Windows 365 app at Ignite 2022 today, and you can see that in the keynote below. He said that the new app means you can access Windows 365 directly from your taskbar or start menu. The Windows 365 app is now in public preview, providing a direct path to Windows 365 from the Task Bar or Start menu with a personal, customized experience that can be tailored to each individual. Getting the Windows 365 app Note: If you'd like to get started with Windows 365 see here. To get the app, you need to be using Windows 11 and to have a Cloud PC available. Windows 10 does not support the app. On a Windows 11 PC, open Microsoft Store and search for Windows 365, it's currently in preview. Click on Get and it'll start downloading. After that app is downloaded and installed it will auto launch in the context of the user you are logged in as, the user I was using didn't have a Windows 365 Cloud PC assigned so I signed in as a user that did have one available, after doing that I got to see the 4 screen intro which you can optionally skip, it was my first time seeing this so I wanted to see each screen. here's screen 1 here's screen 2 here's screen 3 and the final screen after completing the Intro, you get access to your Cloud PC and are treated to another tour, which you can also skip. The tour has an additional item and that is to provide feedback, shown here. To launch your Cloud PC, click on the Connect button. It will probably say 'Authenticating', in my case nothing happened after that except it failed to connect and showed an error and 'see details'. I determined that the reason it failed to 'Connect' was because the popup asking for the user credentials was behind the Windows 365 app, and therefore I didn't see it. In the below screenshot you can see the error and the Windows Security window which I've now moved on-top of the Windows 365 app After clicking Connect again and entering my credentials all was good and my Cloud PC launched. The connection seems to be an actual RDP session so it's definitely a better option than the default Web browser session which you can launch via https://windows365.microsoft.com If you are docked to multiple monitors it will open the Windows 365 Cloud PC session on all monitors, and in my case that's 3 monitors side by side. pressing ESC when fullscreen allows you to then set settings in the RDP session like below You can always launch the app again from the Start menu as you can see here or via the taskbar as you can see here For more info, see the official Microsoft announcement here. until next time, cheers

Introduction Linux is a free open-source operating system that has grown in market share over the years and is now found in many different versions (distributions or 'distros'). I wanted to see exactly how well my Windows 365 Cloud PC worked on real hardware when the host OS was running Linux. Windows 365 is a Cloud PC that is accessible from any HTML 5 capable web browser which you'll find on pretty much all modern operating systems including Linux. Please note that this entire blog post was written using the Linux distros below while connected to my Cloud PC. Let's take a look at how well that works using a few popular free Linux distros including: LinuxMint Ubuntu Fedora You might wonder why I am using just the web browser in these tests, the reason, at the time of writing there is no remote desktop app available for Linux. Note: If you'd like to vote for a Linux based RDP client for Windows 365 then click here. LinuxMint LinuxMint is based on Ubuntu, which in turn is based on Debian. I downloaded LinuxMint version 21 from here and installed it on a HP EliteBook 830 G8 via USB bootable media created using http://unetbootin.github.io/. The installation was fast and I selected to also include 3rd party codecs when prompted during installation. After I installed LinuxMint I updated it. That too was quick and painless. Once done, I launched Firefox and browsed to https://windows365.microsoft.com I entered my credentials, satisfied the MFA request and within a few seconds could see the normal Windows 365 welcome screen showing my available Cloud PC. After clicking on Open in browser, I could launch the Cloud PC proper. This particular Cloud PC was a 2vCPU, 8GB RAM, 128GB Storage running Windows 11 22H2 using the Hybrid Azure Ad Join method as described here. As you can see the Windows 365 toolbar is at the top of the web browser session, and you can click on the Collapse Toolbar section to make it hide away. This is better, but to get the best experience out of your Cloud PC via a web browser from Linux, press F11 to maximize the browser window, this will show only the Cloud PC. So now that it looks and feels like Windows 11 (on LinuxMint Linux) it's time to actually use the Cloud PC. Video playback On the Cloud Pc, I used the Edge browser and started watching some videos, the results were OK but there was some noticeable lag from time to time. Unfortunately, there is currently no ability (that I am aware of) to use multimedia redirection in Linux currently like there is for Windows PC's. So, we'll have to make do with that lag. You can see some of that lag in the following video where I set the video playback settings to 1080p. The lag seems to be the same whether or not the browser is full screen or not. Blog writing Next, I logged in to this site (which is an Invision Power Forum) and started editing the very blog post that you are now reading. It was fast, easy to scroll around and worked just as well as if I was using the real thing. Quite fantastic actually. I was able to upload screenshots that I had taken in LinuxMint using the upload ability in the W365 toolbar. That worked great the first time I did it and I uploaded several screenshots successfully, but the 2nd, 3rd and 4th attempt it uploaded nada, zilch. I think this is possibly a bug in the toolbar and I'm not sure if it's related to Linux or the version of the Windows 365 client on Windows 11 version 22H2, I've asked the Microsoft Product Group for comment. Below you can see my later attempts at uploading screenshots, it said it was done and that I should move them but they did not appear in the uploads folder. Using Office 365 apps I started up PowerPoint, Excel and Word and had no issues with creating content on the Cloud PC, it honestly felt very easy indeed and I would forget that I was using Linux at all when creating content using Office 365. Scrolling through Powerpoint was easy and fast and rendered perfectly in the web browser. Word was a breeze And Excel was also equally easy to work with. I launched Outlook and that too worked seamlessly, no issues to report. From an Office perspective, I definitely think this worked just fine in test conditions. That said, my Cloud PC is not laden down with a plethora of security and other agents designed to read every file a million times while consuming every last iota of CPU and storage bandwidth. Hardware support I'm not a touch pad fan so I connected my trustee Think Pad mouse with an USB dongle. It worked perfectly. Next, I tried to connect my Bluetooth headphones (Freebuds 4). But when I tried to connect to them in LinuxMint it failed. Same thing for my Freebuds 3. It seems that this version of LinuxMint has bluetooth issues as reported here: https://forums.linuxmint.com/viewtopic.php?t=378859 Next, I plugged in my Jabra 2 with it's wireless dongle and that worked fine. Teams performed just fine, without any noticeable lag. I held an audio meeting with Paul and it was totally fine, no lag, very little audio issues until the end of the call, in fact it worked better that I'd normally expect a teams meeting to perform. I wasn't however able to to a video meeting as my web camera on the HP was not detected or shared with Teams. sudo apt-get install cheese -y got the camera working in LinuxMint. However I cannot see any way to share that camera with Windows 365 via a web browser session. If you'd like to vote for a Linux client for Windows 365 then click here. Ubuntu Ubuntu is another Debian based distro and a very popular one too, in fact it is the first distro to get Linux management support via Intune as you can read here. I downloaded Ubuntu 22.04.1 LTS from here and set about testing everything I tested above with LinuxMint. During the installation, I split the disk into two, allowing me to keep LinuxMint as well as have Ubuntu, that's a really nice ability with Linux. The installation was very easy and within minutes Ubuntu was installed. I fired up the usual Office 365 apps and all worked as before, no issues there. I even uploaded files (and edited this blogpost) from Ubuntu directly to my Cloud PC using the upload feature, and this time it worked (more than once). Hardware Support I wanted to test the camera and found out that Cheese was already installed. The camera worked fine in the Ubuntu desktop as you can see below without me having to install or configure anything, that was good ! but when I launched Microsoft Teams on my Windows 365 Cloud PC once again the camera was not detected, so that's a no-go for video meetings with Teams on Windows 365 if you are using Linux with your Cloud PC. Once again, as with LinuxMint I had issues with Bluetooth, I couldn't get either of my Bluetooth headphones to work, I plugged in my Jabra 380 wireless USB-C wireless dongle and I got working audio. This means that audio meetings/calls in Teams are at least possible on my Windows 365 Cloud PC when using Ubuntu. Video Playback Video playback while using Ubuntu was certainly OK, I started watching the Inspire 2021 session where Satya announced Windows 365 Cloud PC and played it in a window as well as full screen, the performance was totally acceptable, however I did notice what can only be described as audio ticks when playing back video content, this was also noticeable in LinuxMint. Perhaps there are better audio/video drivers available for my test hardware, but I didn't find them however I did see that according to Ubuntu, this hardware was certified for Ubuntu Linux as of May 2021. The only difference between my test system and the certification was the version of my BIOS. and full screen Fedora I downloaded Fedora 36 from here and proceeded to install it on my HP EliteBook 830 G8. The installation was relatively quick, and I did have to adjust the disk partitions to get it to fit alongside Ubuntu and LinuxMint. As with Ubuntu, Cheese was installed meaning that my camera worked in Fedora Linux, but not in Teams via the web browser on my Windows 365 Cloud PC. ed Video playback via youtube on the Cloud PC worked just fine with the odd audio tick as noticed with the other Linux distros, but overall, it was perfectly acceptable. Setting the web browser settings for Windows 365 to use high dpi does improve the readability somewhat. Uploading files and continuing to edit this blog post also worked with no problem so I was able to be productive on the go using my Cloud PC. Office 365 apps continued exactly where I left them. And I think that is the key differentiator here, being able to use whatever operating system you want on your host computer to connect to your Windows 365 Cloud PC to do your daily work without fuss. It's quite amazing and refreshing. Summary Using Windows 365 Cloud PC on your Linux box gives you the power to get your work done, anywhere using the Operating System of your choice. I did note some short comings with this approach such as the lack of a real remote desktop (RDP) client from Microsoft for the Linux OS. Web based sessions can only do so much and the lack of this RDP client will leave you with the inability to host video meetings in Teams, so keep that in mind if it's important to you. Note: If you'd like to vote for a Linux based RDP client for Windows 365 then click here. Please also note that there are some Linux based distros (which are not free) such as Igel that offer their own AVD/W365 based clients which are optimized for Teams and other meeting-based software (such as Zoom). I'll hope to write about that in a coming blog post.

too little info, have you verified that the client is the right version ? anything else you can share ?

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