.

🧩 When a Security Policy Breaks Exchange Installation: WinRM Troubles Uncovered

Some time ago, one of my clients faced the challenge of migrating to Exchange 2019 from earlier versions. The migration and installation plan were in place, and a clean OS was installed on the new servers – everything seemed straightforward. However, as is often the case, installations in a production environment don’t always go as smoothly as they do in a test environment, especially when there are specific configurations unique to the production setup. Typically, any unexpected behavior has a logical explanation that just needs to be uncovered.

During the installation of the first server, we encountered an issue with the stopping and starting of the WinRM service. We were able to continue the installation (which is usually possible if the issue is temporary), but the installer’s subsequent behavior was quite unusual. Moreover, the initial error reoccurred on another server.

The following error was generated when “$error.Clear();

configure-WSManIISHosting -EnableKerberosModule;

” was run:

“System.InvalidOperationException: Running the command ‘C:\Windows\system32\net.exe start winrm’ failed.

Output

message: The service is starting or stopping. Please try again later.

Here, the competence of the client’s engineers and their deep understanding of their infrastructure were crucial. Revisiting the specific error, they decided to experiment by manually stopping and restarting the WinRM service. Indeed, they were able to replicate the problem of the service’s slow start and stop times.

Fortunately, we didn’t have to delve too deeply into the issue, as the client recalled that some time ago, at the request of the information security department, a policy was implemented to forward event logs to a windows event collector server (Windows Event Collection). For more information you can read this https://learn.microsoft.com/en-us/advanced-threat-analytics/configure-event-collection

🔎 Disabling this policy resolved the issue with the slow WinRM startup, and, as a result, the installation problem was also resolved.

Interestingly, this policy had been applied to already installed servers of previous versions without causing any issues. However, it’s important to note that the installation process cannot be directly compared to the operation of an already installed product, especially when the OS version is significantly different. In managing systems, it is crucial to understand the specific configurations and atypical settings that can potentially affect the operation of these systems. This knowledge significantly reduces problem resolution time and administrative costs.

End.


Leave a comment