Forum Widgets
Latest Discussions
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.
Minor Improvement for v2
You might receive the below error during installation System.Management.Automation.RuntimeException: WSL MCC setup requires Hyper-V to be installed on this machine, please install Hyper-V and re-run installation : Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All The suggested fix only applies to Windows 11 installations. Windows server installs require the below command. All of this info is listed in the prerequisites but it might catch some people out. Install-WindowsFeature -Name Hyper-V -IncludeManagementTools
edgehub container not deploying
"MessageBody">Hello, We are currently trying to deploy Microsoft Connected cache for enterprise in public preview running on Windows. Installation is on Windows Server 2022 Standard and every time facing the same issue, edgeagent container is deployed correctly but edgehub or mcc containers are never deployed. When I run sudo iotedge check --verbose everything is checked correctly only with one exclusion: × production readiness: Edge Hub's storage directory is persisted on the host filesystem - Error Could not check current state of edgeHub container caused by: Could not check current state of edgeHub container caused by: docker returned exit status: 1, stderr = Error: No such object: edgeHub Which is caused by missing edgehub container. In edgeagent.log is occurring this warning: [Microsoft.Azure.Devices.Edge.Agent.Core.ConfigSources.BackupConfigSource] - Empty edge agent config was received. Attempting to read config from backup (/tmp/edgeAgent/backup.json) instead It seems to me that edgeagent connects to IOT Hub successfully but cannot find/download the deployment manifest and because of that will not even try to install edgehub and mcc container/module. I already tried deployment many times, even manually from the docker, verified firewall ACLs and no blocked communication is happening there. I also tried to switch from AMQP to HTTPS via proxy, but the state is still the same. Reprovision or restart also doesn't help.I 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.Welcome to the Connected Cache for Enterprise and Education Discussion Forum!
Hello All! Welcome to the new discussion board for Microsoft Connected Cache for Enterprise and Education! Here you can engage in conversations with your peers around configuration and deployment of cache nodes, Connected Cache CLI, reporting and monitoring, troubleshooting issues, post questions for our product team or other users of the product. We will have a separate "Ideas Board" where you can share ideas for the future of Connected Cache for Enterprise and Education. So look for this announcement coming soon. Thanks for being a part of our community!
