anyweb

sorry i had a long day, can we do a remote session tomorrow, i'm in Sweden so GMT+1

you can install the portals as mentioned here (scroll down) and for troubleshooting see this post

are you doing as follows, enabling the feature creating bitlocker management policy testing it or are you doing something differently ?

yeah we can try that tomorrow evening if you want (teams to talk, quickassist to view) ping me @ niall AT windowsnoob.com

is the client version on the clients the same as the site version ?

did you enable the feature ?

check your proxy settings

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

yes i've seen it, I assume you are talking about the Technical Preview releases ? I have the exact same problem in my Technical Preview lab and reported it already to Microsoft

Introduction This blog series is comprised of 3 parts. In part 1 you reviewed a video of the solution and then carried out the initial steps to set everything up. In part 2 you saw how you could modify files, text and graphics to customize the app so that it matched with your company look and feel. In this part you'll look at troubleshooting to assist you with a deeper understanding of the solution and using that knowledge to make it work in your environment as quickly as possible. Migrate to the cloud - Part 1. Setup Migrate to the cloud - Part 2. Customization Migrate to the cloud - Part 3. Troubleshooting <- you are here Step 1. Test the app using SYSTEM context During the testing phase, use SYSTEM context to test the scripts. This verifies that everything you do will work correctly when it's eventually converted into a package/application in ConfigMgr. PSExec allows you to launch processes in SYSTEM context and as this app will run in SYSTEM context you should test and verify that it behaves correctly. To do that download PSExec from here and then launch an Administrative Command prompt. To launch a new command prompt in SYSTEM context issue the following command. psexec /i /s cmd.exe After launching the cmd prompt you can start Powershell to test the solution. Step 2. Familiarize yourself with the log files The app writes logs for each component that is running to the default log location which is C:\Windows\Temp\Sweepback as shown here. There are two main components for each part, the main script itself, and it's corresponding status script, each have their own separate log files. You can open the log files with CMTrace and monitor them live or when debugging issues. If you let the solution run to completion the following log files are generated in the default log file location of C:\Windows\Temp\Sweepback Win.AP.sweepback_part1.log Win.AP.sweepback_part2.log Win.AP.sweepback_part3.log Win.AP.sweepback_status_part1.log Win.AP.sweepback_status_part2.log Win.AP.sweepback_status_part3.log Step 3. Use devmode during development While you are testing the solution in your environment and tweaking it, you should enable the devmode variable. This allows you to include an Abort button on the 3 status screens, this will aid in troubleshooting as you can close the status screen and monitor logs live in CMTrace. Note: The Abort button does not stop the progress it just closes the currently open status screen. To enable devmode find the devmode variable in the main script and set it to $true, like so... after setting the variable to $true, save the script and then update your package to your distribution points. After doing so, you'll find the handy Abort button on all three of the status screens allowing you to easily close the status screen and check logs/registry settings/event viewer. When you've solved all your issues with the script, don't forget to flip devmode back to $false. Step 4. Familiarize yourself with the registry settings The app writes several regkeys to the following locations, you can review them to verify that it's writing the correct data. Below are the 2 locations that it will write to. The registry keys are used in the remaining parts so if not correctly written things will fail. It writes to the root of HKLM\Software and after the app is launched it writes to HKLM\SOFTWARE\Company where Company is your company name. The atStep registry key records the step which is currently shown in the status screen (usually from 0 to 7 depending on which part you are in). Step 5. Use the email ability If and when the app fails, it should send an email to your configured email inbox via the Azure Sendgrid ability. You'll need to configure Sendgrid as per the first part of this series and add your APIKey to the main script. Tip: You can manually force a failure (to capture logs etc) by calling the somethingfailed function during script execution as shown here. When running the script with that forced failure, the following will appear Here's an example of an email sent to your inbox when something fails. and the zip itself contains all logs generated at that point Step 6. Scheduled tasks The solution uses scheduled tasks to auto start parts, such as part 2 and part 3. During part 1 it will create a scheduled task to change the Windows Shell used during part 2, you can see that scheduled task here (sometime during part 1) before starting part 2. this scheduled task will be deleted upon successful completion so if something goes wrong, you can always ask the end user to restart the computer and if you are lucky it'll launch the scheduled task for that part and continue... Below you can see the scheduled task used to launch part 3 (which is created during part 2). Step 7. Test virtually When testing this solution, use virtual machines such as Microsoft Hyper-v (Generation 2) or VMware Workstation and take snapshots before running the script. If you do test it using hyper-v, run the scripts with enhanced mode OFF otherwise it'll fail to detect the logged on user. Once you've ironed out all the bugs, copy the scripts to your package source and test them via Software Center ! Well that's it, I hope this information has motivated you enough to start migrating your computers to cloud management ! until the next time, adios ! cheers niall.

update: this is now resolved natively without the need for a Powershell script in ConfigrMgr 2203, read more here > https://www.niallbrady.com/2022/03/06/new-video-escrow-bitlocker-recovery-password-to-the-site-during-a-task-sequence-in-configuration-manager-2203/

Introduction This blog series is comprised of 3 parts. In part 1 you reviewed a video of the solution and then carried out the initial steps to set everything up. In this part, you'll see how you can modify files, text and graphics to fit in with your company look and feel. Migrate to the cloud - Part 1. Setup Migrate to the cloud - Part 2. Customization <- you are here Migrate to the cloud - Part 3. Troubleshooting Step 1. Add a custom icon in Software Center Right now the app looks pretty generic in Software Center and doesn't have a custom icon. To create one open sweepback.png (found in C:\dev\autopilot_sweepback\encode files) in MsPaint. Resize/crop the graphic to 256x256 pixels. Save that resized file as sweepback_icon.png. Using an online website like this one upload the sweepback_icon.png file and download the converted sweepback_icon.ico and copy the saved file to your package source In ConfigMgr, locate the Application (or package) that you created the original app with, and change the icon there to point to our new sweepback_icon.ico file. click Apply when done. After updating policy on the client, the app will show in Software Center with the new custom icon. Much nicer! Step 2. adding your company logo to the status screens During the migration the end user will see various status screens showing what is currently happening, and those screens include a company logo which is currently set to the windows-noob.com egg. To edit the logo open the CompanyLogo.png file in MSPaint. and paste in your company logo, I'd recommend that you try and retain this exact size otherwise you'll have to modify each of the following files with any new dimensions. Win.AP.Sweepback.status_part1.ps1 Win.AP.Sweepback.status_part2.ps1 Win.AP.Sweepback.status_part3.ps1 If you do decide to change the logo size then you'll need to modify the $PictureBox.width and $PictureBox.height section of the scripts, that in turn may need other modifications to the other parts of the script that displays text/graphics. . Once you are done modifying the CompanyLogo.png file save it to your script source, eg: C:\Dev\autopilot_sweepback\Encode files Below is my 'new' company logo. To add the new company logo to your solution, you'll need to encode it, so start Powershell ISE as Administrator and open encode.ps1 located in C:\Dev\autopilot_sweepback\Encode files enter the following Set-ExecutionPolicy unrestricted and then run the encode script. After it has run, locate the Encoded_CompanyLogo text document as shown here. Open it in notepad and press CTRL+A followed by CTRL+C (to select all and copy) Paste the encoded text into the corresponding section of your Win.AP.Sweepback_part1.ps1 script as shown here: Note: If you modified the text or graphics dimensions in any of the status scripts then you'll need to copy/paste the encoded data from those files also into the main script. After modifying the company logo, you'll need to test the scripts to verify that it's changed and of course working. Below you can see the new company logo in the status screen of part 1. Step 3. Adding/changing steps in the status screens Each status screen is tied to it's corresponding script like so Win.AP.Sweepback_part1.ps1 >>>> Win.AP.Sweepback.status_part1.ps1 Win.AP.Sweepback_part2.ps1 >>>> Win.AP.Sweepback.status_part2.ps1 Win.AP.Sweepback_part3.ps1 >>>> Win.AP.Sweepback.status_part3.ps1 If you want to modify the number of steps in a status script, then you will have to do so first in the status_partx script and if needed in the associated partx script within the takeaction function. Below you can see some of the steps that are displayed during the third status screen script. You could add or modify the text here to suit your own needs. the status scripts do count the number of steps so if you add or remove a step then you'll need to also modify these two values. Step 4. Modify the initial warning message When users select to start the migration, they'll get an initial popup informing them what is about to happen and what is expected of them. If you want to modify that text, find it in the main script in this section, and make and edits that you feel are appropriate. Save the file when done. Note: After making your edits, don't forget to update any encoded files into the main script, and to copy that main script to your package source, once done, update that source to your distribution points. Then test and verify your changes on a virtual machine. Job done! Please do join me in the final part where we'll look at troubleshooting the solution.

ok i've uploaded a new copy of the scripts, it should resolve the devmode issues we saw in your lab last night

have you verified it's correctly creating the APSweepback account ? you can place an EXIT 1 just after that section in the takeaction function....to troubleshoot it further and then make sure you have devmode=$true so that you can click abort to the status screen. you can reach me at niall AT windowsnoob.com

HI @bondy666 i'm happy to do a remote quickassist session to take a look if you want, and yes the djoin variables are for an on-premises account, ideally i'd like to remove that from the script altogether but haven't got around to that yet when testing the script manually, make sure to run it as Administrator, or better yet, as SYSTEM context (using psexec /i /s cmd.exe) the APIkey is only used for sending emails via Sendgrid (emails are sent when something fails) and this key is generated when you configure sendgrid to send emails, see from point 4 of this blog post

try tagging him like so @Sokoban maybe he can clarify what he did to resolve it

Introduction This blog series is comprised of 3 parts. In this part I'll cover how you can migrate your existing configuration manager managed, domain joined devices to Azure AD joined, and Intune managed devices. During that process the app also converts those devices to Windows Autopilot devices, all with minimal downtime for the end user and via an easy to use self-service app. Migrate to the cloud - Part 1. Setup <- you are here Migrate to the cloud - Part 2. Customization Migrate to the cloud - Part 3. Troubleshooting If you'd like to see a video showing the entire migration process then here it is. Note: In the video, I refer to a Windows Hello for Business problem pin entry, but that was simply because I was restoring a check-pointed virtual machine and testing it over and over. You shouldn't see that problem on regular computers. The app itself is comprised of 3 main parts which does the following: Part #1 1. Create local migration admin account APSweepback, enable Autologin 2. Remove MBAM client 3. Remove SCCM client 4. Change the Windows shell 5. Drop out of the domain 6. Restart computer... Part #2 1. AutoLogin as APSweepback account 2. Start second script (shell) 3. rename old 'on prem' account to xxxxx.OLD 4. popup AADJ wizard asking for credentials 5. convert the device to Windows Autopilot device 6. create scheduled task for part 3 7. restart computer (to reapply UAC settings and for WHFB) Part #3 1. Install Company Portal 2. Launch OneDrive for Business 3. Cleanup registry keys and changes 4. add to Autopilot Sweepback completed AAD group (for reporting and remediation scripts) 5. popup notification that all is done and logoff The app development is mostly done, but it's still evolving based on feedback, if you know of better ways of doing things within the app then do please let me know. Here's a short overview of the apps main features Created with Powershell Uses Azure Functions (HttpTriggers) Disconnects a device from the domain/ConfigMgr Connects to Azure AD/Intune (uses Auto MDM enrollment) Convert device to Windows Autopilot Users data stored in OneDrive Users data remains on the device after migration Installed apps remain installed on the device UI front end for the end user Status screen indicating progress Detailed Logs Email ability (via Azure/Sendgrid) Step 1. Get the scripts Note: You can only download these files when logged on as a member of https://www.windows-noob.com autopilot_sweepback.zip Note: Last updated 2022/05/31 (v1.4 logsfolder bug) Extract the zip to C:\DEV The extracted ZIP files should look something like this Step 2. Get ServiceUI.exe from MDT You'll need the ServiceUI.exe executable file to display user interfaces (UI) to end users in SYSTEM context. As our app will be deployed from ConfigMgr in SYSTEM context, we'll utilize ServiceUI.exe. To get the file, download and install MDT somewhere and navigate to C:\Program Files\Microsoft Deployment Toolkit\Templates\Distribution\Tools\x64. To download MDT click here. Copy the ServiceUI.exe file to your extracted C:\DEV\autopilot_sweepback\Encode files folder so it looks like this. Step 3. create some azure ad groups In Microsoft Endpoint Manager (MEM), create two Static Azure AD groups with the following names: Autopilot Sweepback Completed Convert devices to Windows Autopilot After creating the groups, take note of the ObjectId of each aad group. Step 4. create a Windows Autopilot deployment profile In MEM, navigate to Devices, Windows, Windows Enrollment, and select Windows Autopilot Deployment Profiles, select Create to create a new profile and make sure that Convert all targeted devices to Autopilot is set to YES and that the profile is assigned to the Convert devices to Windows Autopilot Azure AD group created in step 3 above. Step 5. create an Azure function In Azure, I will assume you've already created a functionapp as per Step 4 of this blog post. If not, go ahead and create one and then return to this step. Next create a new httptrigger called add_device_to_aad_group and insert the following code into it. # Niall Brady 2022/05/21 (used by the Check Compliance, Software Updates to devices solutions amongst others...) # Dynamically ADDS a device to an azure ad group # using namespace System.Net # Input bindings are passed in via param block. param($Request, $TriggerMetadata) # Write to the Azure Functions log stream. Write-Host "PowerShell HTTP trigger function processed a request." # Interact with query parameters or the body of the request. $deviceId = $Request.Query.deviceId $GroupID = $Request.Query.GroupId if (-not $deviceId) { $deviceId = $Request.Body.deviceId } if (-not $GroupId) { $GroupId = $Request.Body.GroupId } # define the following variables $ApplicationID = "" # this is the id of the app you created in app registrations $TenantDomainName = "" # your tenant name, eg: windowsnoob.com $AccessSecret = "" # this is the secret of the app you create in app registrations # create the body $Body = @{ Grant_Type = "client_credentials" Scope = "https://graph.microsoft.com/.default" client_Id = $ApplicationID Client_Secret = $AccessSecret } # make initial connection to Graph $ConnectGraph = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenantDomainName/oauth2/v2.0/token" -Method POST -Body $Body # get the token $token = $ConnectGraph.access_token $token # to improve logging... $triggerName = "add_device_to_aad_group" $a = Get-Date $body = " `n" $body = $body + "$a Starting the '$triggerName' function...`n" $body = $body + "$a Connected to tenant: $TenantDomainName.`n" #START $FindDevice if ($deviceId -and $GroupId) { $Group = Invoke-RestMethod -Method Get -uri "https://graph.microsoft.com/v1.0/groups?`$filter=Id eq '$GroupId'" -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value $GroupName = $Group.displayName $body = $body + "$a You supplied deviceId: '$deviceId'" + ".`n" $body = $body + "$a You supplied groupId: '$GroupId'" + ".`n" $body = $body + "$a Group.displayName: '$GroupName'" + ".`n" #$GroupMembers = Invoke-RestMethod -Method Get -uri "https://graph.microsoft.com/v1.0/groups/$GroupID/members?$filter " -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value # | Select-Object -ExpandProperty Value # below fixes the 100 members per returned result in AAD problem $GroupMembers2 = Invoke-RestMethod -Method GET -uri "https://graph.microsoft.com/v1.0/groups/$GroupID/members?`$count=true&`$filter=startswith(deviceid,'$deviceId')" -Headers @{Authorization = "Bearer $token";"ConsistencyLevel" = "eventual"} # if found do this if ($GroupMembers2.value.deviceId){ #$body = $body + "--------------------------------------------------------------------`n" #$body = $body + "This device was found in the AAD group so no need to add it again...`n" #$body = $body + "deviceId: " + $GroupMembers2.value.deviceId + "`n" #$body = $body + "displayName: " + $GroupMembers2.value.displayName + "`n" #$body = $body + "--------------------------------------------------------------------`n" Write-Host -ForegroundColor Yellow "$GroupMembers2.value.displayName is in the group" $body = $body + "$a Device: " + $GroupMembers2.value.displayName + " is already in the " + $GroupName + " group, nothing to do.`n" $body = $body + "$a The computer is already in the group, nothing to do.`n" $Status = "Already present in group" } else { $AddDevice = Invoke-RestMethod -Method Get -uri "https://graph.microsoft.com/v1.0/devices?`$filter=deviceId eq '$deviceId'" -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value | %{ Write-Host -ForegroundColor Green "Adding $($_.DisplayName) ($($_.ID)) to the group" $body = $body + "$a Adding $($_.DisplayName) ($($_.ID)) to the group with ObjectID $GroupID.`n" $ComputerName = $($_.DisplayName) $Status = "ADDED" $BodyContent = @{ "@odata.id"="https://graph.microsoft.com/v1.0/devices/$($_.id)" } | ConvertTo-Json # code to add it here... # the $ref variable is explained here... kinda # https://docs.microsoft.com/en-us/graph/api/group-post-members?view=graph-rest-1.0&tabs=http try {Invoke-RestMethod -Method POST -uri "https://graph.microsoft.com/v1.0/groups/$GroupID/members/`$ref" -Headers @{Authorization = "Bearer $token"; 'Content-Type' = 'application/json'} -Body $BodyContent # pause some seconds to allow time for the object to be populated if recently added... sleep 30 } catch { $body = $body + "$a ERROR ADDING THE DEVICE`n" $body = $body + "Here is the error message: '$_.ErrorMessage'" $Status = "ERROR ADDING THE DEVICE" } } } } #END $FindDevice $a = Get-Date $body = $body + "$a Exiting Azure function." # Associate values to output bindings by calling 'Push-OutputBinding'. Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{ StatusCode = [HttpStatusCode]::OK Body = $body }) In the code above, fill in the following values that correspond to your environment: ApplicationID TenantDomainName AccessSecret Don't forget to Save your changes in the Http trigger. Take note of the function URL by clicking on Get Function URL, it'll look something like this Step 6. edit the variables Next, open Powershell ISE and locate the win.ap.sweepback_part1.ps1 powershell script. Fill in or change the missing values for the variables listed below: Note: DjoinPwd and DjoinAcct must use valid credentials for a user in your domain. The values below are examples from my lab. So it looks more like this (the values from my tenant are blurred): Note: The APIKey value is for sending emails using sendgrid, if you'd like info about setting that up see this guide (point 4) Next, open the encode.ps1 script and run it, once completed, browse to the Encoded files folder and locate the After running the script, locate the encoded_ServiceUI.txt file and open it in notepad. Copy the contents of that file using CTRL+A followed by CTRL+C Paste that code into the following line in between the quotation marks Save the changes to the win.ap.sweepback_part1.ps1 code. Step 7. create and deploy the app in ConfigMgr In my example, I simply created a package/program in ConfigMgr to deploy this app, use whatever application model you wish. To do this simply copy two files to a folder called Autopilot_Sweepback and use that as your package source. ServiceUI.exe win.ap.sweepback_part1.ps1 the program for the package uses the following line ServiceUI.exe -process:explorer.exe %SYSTEMROOT%\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass -File Win.AP.Sweepback_part1.ps1 as shown here Next, deploy the package to a collection containing some devices you want to migrate. Step 8. Test it Now the hard work is mostly done and you can start testing it, launch it from Software Center and start migrating to the cloud ! That's it, join me in the next parts where we'll go a little further! cheers niall Related reading https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/to-aad-join-or-not-that-is-the-question/ba-p/3435768 https://www.windows-noob.com/forums/topic/15773-how-can-i-enable-mdm-auto-enrollment-for-microsoft-intune-in-azure/ https://docs.microsoft.com/en-us/windows/client-management/mdm/mdm-enrollment-of-windows-devices https://docs.microsoft.com/en-us/mem/intune/enrollment/enrollment-restrictions-set https://techcommunity.microsoft.com/t5/microsoft-endpoint-manager-blog/the-journey-to-cloud-based-device-management/ba-p/3264631 https://docs.microsoft.com/en-us/mem/cloud-native-endpoints-overview

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 ?

Introduction This video is a quick look at the Migrate to the cloud app. The Migrate to the cloud app is a Powershell based solution delivered via Software Center in Microsoft Configuration Manager, that takes your domain joined, ConfigMgr devices and migrates them to Intune management and converts them to Windows Autopilot devices in the process, all done without data-loss and minimal user interruption or downtime. You can check out the video here. I'll be posting a blog post or two covering how to implement this in your own environment, watch this space.

hi @rahill here's what I got from Microsoft ConfigMgr 2203 current branch Eval - https://aka.ms/MECM2203CB-Eval ConfigMgr 2202 technical preview baseline - https://aka.ms/MECM2202TP-Baseline

hi Robert, do you require 2103 eval for Current Branch or will another (later) version do ?

you are right it doesn't work currently, Microsoft has been made aware of this i\ll update this once i know more

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

first things first, have you created any bitlocker management policy yet ? when you create your first policy it starts installing things, and maybe that's what you are missing

if DNS doesn't work then nothing will work, you need to fix DNS first and then deal with all the other issues.