Leaderboard

if this is a lab i'd suggest you rebuild the lab (doesn't take long) and before converting the lab to PKI take snapshots of the virtual machines, so you have different states (http/https/e-http) if you cannot do that then you'll have to experiment with removing bindings in IIS for https, removing the certificates to the dp role and more, and removing certificate services, quite a mess, you could basically undo all the settings where you switched to HTTPS back to HTTP

Ok so finally figured this out. On the ScanAgent.log I was seeing a lot of "Sources are not current" messages. This led me to dig further and that the SUP MUST be in the default boundaries group, which I didn't know. It apparently is new to 1702?!?! Once I added the SUP to the default group clients started reporting in instantly! Hope this helps someone out there. Regards Kevin

In my case with 20H2 there was still a pending cumulative Microsoft update KB5014699 that needed to be installed. After installing that update, I was able to connect through the admin console.

Just want to say thank you so much for replying and your help. so testing using your troubleshooting worked like a treat. i ripped it all out and re read everything and the part 2 ran perfectly. I have a question though, our on prem usernames are JBlogs (first initial then last name) where as our Azure UPNs are Joe.Blogs@ (firstname.lastname). when the part 2 appears and asks for you to sign in with your email and password to enroll, its JBlogs@companyemail.com. is there anyway to convert this to firstname.lastname? again thank you so much!

did you enable the feature ?

if you check in your SCCM DB, they are there, the issue is with the Console showing them... also, if you remember the ADR name and search for it by name it should show up

i don't have a lab in your state to test this on as mine already has bitlocker management enabled, so please go ahead and create a test bitlocker management policy, doing so will put in place things like bitlocker management services in IIS, back when this was first released in 1910 we had to run powershell scripts to get reports, but it's all integrated now

There should be some powershell commands to do this. aka edit the WMI data.

this method guides you through setting up a pki infrastructure as described, it does not cover what you are looking for however i'm sure once you are done setting this up, that setting up the remaining disaster recovery options will be doable, ask a PKI expert before you take on the task.

I saw the non-user version of the MSI from the original post didn't work anymore, so I uploaded my copies of them just in case anyone still needs it. TriggerBitlocker Windows-Noob v1.0.0.2 - User.7z TriggerBitlocker Windows-Noob v1.0.0.2 - System.7z

For anyone in the same situation - We simply deleted the failed classic CMG and recreated a new Scale Set CMG using the same service name and certificate. Changed DNS to point to the new URL and all worked fine. Clients reconnected to the new CMG without any issues.

**UPDATE** Okay, what worked for me was reading through this article https://timmyit.com/2018/12/17/mdm-join-an-already-azure-ad-joined-windows-10-pcs-to-intune-with-a-provisioning-package/ I already had an RMM in placed for my side of things, so, I just used the Powershell script that he had and pushed that out to all the devices. Once I did that, all the devices started to enroll into Intune. Learning Experience: Keep Note: If you started off with MSFT standard license and down the road you upgrade to a premium license. The above resolution will most likely fix your problem. I have attached zip file just in case Timmy site down the road goes offline. MDM_File.zip

Introduction Understanding when Windows Autopilot is complete is an interesting topic. It would be great if there was a reg-key or file that was set when Windows Autopilot completed successfully, but there isn't, at least not now. Or if there is, I haven't seen any official documentation stating it. In the meantime let's use some other method of determining whether it's complete or not. To do that we'll rely on the creation date of the Microsoft Intune Device Management Extension folder as that gets created on the device if a PowerShell script or a Win32 app is targeted to the user or device, and I'm fairly confident that we all have at least one Win32 app or a PowerShell script deployed to our Autopilot devices during the Enrollment Status Page (ESP) phase of Autopilot. You can see how the enrollment date is calculated from the script here. Note: The script will only run based on the hours since enrollment detected and the detected logged on user. The script will not run if it detects that the current logged on user is defaultuser0. That user is used by Windows during the Enrollment Status Page (ESP) Device Setup phase. As the script runs again during the Account Setup phase of the ESP (the last phase), this time it will be running as a user that is not defaultuser0 and in fact is the actual user that will use the computer. Therefore it will create a scheduled task to run XX minutes after the date/time that it detects, and that usually is 15 minutes or so after the user enters their credentials. It's not perfect, but it's better than nothing. Please adjust it to suit your individual requirements. If you know a better way to do this, then let us know. Now that we have an idea of when Autopilot finished, we can deploy a PowerShell script to our Autopilot users to present a welcome page to the end user. At least that's the idea, and speaking of ideas, this great idea came from a friend of mine on Twitter, I just expanded upon it and fine tuned it for my needs, so please show your thanks to Chris Roberts for the great idea, and do him a favor and follow him on Twitter. The scheduled task will only show the web browser once (1 minute after login), during the time frame we've decided (first 48 hours after enrollment). This gives your users a nice warm fuzzy feeling that everything is completed, and let's them know that they can now use their computer. In order to achieve this we'll do the following. Create a static website in Azure Upload some files to the website Add a PowerShell script in Intune Note: This guide assumes you've already created an app for Microsoft Edge Chromium and deployed it to your Autopilot users. Step 1. Create Storage Account In Azure Active Directory create a storage account. To do that click on Create a Resource in https://portal.azure.com. In the page that appears, search for Storage Account. Select it and click on Create. You can attach it to an existing Resource Group or as in my case (to keep things clean) create a new Resource Group. Next, fill in a Storage account name and select the region and performance. And click on Review + create and after being presented with the summary, click Create. In the Storage Account, select Static Website from the options in the left pane. Set it to Enabled and provide the following file names Welcome.html and 404.html. Click Save when done. Next, click on $web, you will be presented with a simple interface for uploading files to your new static website. Step 2. Download files Download the Welcome page html files and the LaunchEdgeWelcomePage.ps1 PowerShell script here. Note: To download the files hosted on windows-noob.com, make sure you are logged on to the site first. Download the Welcome page files hereWelcomePage.zip Download the LaunchEdgeWelcomePage.ps1 hereLaunchEdgeWelcomePage.zip Download Microsoft Azure Storage Explorer Step3. Upload files After installing the Microsoft Azure Storage Explorer, browse to the $web folder of your storage account in the Blob Containers The easiest way to get the files and folders to the $web folder is to drag and drop from Windows File Explorer. Step 4. Change Access Level In the $Web container click refresh, you should see your files/folders. Click on Change access level to change the access level to these files. Set it to the access level you require, for example Blob access. To restrict access to this website and to block public see the following post. Step 5. Add the static website URL to the script In the $web container, click on properties. The static website URL is displayed, copy the url. Note: the returned URL is case sensitive. Edit the LaunchEdgeWelcomePage.ps1 PowerShell script and paste in your static website URL. Notice how I didn't copy over the /$web part of the url, it's added later. Save the changes. Step 6. Upload the PowerShell script to Intune In Endpoint Manager, select Devices, Windows Devices and choose PowerShell scripts. Add the edited LaunchEdgeWelcomePage.ps1 script. Don't forget to assign the Powershell script to your Windows Autopilot users. Step 7. Review the end result During Autopilot, you've probably enabled the ESP (Enrollment Status Page), if not it's a good idea to do so as it gives your users an indication that something is happening. After Windows Autopilot enrollment is complete, it should logon to the desktop, and Edge should launch with the welcome page. After the user selects the Sync option they'll see this (you can auto configure sync options). The user can click on any of the icons in the webpage to bring them to the online versions of those applications. In addition, an icon on the desktop links back to the welcome page. Step 8. Troubleshooting If it didn't go as planned, check for the presence of the scheduled task. Try running it manually, also look for the log file in C:\Windows\temp\LaunchEdgeWelcomePage.log The script creates a scheduled task to launch the welcome page one time (for each user that logs on to the computer within the allotted time frame of 48 hours) after Autopilot is complete. in In the example below I ran the script on my daily laptop and it wouldn't add the scheduled task as enrollment was many months ago. If you want to test it anyway, then temporarily remove the # on line 87 and try again. Make sure to add the # back before uploading the script to Intune. Note: If Edge Chromium doesn't install during the ESP for whatever reason, and yes, sadly it happens then this welcome page won't launch either. If that happens to you try plan b, which is to launch another browser (I picked Internet Explorer). Below is the section containing the workaround which is NOT in the main script, so it's here just in-case you want to use it. Replace the $action line with this # special workaround for cases where MS Edge Chromium failed to install during ESP LogWrite "checking if Edge Chromium is actually installed right now...." $EdgeChromiumPath = "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" if (!(Test-Path $EdgeChromiumPath)) { LogWrite "'$EdgeChromiumPath' is NOT present, will use plan b..." $action = New-ScheduledTaskAction -Execute '"C:\Program Files (x86)\Internet Explorer\iexplore.exe"' -Argument $websiteURL } else {LogWrite "$EdgeChromiumPath is present, good !" $action = New-ScheduledTaskAction -Execute $EdgeChromiumPath -Argument $websiteURL } # end workaround That's it ! Have fun and please let me know how you get on with this, if you modify the script or webpage then please show us your changes/ideas ! Useful links Favicon Generator Edge Chromium sync - https://docs.microsoft.com/en-us/deployedge/microsoft-edge-enterprise-sync Microsoft Azure Storage Explorer Intune device management extension Azure static website Azure Blob pricing cheers niall

We have WU blocked as all patching is handled by MEMCM. I found this workaround script to temporarily enable in the registry, add the feature, then set the registry back to what is was prior. $currentWU = Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Name "UseWUServer" | select -ExpandProperty UseWUServer Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Name "UseWUServer" -Value 0 Restart-Service wuauserv Get-WindowsCapability -Name RSAT* -Online | Add-WindowsCapability –Online Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Name "UseWUServer" -Value $currentWU Restart-Service wuauserv

Use the application substitution rule, first do the uninstallation of the old version parameters or scripts, in the installation will first uninstall the old version before installing the new version

Hello, I am trying to deploy CMTrace as part of the TS (SCCM 2012 SP1, no MDT integration) and also set it as default log viewer. This is my powershell script: $RelativePath = (split-path $SCRIPT:MyInvocation.MyCommand.Path -parent)+"\" Copy-Item -Path $RelativePath"CMTrace.exe" -Destination "c:\temp\" -Force xcopy "c:\temp\CMtrace.exe" "c:\windows\System32" /y xcopy "c:\temp\CMtrace.exe" "c:\windows\SYSWOW64" /y $CMtraceKey = "HKCU:\SOFTWARE\Microsoft\Trace32" Set-ItemProperty -Path $CMtraceKey -Name "Register File Types" -Value 00000000 $Parameters = "assoc .log=logfile" cmd.exe /c $Parameters The xcopy commands do not work for some reason, and smsts log doesn't show me anything. Can somebody advise on why the copy commands do not work and how can I apply the HKCU key properly ? Thanks

I imported some VHD's from Microsoft Virtual PC to Hyper V, and I noticed that one of my VM's had a problem, I couldn't add a second network card to it (I could add it in settings, but it would never appear as a new device on the VM or in the VM's device manager), so I checked out the device manager, there was a device with a yellow exclamation mark on it called VMBus. Double clicking on that showed me the following error After some googling I found this post and the advice in there was spot on, I had already installed my Intergration Services Setup disk and rebooted, but my problem remained, the VMBus was now called Virtual Machine Bus but still no network, so I ran MSCONFIG, clicked on boot, then clicked on the advanced tab and put a checkmark in Detect HAL, I clicked ok and reboot, some windows drivers were redetected and lo and behold my problem disappeared ! cheers ! anyweb

Yes, I am very sure. I was communicating with other it users and they also encountered this situation

I'm glad you got it sorted

Introduction I'm writing this post to catalog problems I recently faced while doing Windows Autopilot installations, we use a very slim enrollment Status Page (ESP) configuration with only one app marked as required (Microsoft Edge Chromium). The remaining applications are a mix of Win32 apps and the all important Microsoft Office 365 suite. This suite was configured with the following apps. Excel, OneDrive Desktop, OneNote, Outlook, PowerPoint, Teams, Word This worked well since about mid-February 2020. However, starting week 46, I started noticing the following error on newly delivered HP computers with Windows 10 version 1909 (and some office components preinstalled) after clicking the Microsoft Outlook icon soon after Windows Autopilot had completed. It looks ominous. Clicking OK and trying again, the problem looked even worse, you'd see something like this, outlook prompting you to choose a Profile. followed by a Script error, stating Class not registered on Line 278. Choose Yes or No had pretty much the same effect, Outlook was well and truly broken. If you clicked on the Account Information in Outlook you'd see something like this. A Metered connection warning followed by a Upgrade in Progress warning. The first is definitely a red-herring as the Network card was not in a state that was metered. When checking the version of office installed on affected machines I could see it was as shown below, Office version 2011. The interesting thing to note is that Computers that had a clean image of Windows 10 version 1909 with no Office installed previously did not exhibit this problem, it only affected factory image(s) of HP computers with Windows 10 version 1909 factory image and those images come with a version of Microsoft Office installed (in the Nordics), namely Microsoft Office 365 ProPlus version 1908 (Build 11929.20394). Troubleshooting Based on the above I knew that clean installs of Windows 10 1909 did not have the issue (even though they subsequently got the Office 2011 version installed before the user logged on). I initially suspected that security software or a device configuration profile were to blame, and went through the time consuming task of excluding a computer from each profile, and then resetting it to verify the behavior. Excluding a device from an assignment takes precedence over including a device so it was a good way of testing Windows Autopilot without certain settings or configurations, to rule them out. Below you can see I've excluded a group (containing my test device) from a Device Configuration profile, to verify if that was the issue. trying this didn't help, but it at least ruled out the following from being part of the problem. Device Configuration Profiles Win32 based Security based apps (such as Azure Information protection, Crowdstrike, Symantec DLP) Armed with that knowledge I recreated the Office Suite settings in my own test tenant, and ran a Windows Autopilot build, to my surprise the HP failed starting outlook the exact same way as in Production, so that completely ruled out everything other than the version of Office installed on the HP. Next I turned to logging options within Office/Outlook to see if that would help, but in reality it just generated .ETL files that I'm still analyzing in order to root-cause this issue. The breakthrough came when looking at the settings of the Office suite in Endpoint Manager. The version of Office that gets installed is based on your settings in the Office Suite, and we had been using these settings without problem since February 2020. The really important bit was the update channel, shown below. The update channel we were using was Current Channel (Preview). You can get details of the update channels here. According to Microsoft: ... three primary update channels: Current Channel Monthly Enterprise Channel Semi-Annual Enterprise Channel We recommend Current Channel, because it provides your users with the newest Office features as soon as they are ready. But what is the difference between Current Channel and Current Channel (Preview). According to Microsoft: To become familiar with the new features coming in the next feature release of Current Channel, we recommend that you use Current Channel (Preview). There isn’t a set release schedule for Current Channel (Preview). In general, a new version of Current Channel (Preview) with new features is released at least a week or more before that new version is released to Current Channel. There might be several releases of Current Channel (Preview), with non-security updates, before that version is released to Current Channel. You should deploy Current Channel (Preview) to a small, representative sample of users in your organization. This can help you identify any possible issues for your organization before those new features are released more broadly to your users that have Current Channel. We also encourage you to use Current Channel (Preview) so that you can identify any possible issues that you want us to fix before that version is released to Current Channel. This can help reduce the number of non-security updates that are needed for Current Channel. And this pretty much matched what we were doing, so now that we had this knowledge, but still had no root-cause for the Outlook (and Word/Excel issues). The Resolution I decided to change the Update Channel from Current Channel (Preview) to Current Channel. This decision was based on the fact that the Preview channel may contain changes that are incompatible with our image in some way, which is odd because we are using the factory installed HP image. Once I made the change, and re-tested Windows Autopilot the difference was clear. Now Outlook worked as expected without issue (and Word/Excel issues disappeared also), however the version of Office installed was Version 2010 instead of Version 2011 that we got in the Current Channel (Preview). This didn't matter too much but of course it meant that some cool new cloud friendly features in Version 2011 were now no longer available on newly installed Windows Autopilot machines. The versioning used by Microsoft for Office is somewhat confusing, in the Office Account screen you'll see the version info, here you can see it's listed as Current Channel, Version 2010 (the version without the problem). So version 2010 relates to year 20, month 10, or the October release of Office 365. That would of course mean that version 2011 is the November release. Note: we've noticed that HP's corporate ready image includes an office version that is released before the OS version was released, so for example if you get Windows 10 version 1909, then you'll get the Office version released approximately one month before that (Office version 1908). Likewise if you got Windows 10 version 2004, you should get Office version 2003. Summary Sometimes living on the edge means you will fall over. I know that changing from Current Channel (Preview) to Current Channel might only delay the problem until the Current Channel update channel migrates to the new version of office next month, so we may actually encounter this problem again, and soon. So to conclude, if any of you have come across this exact issue (I have searched and found similar problems with "Library not registered", but the advice within them didn't apply here), then please get in touch with me. In the meantime I will look through the gathered ETL traces to see if they provide any clue as to why Office was so broken on these new devices in order to root-cause the problem. Links used in this blog post Github script, Metered - https://gist.github.com/nijave/d657fb4cdb518286942f6c2dd933b472 Update Channels - https://docs.microsoft.com/en-us/deployoffice/overview-update-channels Office Versions - https://docs.microsoft.com/en-us/officeupdates/current-channel

ok first things first, the SMSTSPostAction variable is for use in operating system deployment task sequences to do an action after the task sequence has completed, are you planning on installing SEP as part of a task sequence ? if so use an Install Application step instead of Install Package if that's easier, or even run PowerShell script... but first, if you really want to install the app just using a powershell script then test the script on a virtual machine standalone, outside of a task sequence

If anyone gets an access denied error at the last step (certutil -crl), then please reboot your Issuing CA server once and then issue the command again. I had this issue and apparently several other users had this too per various forums.

Introduction I've been thinking about doing something with this issue for some time now and finally got around to implementing it, however credit where credit is due I've based this on a method developed by a colleague of mine (Magnus Mourujärvi) to work with a 3rd party's custom boot wims. Basically that method is a registry hack which takes place in the boot wim. Problem We've all seen this happening, you get new hardware, you PXE boot, it pulls down the boot wim but as you don't have network drivers in your boot wim the task sequence won't run, or worse it just reboots without telling you why. checking the SMSTSLog will give you clues as to the problem... Troubleshooting it further would involve doing some clever use of wbemtest to find out what the network card pnp device id is in order to identify what the right driver is to be added into your boot wim. It was this process that I wanted to simplify, making it easy to identify the problem and the helping the user identify the Network card in question. Solution Add two files to your boot wim, update them to the distribution points and sit back and watch the show. Well ok, not quite that easy, there are some steps to do, documented below. Step 1. Get the script Note: there is a newer version of the script here which also checks for SATA connections (storage) Download the CheckForNetwork.vbs script here. Yeah it's a vbs, if I get time I'll convert it to PowerShell. CheckForNetwork.zip Extract it to C:\Temp In the script locate the ServersToPing array and edit it to match one or more servers you want to ping in your address, and save the script. Step 2. Copy a file from the MDT 2013 Toolkit Locate your MDT Toolkit files package and browse to the folder matching the architecture of the boot image you intend to edit, for example if you plan on editing the x64 boot wim then use a path similar to below: \\sccm\d$\sources\os\MDT 2013\Toolkit\Tools\x64 Locate a file called windowhide.exe and copy it to C:\Temp Step 3. Create some temp folders On the C:\ of your chosen server, create the following folder structure C:\Mount C:\WinPEMount\ C:\WinPEMount\X64 C:\WinPEMount\X86 Step 4. Make a copy of your boot wim Identify your target boot wim in the Configuration Manager console as shown below, this will be the boot wim we are going to make changes to... Right click the boot wim and select the data source folder, make a note of the Image Path Make a backup copy of the boot wim (ctrl+c and then ctrl+v) and then copy the boot.wim file (or WinPE.wim if it's a MDT created boot wim) to C:\Mount as shown below. Step 5. Mount the boot wim and make some changes Using Run as Administrator, start the Deployment Imaging and Tools Environment cmd prompt as shown below In the CMD Prompt that opens, mount the boot wim by issuing the following command: dism /mount-wim /wimfile:c:\mount\boot.wim /index:1 /mountdir:c:\winpemount\x64 Tip: In the above command i'm mounting a Configuration Manager boot image called boot.wim, if this was a MDT Created boot image it would be named WinPE.wim. Now that the boot image is mounted, we can make our modifications. First we will edit a registry key but to do that, we need to mount it. Using REG.exe mount the SYSTEM hive of the mounted boot wim REG.EXE load HKEY_LOCAL_MACHINE\Mount\ "C:\WinPEMount\X64\Windows\System32\Config\SYSTEM" Once done, change the current value for CmdLine in the mounted registry hive to run our script instead reg add "HKEY_LOCAL_MACHINE\Mount\Setup" /v CmdLine /t REG_SZ /d "cscript.exe CheckForNetwork.vbs" /f Next we commit those changes to the mounted registry REG.EXE unload HKEY_LOCAL_MACHINE\Mount and now we copy two files from C:\Temp to C:\WinPEMount\X64\Windows\System32 (assuming you are editing the x64 boot image) copy c:\temp\CheckForNetwork.vbs c:\WinPEMount\x64\Windows\System32 copy c:\temp\windowhide.exe c:\WinPEMount\x64\Windows\System32 Now that we've made our changes, we want to commit them to the boot wim (write the changes) dism /unmount-wim /mountdir:c:\WinpeMount\X64 /commit as shown below Step 6. Copy the modified boot wim back to the Image Path in Step 4. Now that we've made the changes we need, copy the modified boot wim from C:\Mount back to it's original location Step 7. Update your boot image to the distribution points In the Configuration Manager console, locate your boot image, right click and update it to the distribution points as shown below Once done you are ready to test the new functionality in the boot image. Step 8. Review the changes If the network works ok in WinPE, the task sequence will load as normal and you won't see any popup, or notice anything other than an additional 12 seconds added to your boot time. However, in the event that you have no network and cannot ping any server in the array of server IP's listed in the script, you will see the following warning popup after WinPE starts (before the PXE password and before a task sequence is selected). Note: The script try's to hide Wireless nics from being displayed in the results as we don't use wireless nics for OSD, yet. As you can see from the message it provides the following info a reason for the popup (no network connectivity) lists the detected Network Card lists the PNP Device ID identifies the Computer model and gives the user some options click YES to retry (for example if the network cable was not connected) click CANCEL to open a CMD prompt if further troubleshooting is needed click OK to reboot. Below you can see what happens when the user clicks on Cancel well that's it ! have fun :-) cheers niall

windows-noob.com has been around for many years, and during that time I’ve written hundreds of step-by-step guides with screenshots. You may not be aware, but I’ve created indexes of these guides that cover multiple versions of System Center Configuration Manager (SCCM), Microsoft Intune and Microsoft Deployment Toolkit (MDT). These indexes are popular as you can see below. The indexes sort the guides into an easy to read format so that you can quickly find content that matches topics you are interested in learning more about. The guides themselves are detailed and include tips, PowerShell scripts and advice to get the job done and to teach you how to become a guru in no time. I spend a lot of time and effort to ensure the quality and content of these guides and always try to respond to feedback and questions about the content. If you are working with Enterprise technologies and are looking for step-by-step guides about SCCM Current Branch, Technical Preview, Microsoft Intune or even MDT then please do yourself a favor and check out (and bookmark) the indexes of guides listed below: Configuration Manager (Current Branch) step by step guides: https://www.windows-noob.com/forums/topic/13288-step-by-step-guides-system-center-configuration-manager-current-branch-and-technical-preview/ Microsoft Intune (standalone) in Azure step by step guides: https://www.windows-noob.com/forums/topic/15558-microsoft-intune-standalone-in-azure-step-by-step-guides/ Microsoft Intune (hybrid) step by step guides: https://www.windows-noob.com/forums/topic/10905-the-windows-noob-microsoft-intune-mobile-device-management-guides-now-available-to-download/ Configuration Manager 2012 step by step guides: https://www.windows-noob.com/forums/topic/4045-step-by-step-guides-system-center-2012-r2-configuration-manager/ Microsoft Deployment Toolkit step by step guides: https://www.windows-noob.com/forums/topic/15559-mdt-step-by-step-guides/ Please also feel free to share this post on FaceBook, Twitter, Reddit or whatever platform you use so that others can benefit from this content. cheers ! niall

You might want to check Action1 Endpoint Security - https://www.action1.com - they give you a lot of real-time information about your endpoints, including installed software, running processes, configuration settings and so on. You can also setup an alert when software installed/removed. And it is free for up to 100 endpoints.

Nice work on improving the version I created earlier, I'm sure many will benefit!

Need help, I´ve followed your manual and I got error 0xffffffff on run command step. I don´t have timeout selected. Is there anything else what I can check? Thank you. @already solved by adding proper path to powershell.exe file in Win10. Thx

If you (like me) have used Quick Assist in the past you might be disappointed to know that the built in Windows 10/11 app is going to be killed off in the coming days and replaced with Quick Assist from the Microsoft Store. If you start the Quick Assist app today you'll see something like this (taken from my Windows 11 computer). the text below is taken from the official announcement. Why is this a big deal ? Well for a couple of reasons namely... If you were supporting users in Windows Autopilot using CTRL+Windows key + Q, then that built in ability will be gone. If your users are Standard Users (and they should be) then they won't be able to install the app from the Store as it requires local admin permissions. Below screenshot is from a Windows 10 vm running as a standard user. If the computer you are supporting has Store app issues (and that's a common problem, for example store apps not working after a Cumulative update was installed and waiting on a reboot). The new app uses characters as well as numbers, and that might confuse some people Ironically, the new Store apps provided instructions say nothing about the fact that the user has to download the Store app to get support. Some think this is a good thing as it means only admins can install the remote assistance app, but I think it'll just push people towards alternatives What are your thoughts on this ?