Forum Widgets
Latest Discussions
New shortcut file
hi Anyone noted a new file that gets downloaded / created called shortcut.ico when we trigger the installation of connected cache. This was seen only from past 2 weeks. This file is not available in the installer download location so i assume this is getting downloaded during installation and goes inside the installer folder. Double click or checking the path of this ico file doesnot showup anything useful to troubleshoot / checkI see "Failure: WSL MCC install failed with exception during installation, Return Code: 13631495"
If you hit this error, or other errors during the install on Windows, the MCC installer will write logs to the installation folder specified in the installation command (C:\mccwsl01\InstallLogs by default). Please inspect the installation logs for self-help. There are three types of log files that will be appended with the dat and time of they are written: WSL_Mcc_Install_Transcript This log file records the lines printed to the command prompt when running the installation script. This is where you will see the initial error which may not include all the details you need. WSL_Mcc_Install_FromRegisteredTask_Status This log file records the high-level status that is written during the registered tasks install WSL_Mcc_Install_FromRegisteredTask_Transcript This log file records the detailed status that is written during the registered tasks install. This log file will include the most detailed information of the install, including the installation details for the Linux portion of the install. WSL_Mcc_Monitor_FromRegisteredTask_Transcript The log file records "Monitor" scheduled task which ensures Connected Cache is running. Watch out for errors when passwords change. You'll need to update the user in this schedule task, all of them actually, when passwords change.
MCC Deployment Large Enterprises
Hello everyone, As dedicated fans of MCC, I’d like to share some challenges you might encounter when deploying MCC in conjunction with DHCP option 235. Below are key troubleshooting points and network considerations to help guide you through the process. Preliminary Troubleshooting Steps Before diving deeper, ensure you verify the following: Network Proxy: Confirm if your network uses a proxy, adjust the rules. TLS Inspection: Review and adjust TLS inspection rules by creating necessary exclusions. Firewall Policies: If Firewall Local Policy Merge is disabled for all clients, Create appropriate inbound rules for Delivery Optimization (DO) and inspect the firewall’s inbound logs on the client. Connectivity Test: Verify access to the MCC using a command, that is mentioned in the docs, from the client. For guidance, refer to Microsoft Documentation. PowerShell Check: Run Get-DeliveryOptimizationStatus to confirm that P2P is operational and that the MCC is properly recognized. Intune Policies: Double-check that your DO Intune policies are configured correctly. Network Deep Dive: DHCP Communication If the MCC server remains unreachable via DHCP Option 235 after the initial checks, it’s time to investigate further into your network setup. Standard DHCP Process Typically, DHCP communication occurs in four steps: DHCP Discover DHCP Offer DHCP Request DHCP ACK The DHCP ACK packet is where the client normally receives DHCP Option 235. Role of VLANs and DHCP Relay In large networks with multiple VLANs, an IP helper-address is used to set up a DHCP relay. Since DHCP broadcasts are limited to the local LAN, a DHCP relay intercepts the broadcast, converts it into a unicast request to the DHCP server on a different LAN, and then relays the unicast response (including the necessary DHCP options) back to the client. Introduction of DHCPINFORM In these scenarios, a fifth packet—DHCPINFORM—comes into play. This packet is sent by clients to obtain additional network configuration details (like DHCP Option 235) without needing to lease a new IP address. Identifying and Resolving Communication Breaks A potential issue arises when the DHCPINFORM request is either not forwarded by the firewall or core switch (which handles the IP helper function) or when the corresponding DHCP ACK response is blocked. In such cases, the client successfully obtains its IP address and basic DHCP options, but fails to receive Option 235, which is crucial for starting content downloads. So we where able to see the DHCPINFORM request but there was any response. The resolution involved investigating the firewall responsible for handling the IP helper function. Although the DHCP server correctly sent a DHCP ACK in response to the DHCPINFORM request, the firewall treated this as a new session and blocked it. Adjusting the firewall rules allowed the DHCP ACK to reach the client successfully. I hope these insights help you troubleshoot and achieve a seamless deployment of MCC with DHCP Option 235. If you have any questions or need further clarification, please feel free to reach out.Reminder: 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.
Waiting for MCC container to become available
Hi, Trying to setup Intune Connected Cache and getting stuck on MCC Install Waiting for MCC container to become available. running on Server 2022 VM with nested virtulization turned on and using a groupMSA account. I have set this up fine on one of our other domains\tenancy. Any ideas? Tried starting from scratch several times and not sure whats stopping it. Thanks Scott
Windows 11 :: Return Code: 13631746
Hi Trying to install Cache Node on Windows 11 and it fails with the below error: System.Management.Automation.RuntimeException: Failure: MCC failed to install during provisioning command line, please check install from registered task install logs to diagnose issue and retry, Return Code: 13631746 Checked the log "WSL_Mcc_Install_FromRegisteredTask_Transcript_01-13-2025_03-19-26.txt" and last few lines shared below Get:37 http://security.ubuntu.com/ubuntu jammy-security/multiverse amd64 c-n-f Metadata [224 B] Fetched 15.2 MB in 2s (7274 kB/s) Reading package lists... E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1934 (unattended-upgr) E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it? E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1934 (unattended-upgr) E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it? ./installiotedge.sh: line 352: /etc/docker/daemon.json: No such file or directory ./installiotedge.sh: line 353: /etc/docker/daemon.json: No such file or directory ./installiotedge.sh: line 355: /etc/docker/daemon.json: No such file or directory Failed to restart docker.service: Unit docker.service not found. Hit:1 https://packages.microsoft.com/ubuntu/22.04/prod jammy InRelease Hit:2 http://security.ubuntu.com/ubuntu jammy-security InRelease Hit:3 http://archive.ubuntu.com/ubuntu jammy InRelease Hit:4 http://archive.ubuntu.com/ubuntu jammy-updates InRelease Hit:5 http://archive.ubuntu.com/ubuntu jammy-backports InRelease Reading package lists... E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1934 (unattended-upgr) E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it? Rules updated Rules updated (v6) Rules updated Haven't faced this error in other installation done on the same type of configuration
