Install Winrm Windows Server 2019
Rebbeca Schulke
The command winrm quickconfig creates a firewall exception only for the current user profile. If the firewall profile is changed for any reason, then to enable the firewall exception for the new profile, run winrm quickconfig (otherwise the exception might not be enabled).
Set up a trusted hosts list when mutual authentication can't be established. Kerberos allows mutual authentication, but it can't be used in workgroups; only domains. A best practice when setting up trusted hosts for a workgroup is to make the list as restricted as possible.
Specifies a URL prefix on which to accept HTTP or HTTPS requests. This string contains only the characters a-z, A-Z, 9-0, underscore (_), and slash (/). The string must not start with or end with a slash (/). For example, if the computer name is SampleMachine, then the WinRM client would specify in the destination address. The default URL prefix is wsman.
Specifies the thumbprint of the service certificate. This value represents a string of two-digit hexadecimal values found in the Thumbprint field of the certificate. This string contains the SHA-1 hash of the certificate. Certificates are used in client certificate-based authentication. Certificates can be mapped only to local user accounts. They don't work with domain accounts.
Many of the configuration settings, such as MaxEnvelopeSizekb or SoapTraceEnabled, determine how the WinRM client and server components interact with the WS-Management protocol. The following sections describe the available configuration settings.
Allows the client computer to use Basic authentication. Basic authentication is a scheme in which the user name and password are sent in clear text to the server or proxy. This method is the least secure method of authentication. The default is True.
Allows the client to use Digest authentication. Digest authentication is a challenge-response scheme that uses a server-specified data string for the challenge. Only the client computer can initiate a Digest authentication request.
The client computer sends a request to the server to authenticate, and receives a token string from the server. Then the client computer sends the resource request, including the user name and a cryptographic hash of the password combined with the token string.
Digest authentication is supported for HTTP and for HTTPS. WinRM Shell client scripts and applications can specify Digest authentication, but the WinRM service doesn't accept Digest authentication. The default is True.
Allows the client to use client certificate-based authentication. Certificate-based authentication is a scheme in which the server authenticates a client identified by an X509 certificate. The default is True.
The server determines whether to use the Kerberos protocol or NT LAN Manager (NTLM). The Kerberos protocol is selected to authenticate a domain account. NTLM is selected for local computer accounts. The user name must be specified in domain\user_name format for a domain user. The user name must be specified in server_name\user_name format for a local user on a server computer. The default is True.
Allows the client to use Credential Security Support Provider (CredSSP) authentication. CredSSP enables an application to delegate the user's credentials from the client computer to the target server. The default is False.
Specifies the maximum number of users who can concurrently perform remote operations on the same computer through a remote shell. If new remote shell connections exceed the limit, the computer rejects them. The default is 5.
Specifies the maximum number of concurrent shells that any user can remotely open on the same computer. If this policy setting is enabled, the user won't be able to open new remote shells if the count exceeds the specified limit. If this policy setting is disabled or isn't configured, the limit is set to five remote shells per user by default.
WinRM isn't dependent on any other service except WinHttp. If the IIS Admin Service is installed on the same computer, then you might see messages that indicate that WinRM can't be loaded before Internet Information Services (IIS). However, WinRM doesn't actually depend on IIS. Those messages occur because the load order ensures that the IIS service starts before the HTTP service. WinRM requires that WinHTTP.dll is registered.
If two listener services with different IP addresses are configured with the same port number and computer name, then WinRM listens or receives messages on only one address. This approach used is because the URL prefixes used by the WS-Management protocol are the same.
If the baseboard management controller (BMC) resources appear in the system BIOS, then ACPI (Plug and Play) detects the BMC hardware, and automatically installs the IPMI driver. Plug and Play support might not be present in all BMCs. If the BMC is detected by Plug and Play, then an Unknown Device appears in Device Manager before the Hardware Management component is installed. When the driver is installed, a new component, the Microsoft ACPI Generic IPMI Compliant Device, appears in Device Manager.
If your system doesn't automatically detect the BMC and install the driver, but a BMC was detected during the setup process, create the BMC device. To create the device, type the following command at a command prompt:
The IPMI provider places the hardware classes in the root\hardware namespace of WMI. For more information about the hardware classes, see IPMI Provider. For more information about WMI namespaces, see WMI architecture.
Beginning with Windows 8 and Windows Server 2012, WMI plug-ins have their own security configurations. For a normal or power user, not an administrator, to be able to use the WMI plug-in, enable access for that user after the listener has been configured. Set up the user for remote access to WMI through one of these steps.
After setting up the user for remote access to WMI, you must set up WMI to allow the user to access the plug-in. To allow access, run wmimgmt.msc to modify the WMI security for the namespace to be accessed in the WMI Control window.
With Ansible you can generally manage Windows versions under the current and extended support from Microsoft. You can also manage desktop OSs including Windows 10 and 11, and server OSs including Windows Server 2016, 2019, and 2022.
The script determines what programs you need to install (such as .NET Framework 4.5.2) and what PowerShell version needs to be present. If a reboot is needed and the username and password parameters are set, the script will automatically reboot the machine and then logon. If the username and password parameters are not set, the script will prompt the user to manually reboot and logon when required. When the user is next logged in, the script will continue where it left off and the process continues until no moreactions are required.
On PowerShell v3.0, there is a bug that limits the amount of memory available to the WinRM service. Use the Install-WMF3Hotfix.ps1 script to install a hotfix on affected hosts as part of the system bootstrapping or imaging process. Without this hotfix, Ansible fails to execute certain commands on the Windows host.
You need to configure the WinRM service so that Ansible can connect to it. There are two main components of the WinRM service that govern how Ansible can interface with the Windows host: the listener and the service configuration settings.
In the example above there are two listeners activated. One is listening on port 5985 over HTTP and the other is listening on port 5986 over HTTPS. Some of the key options that are useful to understand are:
CertificateThumbprint: If you use an HTTPS listener, this is the thumbprint of the certificate in the Windows Certificate Store that is used in the connection. To get the details of the certificate itself, run this command with the relevant certificate thumbprint in PowerShell:
Using winrm quickconfig for HTTP or winrm quickconfig -transport:https for HTTPS. This is the easiest option to use when running outside of a domain environment and a simple listener is required. Unlike the other options, this process also has the added benefit of opening up the firewall for the ports required and starting the WinRM service.
Using Group Policy Objects (GPO). This is the best way to create a listener when the host is a member of a domain because the configuration is done automatically without any user input. For more information on group policy objects, see the Group Policy Objects documentation.
The Keys object is an array of strings, so it can contain different values. By default, it contains a key for Transport= and Address= which correspond to the values from the winrm enumerate winrm/config/Listeners command.
Service\AllowUnencrypted - specifies whether WinRM will allow HTTP traffic without message encryption. Message level encryption is only possible when the ansible_winrm_transport variable is ntlm, kerberos or credssp. By default, this is false and you should only set it to true when debugging WinRM messages.
Service\Auth\CbtHardeningLevel - specifies whether channel binding tokens are not verified (None), verified but not required (Relaxed), or verified and required (Strict). CBT is only used when connecting with NT LAN Manager (NTLM) or Kerberos over HTTPS.
Service\CertificateThumbprint - thumbprint of the certificate for encrypting the TLS channel used with CredSSP authentication. By default, this is empty. A self-signed certificate is generated when the WinRM service starts and is used in the TLS process.
If you run the command in a domain environment, some of these options are set byGPO and cannot be changed on the host itself. When you configure a key with GPO, it contains the text [Source="GPO"] next to the value.
If running over HTTP and not HTTPS, use ntlm, kerberos or credssp with the ansible_winrm_message_encryption: auto custom inventory variable to enable message encryption. If you use another authentication option, or if it is not possible to upgrade the installed pywinrm package, you can set Service\AllowUnencrypted to true. This is recommended only for troubleshooting.
4a15465005