Forum Widgets
Latest Discussions
Import SSL failed 'Distribution Ubuntu-24.04-Mcc is not accessible from gMSA context'
I’m looking for assistance with troubleshooting issues importing a new SSL certificate purchased from Digicert. We are running MCC v2.0.0.2124_e with deployment application v1.0.24.0. Successfully generated the CSR, sent to Digicert and downloaded the signed certificate. Upon importing the certificate with gMSA on Windows Server 2022 we receive an error message "IMPORT_RESULT: FAILED, Certificate import failed”. I believe this is due to a known issue with the older deployment scripts v1.0.24.0. The following post acknowledges the issue and shows resolved in v1.0.26.0. Instructions mention “Then you may proceed to re-deploy your Connected Cache node…”. Is re-deploying the MCC node is required to fix the issue? I just updated the deployment scripts to v1.0.26.0 and attempted the certificate import again. Received error message "IMPORT_RESULT: FAILED, ERROR: Distribution Ubuntu-24.04-Mcc is not accessible from gMSA context”. Please let me know how to proceed. I can provide the logs for troubleshooting. If we need to start from scratch, do I need to generate another CSR request? Finally, are we able to use the Digicert certificate that we just purchased?
WSL Install Failures - 2.7.8.0
For those deploying new MCC servers, you may run into an error installing the distro for WSL, this appears to be due to a bug in WSL 2.7.8.0. Affecting KVM & AMD CPU devices. WSL 2.7.9 should be available shortly to mitigate this issue. Errors seen: Error code: Wsl/InstallDistro/Service/RegisterDistro/CreateVm/0x800705b4 Error code: Wsl/InstallDistro/0x80072eff Failure, expected Distro: Ubuntu-24.04. No Distros found. The same errors will be seen when running 'wsl --install' which defaults to downloading Ubuntu. https://github.com/microsoft/WSL/issues/40783Reminder: Intune-managed Win32 app delivery will be HTTPS-only, affecting Connected Cache customers
Starting today, Intune will be enforcing HTTPS-only delivery for managed Win32 app content Why this matters for Connected Cache customers: if HTTPS isn't configured on your cache nodes, clients that previously pulled Intune Win32 app content through Connected Cache can still download content, but those requests bypass cache nodes and fall back to CDN. This behavior can increase internet egress and bandwidth usage. This enforcement was previously announced in February via Message Center and the Intune Tech Community blog: How to enable HTTPS support for Microsoft Connected Cache for Enterprise and Education. Get started with the following documentation: Configure HTTPS on your cache nodes HTTPS setup on Windows HTTPS setup on Linux Validate HTTPS functionality Validate HTTPS on Windows Validate HTTPS on Linux Additionally, you can verify Intune Win32 HTTPS enforcement on a client machine Open C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload.log. Find log entries that include the app download URL for the app assignment you are validating. Confirm the URL is HTTPS (for example, starts with https://). Optionally correlate with Delivery Optimization status to verify whether bytes are being served from cache versus CDN. Configuration Manager customers If you're using Configuration Manager distribution points with Connected Cache, review and apply the published hotfix and prerequisites: Connected Cache update for Microsoft Configuration Manager versions 2409, 2503, and 2509 (KB33247081). If you'd find it useful, reply in this thread and we can also post a step-by-step TLS setup walkthrough video for the Connected Cache community.Large Intune Win32 apps don't seem to cache
I was hoping to see one of our MCC's cache some large Intune Win32 app packages. One is around 28GB and a couple of others are around 18GB. This is within Intune's Win32 app size limit. It's for a self-deploying Autopilot build and these are large sets of maps and documents. All packages deploy accurately given the download time needed. We have 700 to build. The Internet service available at build sites is not really sufficient. An MCC seemed like the perfect solution. Unfortunately, there is apparent evidence that the packages are not being cached. Not only do they not appear to register in the metrics, each device takes all day to build. Obviously, the more we try to do at once, the worse it gets. Here is a screenshot of the metrics for the last 30 days: This cache is dedicated to our PC Build Room's VLAN subnet. As you can see, Intune content only seems to account for 1.99GB when it should be much more than this. The MCC is 300GB in size. Being able to diagnose why the MCC is not caching these Win32 app packages would be extremely useful. Is it our infrastructure or something else? I have an open support case and also posted about it in the MCCP. Microsoft reps advised that MCC should be able to support these packages.
Question regarding update requests on the MCC node
So, as I have understood it, the MCC requires an update request to be requested 3 times by different devices before it actually starts to download it to cache it. 1. How many downloads does the MCC node download at the same time? 2. Does the MCC node keep a que list? 3. Does an update request ever "time out" on the MCC node or is it kept forever until reaching 3? What we have seen on the lab with 10 laptops, it is struggling to get more than 20% updates distributed from the MCC node. We re-install the laptops with the same USB installer multiple times when Windows reports it to be updated, so all of them are installed on the same build level every time. 4. How many times do we need to "re-install" windows until all updates are cached?Check cache status on MCC node
Is it posssible to check/monitor the amount of data the MCC node has cached? Since the MCC downloads updates only when requested 3x by the clients, it would be good to know how much % of an update is actually cached. This would give the most value when troubleshooting the MCC and the distribution of updates. We have configured a MCC in our LAB with 10 connected clients, and the amount of data shared varies too much for each client.
MCC Container missing mount points - unable to get CSR
MCC for Enterprise installed on Server 2022 I have around 20 nearly identical servers set up with MS Connected Cache, but two of them refuse to deploy the container in a fully operational state. Everything works perfectly fine over port 80. However, when I run the generateCSR.ps1 script, it fails. After digging around for quite a while, I found that the mount point inside the container is missing. This means that although the CSR is being generated, it can't send it back to Ubuntu and then to Windows. Running the 'docker inspect MCC' command yields this result: But, it's supposed to look like this: Apparently, you can't just add a mount point to the container. It has to be removed and redeployed with the mount point specified. However, I'm not able to figure out any way of doing that since the script seems to be deploying the container in a way that it generates the configuration file when running the deployment script instead of me being able to modify it for the deployment. I'm at a bit of a loss as to how to fix this or why it's even happening. I've already tried ripping everything out, including WSL and Hyper-V, and redeploying, with no success. Thoughts?Air-Gap System Deployment
Everything I've read indicated that MCC must be deployed on an Internet connected system. However, Microsoft Copolite said it can be deployed on an air-gap (i.e. closed, non-Internet facing) system and to use the pre-seeding tool to download contents. My main interest is to use MCC to assist with future Windows OS upgrade and (secondary) patching on my closed network. I currently pull-down patches via a connected WSUS and then sneakernet them over to the WSUS servers on our closed networks. Has anyone successfully deployed MCC in an air-gap environment and operating as intended? Any lessons learned? Thanks in advance.Cache server hostname source & LocalPolicyMerge setting
hi In our organization we have the LocalPolicyMerge setting set to false thus blocking all standard or custom locally created inbound MDE firewall rule. Outbound does not have any such restriction. We do see that the clients does not receive OptionID235 value from DHCP server. We did see a note in the Microsoft documentation [Delivery Optimization reference] been called out for this, but with less information on what is the configuration or setting that gets blocked. If the LocalPolicyMerge setting is configured, such as part of security baselines, it can impact DHCP client and prevent it from retrieving this DHCP option, especially in Autopilot scenarios. Does anyone have the same issue and what are the rules that were created to have this working? Thank you.generateCsr.sh failing
Hi, I'm trying to run ./generateCsr.sh to generate a CSR, but it is failing with the following errors: [2025-08-18 09:27:23] [GENERATE-CSR-BASH-SCRIPT] - Executing docker command: docker exec MCC bash -lc "source /tls/call-csr-endpoint.sh 'RSA' '2048' 'srv1_csr_20250818_092719' '<SUBJECT>' '<SAN>'" [2025-08-18 09:27:23] [GENERATE-CSR-BASH-SCRIPT] - bash: /root/.bash_profile: Permission denied <snip> [2025-08-18 09:27:25] [GENERATE-CSR-BASH-SCRIPT] - mkdir: cannot create directory '/keys': Permission denied [2025-08-18 09:27:25] [GENERATE-CSR-BASH-SCRIPT] - chmod: cannot access '/keys': No such file or directory [2025-08-18 09:27:25] [GENERATE-CSR-BASH-SCRIPT] - /tls/call-csr-endpoint.sh: line 159: netstat: command not found [2025-08-18 09:27:25] [GENERATE-CSR-BASH-SCRIPT] - CSR script completed successfully [2025-08-18 09:27:25] [GENERATE-CSR-BASH-SCRIPT] - windowsCerts directory does not exist, CSR generated directly in certs directory [2025-08-18 09:27:25] [GENERATE-CSR-BASH-SCRIPT] - ERROR: CSR file not found at expected location: /var/mcc/certs/certs/srv1_csr_20250818_092719.csr MCC software version 2.0.0.2112_e I've tried both Ubuntu 24.04 and Alma Linux 8. No CSR is generated Any ideas?
