Closed jordanmills closed 6 years ago
Thanks for the feedback! We are currently investigating and will update you shortly.
@jordanmills are you saying when installing for Azure Government, you need to manually edit the Registry?
@jason-j-MSFT Yes. Or, actually, I couldn't find an effective way to do it with registry edits. I think it had something to do with improperly replicating either the WS key or the certificate thumbprint, but I haven't had the time to test that in detail. I did find that I was able to make the agent communicate by removing existing workspaces (by deleting the registry key "hklm:\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\Service Connector Services" and its children) then using the AgentConfigManager.MgmtSvcCfg COM interface to add the OMS workspace programmatically:
$mma = New-Object -ComObject 'AgentConfigManager.MgmtSvcCfg';
$mma.AddCloudWorkspace($WorkspaceGuid,$WorkspaceApiKey,1)
In most of the cases I attempted, it was an upgrade of MMA from 7.1.10184.0 (updated to SCOM 2012 R2 UR14 by KB4024942, with no OMS workspaces added) to 8.0.11103.0, on both Windows Server 2012 R2 and Windows Server 2016.
Thinking about it, I should probably also try to uninstall MMA 7.1.x, restart the computer, and then try installing MMA 8.0.x specifying the ws, key, and cloud type.
@MGoedtel this issue may be a bug in the procedure in the installation of the Log Analytics agent for Azure US Government.
@jason-j-MSFT and @jordanmills - The documentation is correct in demonstrating how to configure the agent to report to a LA workspace when not in a multi-homed scenario (meaning agent reporting to both OpsMgr and LA workspace). Attempting to configure the agent to report to a LA workspace does not work on an upgrade scenario of the agent, only when doing a reconfiguration of the agent or installation of the agent.
Thank, it might help someone else save a lot of time and troubleshooting. I did confirm that it works as expected when there is no agent or residual configuration, which is probably no surprise.
This agent was deployed to a pilot group, and the computers never showed up in the OMS workspace. Investigation of the event logs showed an error in the operations manager event log with event ID 4000 and message (identities removed): "DNS resolution of the service name [guid].oms.opinsights.azure.com failed. Please check that the computer has Internet access or that a HTTP proxy has been configured for the system. The query will be retried later. The article KB3126513 has additional troubleshooting information for connectivity issues.
URL for Operation: https://[guid].oms.opinsights.azure.com/AgentService.svc/AgentTopologyRequest Proxy Host: "
Following are the settings used to deploy the agent:
USE_SETTINGS_FROM_AD=0 USE_MANUALLY_SPECIFIED_SETTINGS=1 NOAPM=0 AcceptEndUserLicenseAgreement=1 MANAGEMENT_SERVER_DNS=[scomserver] MANAGEMENT_GROUP=HCSCOM SECURE_PORT=5723 ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_ID=[guid] OPINSIGHTS_WORKSPACE_KEY=[key] OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE=1
It looks like it was deployed with URLs ending in .com, despite it being deployed for a government cloud tenant. It looks like I can manually edit the URL in the registry at "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\Service Connector Services\Log Analytics - [guid]" to correct the URL, but that gets pretty tedious. If I do that, it seems to communicate fine with the OMS workspace.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.