Jump to content


Established Members
  • Content Count

  • Joined

  • Last visited

  • Days Won


Peter33 last won the day on March 1

Peter33 had the most liked content!

Community Reputation

44 Excellent

About Peter33

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Peter33

    Office 365 Software Updates

    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.
  2. Peter33

    Office 365 Software Updates

    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.
  3. Peter33

    Office 365 Software Updates

    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.
  4. Peter33

    Office 365 Software Updates

    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.
  5. 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
  6. 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.
  7. 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
  8. 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.
  9. 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.
  10. Peter33

    Surface Pro

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

    Rename VM Hyper V

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

    WQL version less than string

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

    Office 365 Deployment

    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.
  14. 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.
  15. 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.