Peter33

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)#

The better option is to use the ReleaseDate property, which is a datetime value.

Your problem seems to lie not in the application itself. Check out this post. https://larslohmann.blogspot.de/2014/01/task-sequence-fails-with-error.html Maybe it will help you to solve this.

You should check the 64Bit check box in your last screenshot. Otherwise the value will be written to the 32 Bit registry node. 64 Bit clients will not read informations from this location.

OK, think i got it now. The dynamic file content changes the task at hand. You could still do it by using compliance rules, but it gets quite boring and a lot of work when you have to cover every possible version number. That would require a new rule for every possible version. So let's forget about that. The better approach is to create a new custom WMI class, write the file content to a class property and include this new class in your clients hardware inventory. This way query your SCCM database for the Image Version and create custom reports or collections. Here is a tiny script that creates a new class $file = "C:\temp\file.txt" if(Test-Path -Path "$file" -ErrorAction SilentlyContinue) { # Delete WMI Class if it already exists if(Get-WmiObject OSDImageVersion){Get-WmiObject OSDImageVersion | Remove-WmiObject} # Create new WMI Class OSDImageVersion $ImageVersion = Get-Content -Path "$file" -ErrorAction SilentlyContinue $ImageVersion $wmiclass = New-Object System.Management.ManagementClass("root\cimv2", [String]::Empty, $null); $wmiclass["__CLASS"] = "OSDImageVersion"; $wmiclass.Qualifiers.Add("Static", $true) $wmiclass.Properties.Add("ImageVersion", [System.Management.CimType]::String, $false) $wmiclass.Properties["ImageVersion"].Qualifiers.Add("Key", $true) $wmiclass.Put() # Write WMI Class Property ImageVersion [void](Set-WmiInstance -Path \\.\root\cimv2:OSDImageVersion -Arguments @{ImageVersion=$ImageVersion}) ` } You just need to create a new SCCM Package and run the script on each client once. I would also recommend to get rid of the versioning in the text file during OSD and use WMI from the start.