Peter33

There is probably some kind of brute force protection built in. You could also just keep yout current TS structure and add the return Code 10 to the success list of the pw reset steps. Then add a reboot after each of those steps. Kinda ugly, but it should work.

You could simply run all 8 steps in single batch file and add "EXIT /B 0" as your last comand line. If you want to make it shiny you can also add an evaluation step after each pw reset line to check if the returned error code is 0 and if so jump to the end of the script.

The error 10 is unfortunately telling a different story. According to the HP white paper this means the password is wrong.

The Get-CMGlobalCondition CMDlet does not return a valid object for the AddRequirement property. This is a known problem and will be addressed in future CB versions. There is a workaround available though. https://social.technet.microsoft.com/Forums/ie/en-US/95e6ad51-0b5c-4d65-9831-753db4e3b557/how-to-add-an-existing-global-condition-to-an-application-deployment-type-via-powershell?forum=configmanagerapps

In combination of ConfigMgr Current Branch (1602 and later) and WSUS 4.0 you can create regular Update Packages and deploy them to your Clients. The ConfigMgr Client got a new feature with 1602 to Service Office 365 Clients. https://docs.microsoft.com/en-us/deployoffice/manage-updates-to-office-365-proplus-with-system-center-configuration-manager#BKMK_Reqs You can still update your Clients via regular UNC path updates if you can't meet the requirements above. I did that before we switched to currrent branch. Just run a weekly scheduled task to download the updates on your server and set the update path on your Clients to the specified UNC path.

Sure, it means whitelisting the required Domains so that the computer account can access them without the proxy authentication. Assuming that the proxy is managed by another department in your Company, you have to open a change request with them. If you are managing the Proxy by yourself you need to check the documentation on how to apply whitelistings.

All Right, log files are always helpful. You need to exclude http://officecdn.microsoft.com from the proxy auhtentication, so the computer account can access it.

Make sure that that you set the download source to Microsoft and not to your upstream server. Also make sure that all necessary microsoft URLs can be accessed through your proxy server. Check the ruleengine.log for error details.

OK, turns out that it happens to be a general legacy problem, after i imaged a newer model also in legacy mode. It happens only when the BDE drive in the formatting step is assigned with a drive letter. Ticking the option not to assign the drive letter solves the problem. Cheers Peter

Yes, actually Lenovo provided us with a new BIOS last month, updating the Micro Code regarding the Spectre mess. Both, the latest published (2014) and this Beta update showing the same behavior.

Is anyone able to image a Lenovo ThinkCentre M90p Desktop with CongigMgr CB 1806, MDT 8450 and ADK 1803? The imaged OS is Windows 10 1703 and 1803 (MDT captures). I know this is a rather old model, but I'm stuck with several thousand of those for quite a while until they will be replaced on demand next year. And yes it's a legacy BIOS system without support for Windows 10. Everything was peachy when running on CB 1802 and ADK 1703. Now i'm getting a blue screen right after the 'Setup Config Manager Client' step, when the client is supposed to start into Windows. Winload.exe error 0x0000e9 ... claiming that a connected device is not working My guess is that it is referring to the HDD. So basically that means the boot sector got messed up during the windows setup? I already checked the log files in the sysprep folder for errors, but there are none. Already tried to disable the driver installation step, but it doesn't make a difference. Even removed all injected drivers from the PE boot wim. The funny thing is, when i run the imaging over my MDT deployment share, without ConfigMgr, only with MDT 8450 and ADK 1803, it just runs fine and boots into windows without any problems. I also compared the loaded drivers in WinPE with DriverView.exe and both, MDT and SCCM boot images, are using the embedded standard drivers for AHCI and Ethernet. So any suggestions or hints what to try next are welcome. P.S.: Any newer models like M900, M910q, M710q (all UEFI )can be imaged without any problems. Thank you and have a great weekend! Peter

Well, i get that. But i think it's easier to create a patch application for every Reader Version. Then set the original Reader deployment as dependency for the patch application. The screenshot is just an example. You got to replace the ID and version with your values. There is no need for a gobal condition requirement.

Sounds way to complicated for me. We are using just a registry value detection with the "greater than or equal to" operator, which works just fine. It's probably easier to automate too.

Assuming you are using MDT you could simply use the variable IsLaptop=True.

Try this OSDComputerName=VM-#Left("#Replace("#Replace("%SERIALNUMBER%"," ","")#","-","")#",12)#