All Activity

Acknowledged. I will abide by this. Please PM a download link, and I will have it preserved only for own personal use.

it's licensed software so cannot be uploaded to any internet archive sadly.

@anyweb And yes, I'm also here to request a copy of such aforementioned SCCM 2007 & 2012 install support files. And additionally, I request a concent for uploading them onto the Internet Archive, so everyone from now on can access the file without sending you a request.

Retro computing is a fun and archeology. Preserving legacy software is a method to let us not to lose memories on technology history and evolutions. It would be a loss to watch let them die out in time. And there do are actual usages when commercial maintenance for legacy systems is needed. We well know that running unsupported legacy systems is dangerous, and will only do this on VMs or dedicated offline hardwares for pure non-commercial proposes. That's also why the Internet Archive and the Computer History Museum (Mountain View, CA) are created. MS (and many other software vendors) should preserve their support & download resources for legacy softwares, at least throw them onto dedicated archive sites or work with 3rd party organizations, instead of violently delete them from their servers and only make them accessible to internal staffers. Of course it's on their own discretion.

a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } here's the full reply from my chat with Copilot, you should try it too Short answer: yes — your boundary configuration is very likely the issue. Using only Active Directory Site boundaries can absolutely cause exactly what you’re seeing: Clients resolve a boundary But don’t get a valid DP or fallback DP assignment Result = updates sit at 0% downloading ✅ Why this is happening SCCM content download (including updates) depends on: Client is inside a boundary That boundary is part of a boundary group That boundary group has a Distribution Point (DP) assigned With AD Site boundaries only, problems occur when: AD Sites are not accurately mapped to IP subnets (very common) Clients’ IP ranges are not tied to the correct AD site Subnet definitions in AD are missing or incorrect 👉 Result: Clients may: Fall into no boundary Fall into a boundary group without content locations Try to download from a DP they cannot reach Sit at 0% downloading indefinitely 🔍 Your specific situation Your IP ranges: 192.168.0.0 172.20.0.0 172.10.0.0 172.40.0.0 But you're using: ✅ Active Directory Site only 🚨 Problem Unless all these IP ranges are properly mapped in Active Directory Sites and Services, SCCM cannot correctly assign clients. This is extremely common in environments where: Networks expanded over time AD Sites weren't kept updated Multiple IP ranges exist in one logical site ✅ Recommended Fix (Best Practice) ✔️ 1. Add IP Range Boundaries Yes — you should absolutely create IP Range boundaries for each of your ranges. Example: Boundary Type Range IP Range 192.168.0.1 – 192.168.0.254 IP Range 172.20.0.1 – 172.20.0.254 IP Range 172.10.0.1 – 172.10.0.254 IP Range 172.40.0.1 – 172.40.0.254 👉 Adjust ranges appropriately to your subnet masks. ✔️ 2. Add them to the correct Boundary Groups Put all new IP range boundaries into your existing boundary groups Ensure each boundary group: ✅ Has a DP assigned ✅ Has site assignment enabled (if needed) ✔️ 3. Leave AD Site boundaries (optional) You can keep them, but: 👉 Best practice: Use IP range boundaries as primary Use AD Site boundaries only if you trust their accuracy 🔧 Additional things to check ✅ Check Boundary Group settings Verify: DP is assigned: Administration → Hierarchy Configuration → Boundary Groups Under References tab: ✅ Distribution Points listed ✅ "Use this boundary group for site assignment" if applicable ✅ Check fallback configuration If clients are failing to find content: Enable fallback (optional, but helpful) Configure: Neighbor boundary group relationships Fallback time (e.g., 20–60 minutes) ✅ Verify client logs On one affected machine, check: LocationServices.log Look for: Boundary detection Assigned boundary group DP location requests ContentTransferManager.log Look for: Stuck download attempts CAS.log Look for: Content location failures DataTransferService.log Look for: BITS download issues 🧪 Quick validation test On a problem client: Run: PowerShell ipconfig Show more lines Then check: PowerShell nltest /dsgetsite Show more lines 👉 Compare the AD Site vs actual IP If: IP doesn’t match AD Site mapping → confirmed root cause ✅ Expected result after fix Once IP boundaries are added: Clients correctly map to boundary groups SCCM returns valid DP locations Updates move from: 0% downloading → downloading → installing 💡 Pro Tips (real-world SCCM guidance) ✅ IP ranges are the most reliable boundary type ❌ AD Sites are often neglected → unreliable ✅ Always verify with logs, not assumptions ✅ If “0% downloading” appears → it's almost always boundary/content location ✅ Final Answer Yes — relying only on Active Directory Site boundaries is very likely causing your issue. 👉 You should: Add IP range boundaries for all your networks Associate them with your boundary groups Ensure DPs are correctly assigned

Hi Anyweb, First question What do you mean with best practice? Use IP range boundaries as primary Do you mean I have to change from Active Directory site to IP RANGE? Can I edit the Active Directory site to to IP RANGE? I created 4 new Boundary with IP Range and add them to the existing Boundary Group( I have only one), Now my Boundary Group show me 4 Members. My default Boundary was Active Directory site and I added 3 new IP RANGE Boundary and the "References" Is there any more steps I have to do?

a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } from Copilot. 1. Add IP Range Boundaries Yes — you should absolutely create IP Range boundaries for each of your ranges. Example: Boundary Type Range IP Range 192.168.0.1 – 192.168.0.254 IP Range 172.20.0.1 – 172.20.0.254 IP Range 172.10.0.1 – 172.10.0.254 IP Range 172.40.0.1 – 172.40.0.254 👉 Adjust ranges appropriately to your subnet masks. ✔️ 2. Add them to the correct Boundary Groups Put all new IP range boundaries into your existing boundary groups Ensure each boundary group: ✅ Has a DP assigned ✅ Has site assignment enabled (if needed) ✔️ 3. Leave AD Site boundaries (optional) You can keep them, but: 👉 Best practice: Use IP range boundaries as primary Use AD Site boundaries only if you trust their accuracy

I'm in the process of deploying windows updates to Windows Clients (Windows 11 build 25H2) Windows servers(2019,2022,2025) in my environment with SCCM and ADRs and most of the client computers have installed updates just fine however around 50 or so client computers are not installing updates and the updates are not getting downloaded. When I click to install updates it just stays stuck at 0% downloading and never installs until eventually it times out My Boundary and Boundary Groups the updates have been distributed to the DP servers. The boundaries are configured to include the clients in the scope. All of my boundary groups are set up with the Active Directory site only. We have the following IP Range 192.168.0.0, 172.20.0.0, 172.10.0.0. 172.40.0.0 But I set my My Boundary and Boundary Groups with the Active Directory site only. Is that the my issue? Should/Could I create or add some new Boundary with IP address Range(what we have see above IP Range) additionally to my Active Directory site? Could you please help me? Regards

Introduction I’m sure by now that we are all aware of the coming changes to Secure boot certificates as documented by Microsoft here. To cut a long story short, when Secure Boot was introduced by Microsoft back in 2011 or so, they secured it with some default certificates which are set to expire in June 2026. Secure boot checks the bootloader and verifies it’s digital signature, if it’s trusted it allows it to run, otherwise it blocks it, which is a good way of blocking rootkits, bootkits and other low-level firmware attacks. Historically speaking Secure boot became part of UEFI 2.0 specification in January 2006, but Microsoft started rolling it out in 2011 including distributing the first Secure Boot signing certificates in 2011. These were later released to mainstream computers with the release of Windows 8 in October, 2012 where Microsoft required OEMs (Original Equipment Manufacturers) to enable Secure boot and ship systems with UEFI mode enabled. The original 2011 secure boot certificates were designed with a 15 year lifecycle, and in 2023 Microsoft introduced new 2023 certificate authorities. So here we are, all those years later, updating the bios (firmware) of modern laptops and desktops to ensure that they are capable of updating/supporting the new certificates prior to them expiring. There are plenty of good blog posts out there today showing you how to best deal with the Secure Boot certificate problem, but they are really focusing on supported, modern hardware, below are some examples. https://blog.mindcore.dk/2026/04/secure-boot-certificate-update-intune/ https://joymalya.com/intune-secure-boot-2023-certificate-update-rollout-part-1/ https://pureinfotech.com/windows-11-secure-boot-certificates-expiring-june-2026/ https://techcommunity.microsoft.com/blog/windows-itpro-blog/secure-boot-playbook-for-certificates-expiring-in-2026/4469235#community-4469235-_option2 What about older hardware ? But where does that leave older hardware that does support UEFI and secure boot, and should they be turned off/disposed of ? Security experts would most likely say yes to the latter question as they’d be wide open to rootkits/bootkits which is a painful reality when you consider the cost of new computers today thanks to the AI boom. I’m actually writing this article on an old Lenovo T570, which technically is old, it was released in 2017, but has been updated with Windows 11 25H2, and 32GB ram. It’s not the snappiest but it works fine for what I need. I looked at Microsoft Intune’s infamous secure boot status report and it showed me lots of red x’s for my older hardware even though I was already pushing out remediation scripts in my Intune lab to deal with the Secure boot certificates expiry mess. The following were looking sad: Lenovo T570 Dell Optiplex 9020 Microsoft Surface Pro 2 You can access this report in the Intune console by clicking on Reports, Windows Autopatch, Windows quality updates, Reports, and finally selecting the secure boot status report. You can see the details of the report that I ran below, the green arrow shows my Lenovo T570 is not up to date for any of the 4 certificates listed in the report. So I posted a tweet on Twitter (yeah, that’s what I call it) and got some instant feedback, which is the reason for this blog post. In the screenshot below you can see when the bios was last updated on my Lenovo (2024). Fellow MVP, Mike Terrill responded with some great advice. You should still be able to push the certs into the active db. However, the default db wouldn’t get the updated certs. If you did a factory restore of the bios, then the active ones would be replaced and need to be installed again. And he included some Powershell examples from his talk at MMS. I’m including his Powershell code below. All credit to Mike Terill and Gary Blok (I believe). $SecureBootRegPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' New-ItemProperty -path $SecureBootRegPath -name "AvailableUpdates" -PropertyType dword -Value 0x1844 -Force Start-ScheduledTask -taskname '\Microsoft\Windows\PI\Secure-Boot-Update' #verify get-securebootuefi -decoded -name DB | Where-Object {$_.Subject -match "2023"} | Select subject get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject -match "2023"} | Select subject So basically I ran the code above on my Lenovo T570 (from an elevated prompt) and the results were interesting. Below we add a reg key and trigger a scheduled task. The registry value tells Windows to deploy all available certificate updates as documented here and/or here (thanks Jon). and reveal the certificate status after a reboot To my joy, the following day the secure boot status report looked much much better for my Lenovo. Success! thanks Mike! I also got info from another Twitter user and he advised me to look here for some additional advice for patching older systems. https://www.elevenforum.com/t/garlins-powershell-scripts-for-updating-secure-boot-ca-2023.43423/ I did of course try the same method on some other old computers (Microsoft Surface Pro 2, Dell Optiplex 9020) and while it had some success with some of the certs, it couldn’t update the Microsoft Corporation KEK 2K CA 2023 certificate. According to Copilot this was because the firmware on the Dell and Surface, was just too old. Perhaps, perhaps. But then why did my Surface Book 2, which has a firmware (bios) date of wait for it, 2015 update all of the 4 certificates without any issue. That remains to be seen. I’ll update this blog post as I learn more, I definitely don’t want to ‘trash’ some old computers just because their secure boot certificates can’t get updated, worst case scenario I’ll convert them to Linux. On My Surface Pro 2 it updates 3 out of 4, the 4th being the missing KEK certificate, just like on the Dell. Looking in the SYSTEM event viewer, Event ID 1803 is showing every time I trigger the scheduled task from the Powershell script. That links me to this: Understanding Secure Boot Events 1802 and 1803 – Microsoft Support Learn more Finally, if you want to learn more aboute this subject (better late than never) take a look at this Patch My PC webinar, or Johan Arwidmarks free training on the subject: https://patchmypc.com/events/secure-boot-2026-are-you-actually-covered/ https://academy.viamonstra.com/courses/mini-course-secure-boot-2026 Summary Windows Autopatch on it’s own is not enough for getting these systems up-to-date with regards to the Secure boot certificate expiry. There are remediation scripts which definetly help, but they are mostly aimed at modern hardware. Thankfully, you can update some older hardware by using the example script above, either manually or push it out via Intune/ConfigMgr after you have of course ensured that the bios version is the latest available and that Windows is up-to-date. Thanks again to Mike, the beer is on me at MMS in October

contact me on Teams, and i'll see if i have some time > niall@windowsnoob.com

Hi, my SCCM Server does not work fine like before many years. I want to building a new SCCM server from scratch can I still use the old container (called System Management) and delegate control by adding the new server without necessarily extending the AD schema? Could I let running it the old SCCM server and install a new one fresh instillation of SCCM Server? Regards Nick

Hi Nail, I have a big issue with ADRs on the SCCM with monthly Windows updates. On the client machine the download does not work or stucking by 0% or waiting for install. I'm really desperate, do have time for a remote session? Thank you Nick

pros versus cons means what is positive about the solution (pros) and what is negative about it (cons)

Pros and Cons. It means, I do not to run Cons?

Hi, I have created some ADRs for Windows Server and Clients Updates with following settings Software Updates Deployment Schedule If I understand this option correctly, it should run automatically after 7 Days and deploy it to Distribution Server Evaluation Schedule, every month on second Tuesday Could you tell me please why it is not running automatically evey month? What is here wrong? Thank you Regards

Hi, I have created some ADRs for Windows Server and Clients Updates with following settings Software Updates Deployment Schedule If I understand this option correctly, it should run automatically after 7 Days and deploy it to Distribution Server Evaluation Schedule, every month on second Tuesday Could you tell me please why it is not running automatically evey month? What is here wrong? Thank you Regards

only what i posted directly above, which explains it quite well.

Hi, I have created a ADR for Windows Defender to deploy every day the new security intelligence update on Windows Client and Windows Server. It works fine, but only one machine (windows server 2025) does not get the security intelligence update. But if I go the device and proprieties, I see on the Deployment, the security intelligence update is there, but not install. How and where check it why? Regards

Yes I want only have the WSUS Server to convert to HTTPS Do have a Guide step by step?

if you are only talking about the WSUS server then the following could be possible, but messy. Short answer: Yes, you can enable HTTPS on a WSUS server without a full PKI infrastructure, but you still need some form of certificate, and the approach has trade‑offs. 🔐 What WSUS requires for HTTPS WSUS itself doesn’t require a Microsoft AD CS / enterprise PKI. It only requires: An SSL certificate bound in IIS to the WSUS website Clients that trust that certificate So the real question is not “PKI or not,” but how you issue and trust the certificate. ✅ Your main options without PKI 1. Self-signed certificate (most common workaround) You can generate a self-signed cert directly on the WSUS server. Steps: New-SelfSignedCertificate -DnsName wsus.yourdomain.local -CertStoreLocation Cert:\LocalMachine\My Then: Bind it in IIS to the WSUS Administration site Configure WSUS to require SSL: & "C:\Program Files\Update Services\Tools\wsusutil.exe" configuressl wsus.yourdomain.local ✅ Pros No PKI needed at all Quick and simple ❌ Cons Clients won’t trust it automatically You must manually or via GPO: Export the cert Deploy it to Trusted Root Certification Authorities on all clients 2. Public certificate (rare for WSUS, but possible) If your WSUS server has a publicly resolvable name, you can use a certificate from a public CA (e.g., DigiCert, Let’s Encrypt). ✅ Pros Already trusted by clients No GPO distribution needed ❌ Cons Usually not practical (WSUS is internal) DNS + internet validation required 3. Private CA alternative (lightweight, not full PKI) If you don’t want “full PKI,” you can still: Stand up a minimal AD CS (even temporary) Or use tools like: OpenSSL CA Small internal CA solution This is technically “PKI,” but much lighter than a full enterprise deployment. ⚠️ Critical things people overlook 1. WSUS only secures metadata, not update binaries Even with HTTPS: Update content can still download over HTTP This is by design (Microsoft signs updates) So HTTPS mainly protects: Client ↔ WSUS communication Metadata integrity in transit 2. Required IIS configuration WSUS does not require SSL on all virtual directories. You should: Require SSL on: SimpleAuthWebService DSSAuthWebService ServerSyncWebService APIRemoting30 ClientWebService Do NOT require SSL on: Content Selfupdate 3. Group Policy must be updated After switching to HTTPS: Specify intranet Microsoft update service location Change: http://wsus:8530 To: https://wsus:8531 4. Firewall and ports Default WSUS HTTPS port: 8531 Ensure clients can reach it ✅ Recommended approach (real-world) If you truly don’t want a PKI: 👉 Use a self-signed certificate + GPO distribution This is the most common setup in smaller environments. 🧠 Bottom line ✅ You do NOT need a full PKI infrastructure ✅ You DO need a certificate ⚠️ The key requirement is certificate trust on clients

it is a lot of work, are you sure, I cannot convert only Wsus Server to HTTPS?

you can't convert from http to https without a pki infrastructure in place first. Moving to https means you need something to deliver and create those certificates, that's where the PKI infrastructure comes into play. There is something from Microsoft called enhanced http, but that's not the same thing, you can read about it here: https://learn.microsoft.com/en-us/intune/configmgr/core/plan-design/hierarchy/enhanced-http so if you truly want your SCCM and WSUS infrastructure and clients to operate in PKI (https) mode, then you'll need a PKI infrastructure in place, it's not that hard to setup if you follow my detailed guides. Test in a lab first !! below is the response from Copilot on this subject Short answer: No — you can’t properly convert SCCM (Configuration Manager) from HTTP to HTTPS without a PKI infrastructure. Why PKI is required SCCM’s HTTPS mode relies entirely on certificates for: Client authentication Site system role authentication (MP, DP, SUP, etc.) Encrypted communication between clients and site systems These certificates must come from a trusted Certification Authority (CA). That’s exactly what a PKI provides. Without it, SCCM has no trusted mechanism to validate identities. What happens if you try without PKI Clients won’t trust the management point Authentication will fail You’ll see certificate or communication errors (MP unreachable, client not approved, etc.) Core features like software deployment and inventory break Your realistic options ✅ Option 1 — Stay on HTTP (not recommended long-term) Works without PKI Less secure (deprecated in modern environments) Microsoft is pushing away from this model ✅ Option 2 — Use Enhanced HTTP (recommended middle ground) Does NOT require full PKI Uses self-signed certificates automatically managed by SCCM Provides encryption and improved security compared to HTTP Much easier to implement 👉 This is what most organizations do if they don’t have PKI. ✅ Option 3 — Build PKI and move to full HTTPS Requires: Active Directory Certificate Services (AD CS) Certificate templates (client auth, web server, etc.) Deployment of certs to clients and servers Most secure and fully featured option Recommendation If you currently have no PKI: Enable Enhanced HTTP first Plan PKI deployment separately Later transition to full HTTPS when ready Summary Mode Requires PKI Security Level Notes HTTP ❌ Low Deprecated direction Enhanced HTTP ❌ Medium Best without PKI Full HTTPS ✅ High Requires PKI

No I dont have pki infrastructure in place, I want only to convert or to change the WSUS Server from HTTP to HTTPS. An I have to be sure that after convert the WSUS and SCCM does work together for SUP and Windows Updates. What should I do for WSUS Server on the SCCM and for all Clients machine? Thank you for help

you haven't stated if you have a pki infrastructure in place, do you ? if not you'll need to set that up also, see > to convert SCCM and WSUS services to HTTPS i cover the process here, my recommendation is test this in a lab first and/or hire a pki consultant to assist with the job

Hi, I have a SCCM Server with WSUS Server on the same machine with Windows Server 2025. Now I want to change the WSUS Server from http to https. Is that easy or is there any step by step guide? I have to be 100% sure after change from HTTP to HTTPS, my SCCM and WSUS Server work fine Regards Keywan