anyweb

ok and you are sure that the computer(s) are in the collection where this policy is targeted ? did you upgrade configmgr recently ?

as per my guide above " double-check that you've configured and enabled the BitLocker Management Settings in the Client Management setting of the configured BitLocker Management policy "

well that step is something you've created so what exactly does it check for ?

according to your log, this is why it failed, I'm curious though, did you read the log ? The execution of the group (PreChecks) has failed and the execution has been aborted. An action failed. Operation aborted (Error: 80004004; Source: Windows) TSManager 20/01/2021 15:39:16 9960 (0x26E8) Failed to run the last action: Foundation Application Check. Execution of task sequence failed. The line in question that you need to investigate is: Failed to run the last action: Foundation Application Check. Execution of task sequence failed.

it's been a long time since i blogged about it (see here) but i think you'll have to go n+3, so probably offline upgrade from 1606 to 1706 or so and so on, 1606 has been unsupported for years now what took you so long you will definitely have your work cut out for you here...as you'll also need to upgrade SQL server more than likely, and maybe even the os of the server below is what an old lab of mine looks like (version 1610) after I triggered a sync, so in this case you can see that it can upgrade to 1710 (n+3) so that was... 1610 (n) 1702 1706 1710 based on this I'll guess that you can do the following... 1606 (n) 1610 1702 1706 (n+3) 1710 which would mean that you could theoretically upgrade from 1606 to CM2006 like so 1606>1706>1806>1906>2006

I'm glad you sorted it out, thanks for posting your findings

zip up the logs please and include the netsetup.log from %windir%\debug

Introduction In a previous blog post I explained how you could use the SendGrid resource in Azure to send emails, and with a PowerShell script create an Intune app to give end users additional options when resetting their Windows Autopilot provisioned pc. This app would gather the Autopilot diagnostic logs (and other relevant logs) and send an email to your support inbox prior to resetting the pc. This was a very popular post so I updated the code to add some new features and to give more information to the end user. So let's take a look at the changes. New reset option In the new version (version .003) there's an additional reset option called Refresh, it's based on the doWipePersistUserData option here and this allows user account and data to be retained during the reset. In addition, I've added approximate estimations of how long each reset will take (I might adjust these later on with better estimations), this gives the end user a good idea of which option might be best for them. Tooltips I've added tooltips throughout the tool so if you hover the mouse over an option you'll get details about what it offers. You can customize the content of the tooltips in this section of the reset-windows.ps1 PowerShell script. Updated messages I've modified the messages to make them clearer to the end user. Below is one example. Check for Power The script now checks if a power source is connected, and prompts the end user to connect power if not. This check will only occur if the computer is not a virtual machine. Testing the script To test the script, you can use psexec to launch a cmd prompt in SYSTEM context. After doing that, you can launch the reset-windows.ps1 PowerShell script to see how it works after your changes. psexec /i /s cmd.exe and below I'm launching the script using SYSTEM context Don't forget to configure the to/from address and API key here After resetting, the email is sent and this is what it looks like Download the files Ok now you've seen the changes, give it a try ! follow the instructions in the previous part and use the updated script here. Note: you must be logged on to windows-noob.com to download scripts. reset-windows_ver_003.zip cheers ! niall

are you copy/pasting the step ? if so the password has to be re-entered...

now I see it, i'll reply soon

i didn't see any email...I checked my junk email folder and nothing from you, double check where you sent it to

please take a look at my recent post on the subject, it covers the new method of doing this

drop me an email/teams chat on niall@windowsnoob.com and i'll talk to you there

I don't do captures any more, stopped using build and capture more than a few years ago, it's just too much work for too little gain, instead, I use vanilla wims (download the latest from VLSC) in complex osd task sequences that install/configure everything during osd

I imported your task sequence but that was as far as i got today, i have the day off tomorrow so i'll try and look into it, but first things first, why are you capturing an image in the first place, that's old school (now), most people just push out vanilla wim images and add apps in the task sequence

what does the removeapps log file tell you, it's in c:\windows\temp (or the smstslog folder)

i'll try and do it tomorrow and report back

ok thanks are there any odd ascii characters in that password ? can you please share a screenshot of your join domain step, i've contacted Microsoft PG and they don't believe there's any restrictions on password length, the join domain step should even accept 500 characters... i definitely need the log file from a failing domain join to get more understanding of this

I'm planning on testing it in my lab over the coming days, it's just that work takes first priority and right now i'm working on getting some functions to work in Azure, once i've that working i'll try and help here

how many characters do you have in the computername ? can you share the smsts.log with me ?

thank you ! I'm looking forward to hearing about how people use this and expand upon it ?

Introduction Windows Autopilot deployment profiles allow you to decide if the user is a local administrator or a standard user. With all the security concerns today, choosing an User account type of Standard as shown below is a logical choice, but it does have some downsides. Certain abilities within Windows are not available to the end user without elevating their status. For example, as a standard user if you need to reset Windows when things take a nosedive (yes, it does happen), you cannot do it without elevating your session using Windows built in reset abilities, you could use the option in Company Portal, devices, but it doesn't allow you to gather logs, or email the reason for the reset, and it's troublesome to find. As an Intune Admin you could of course trigger the reset from within the Endpoint Manager portal, but what if you want your users to be in control of when and where they make that choice. By providing the users with this self service ability means one less call to the help desk. To give your users the ability to easily self reset Windows, and to do it in a way that your company can benefit from, you can provide an app that runs in SYSTEM context via the Company Portal and that's what this blog post covers. It shows you how to display a simple UI to your end users which runs in SYSTEM context, yet can interact with the end users and gather important data prior to initiating the reset. Step 1. Get the scripts Note: You can only download these files when logged on to windows-noob.com reset-windows.zip Note: In part 2 I've updated these scripts to include more functionality. Extract the files. Step 2. Get ServiceUI.exe from MDT You'll need the ServiceUI.exe executable file to display user interfaces (UI) to end users when operating in SYSTEM context. 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 win32app_source folder so it looks like this. Step 3. Get the Win32 content prep tool Download the Win32 content prep tool from here. Copy the IntuneWinAppUtil.exe file to your reset-windows source folder, it should look like this. Step 4. setup Sendgrid in Azure In https://portal.azure.com login and add a resource called Sendgrid. After creating the resource, click on Manage In the sendgrid web site, choose to Create a sender. Once that is done and you've verified the sender, you can review your sender in the settings node in the sender authentication area. Next you should Create an API key, to create an API keysimply expand Settings in the left pane and choose API Keys followed by Create API Key, I chose full access. Make sure to copy your API key somewhere safe... After all that is done, you can test sending your first email, there's lots of help at sendgrids site. Do not continue until you've got confirmation that you can send email successfully. Step 5. Modify the script Using the API key you copied from above, open the reset-windows.ps1 script and paste in that value (line 144 below). Make sure to also configure the $ToAddress and $FromAddress variables. Save the changes to the script. Step 6. Create your win32 app Open a command prompt and browse to the reset-windows folder structure. Launch the IntuneWinAppUtil.exe file and answer the following. Please specify the source folder: win32app_source Please specify the setup file: reset-windows.ps1 Please specify the output folder: win32app_target Do you want to specify catalog folder (Y/N)? n as shown here. After doing that you'll have the needed reset-windows.intunewin file in the win32app_target folder. Step 7. Create your Win32 app in Endpoint Manager Log into https://endpoint.microsoft.com and add a new Win32 App. Below are some screenshots showing how I've configured the app. App information Program Notice how I add install.cmd and uninstall.cmd here, also note that I've selected the Install behavior to System. Requirements Detection rules with the following detection rules The app is then assigned as available to All my Windows Autopilot users. Continue through that process and Save the changes. Step 8. Test it ! Note: you can test the script prior to uploading it to Endpoint Manager easily by using psexec and launching a cmd prompt in system context with psexec /i /s cmd.exe. From there you can launch the PowerShell script. On a Windows Autopilot computer that is deployed with a user that has a standard user profile, open the company portal app. After clicking the icon, the app will launch for the end user. The end user can optionally decide how they want to reset windows by clicking on the radio buttons or enter some text to explain why they are resetting Windows. Clicking OK will prompt the end user with some additional text and one last chance at cancelling things...you can customize this text in the Powershell script. If they click OK, then the app gathers Windows Autopilot logs and all logs in C:\Windows\Temp and the users local temp folder, then it zips them up and finally emails the zip to your chosen address, once all those are complete (a minute or so) it will start the reset. It logs the actions in the users temp folder (which are grabbed in the email) and here's the restart... closely followed with the actual reset ! The email will contain all the Windows Autopilot logs + log files from any apps you've installed on the device Job done ! One final note, the email provider you choose to use to receive the emails generated from this process should be one that doesn't natively block ZIP files (and there contents) like Google does. You'll be able to see this behaviour in the sendgrid email status Want more ? see part 2 of this blog series.

so you disabled all software update steps and it still fails ? please included the logs from that test.

Id recommend you disable your software update steps and re-test

ok i need to see more of this task sequence, please include a screenshot of the entire ts, are the install software update steps happening before or after the install applications ? because the last thing in your latest log is