Windows Server 2012 R2 is a 64-bit–only operating system. In this book, I refer to 64-bit systems designed for the x64 architecture as 64-bit systems. Because the various server editions support the same core features and administration tools, you can use the techniques discussed in this book regardless of which Windows Server 2012 R2 edition you’re using.

When you install a Windows Server 2012 R2 system, you configure the system according to its role on the network, as the following guidelines describe:

Windows 8.1 and Windows Server 2012 R2 also support a workplace configuration. A workplace is a loose association of computers that grants access to certain internal network resources and business apps. Workplaces have specific benefits:

You implement workplaces by installing the Windows Server Essentials Experience role on servers running Windows Server 2012 R2. Because the Windows Server Essentials Experience role is designed to be used in single-domain deployments of Active Directory Domain Services (AD DS), you should not deploy this role in AD DS implementations with multiple domains.

Windows 8.1 and Windows Server 2012 R2 also support Work Folders, a similar but distinctly different feature. Work Folders allow users to synchronize their corporate data to their devices and vice versa. Those devices can be joined to the corporate domain or a workplace. To deploy Work Folders, the administrator adds the File And Storage ServicesFile and iSCSI ServicesWork Folders role service to a server and then configures Work Folders by using Server Manager. Unlike workplaces, Work Folders can be used in multidomain environments.

Windows Server 2012 R2 uses a Start screen. Start is a window, not a menu. Programs can have Tiles on the Start screen. Tapping or clicking a Tile runs the program. When you press and hold or right-click on a program, an options panel usually is displayed. The charms bar is an options panel for Start, Desktop, and PC Settings. With a touch UI, you can display the charms by sliding in from the right side of the screen. With a mouse and keyboard, you can display the charms by pointing to the hidden button in the upper-right or lower-right corner of the Start, Desktop, or PC Settings screen; or by pressing Windows key+C.

Tap or click the Search charm to display the Search panel. Any text entered while on the Start screen is entered into the Search box in the Search panel. The search box can be focused on Everywhere, Settings, or Files. When focused on Everywhere, you can use Search to quickly find installed programs, settings, and files. When focused on Settings, you can use Search to quickly find settings and options in Control Panel. When focused on Files, you can use Search to quickly find files.

One way to quickly open a program is by typing the file name of the program, and then pressing Enter. This shortcut works as long as the Everywhere search box is in focus (which it typically is by default). In an Everywhere search, any matches for programs are listed first, followed by any matches for settings and finally, any matches for files.

Pressing the Windows key toggles between the Start screen and the desktop (or, if you are working with PC Settings, between Start and PC Settings). On Start, there’s a Desktop Tile that you can tap or click to display the desktop. You also can display the desktop by pressing Windows key+D or, to peek at the desktop, press and hold Windows key+Comma. From Start, you access Control Panel by tapping or clicking the Control Panel Tile. From either Start or the desktop, you can display Control Panel by pressing Windows key+I and then clicking the Control Panel option. Additionally, because File Explorer is pinned to the desktop taskbar by default, you typically can access Control Panel on the desktop by following these steps:

Start and Desktop have a convenient menu that you can display by right-clicking the lower-left corner of the Start screen or the desktop. Alternatively, you can press Windows key+X. Options on the menu include Computer Management, Device Manager, Event Viewer, System, Task Manager, Windows Command Prompt, and Command Prompt (Admin). On the Start screen, the button in the lower-left corner shows a Windows icon, and tapping or clicking the thumbnail opens the desktop. On the desktop, tapping or clicking this button opens Start. Right-clicking the button is what displays the shortcut menu.

Shut Down and Restart are options of Power settings now. This means to shut down or restart a server, you follow these steps:

Alternatively, if configured as a power option, you can press the server’s physical power button to initiate an orderly shutdown by logging off and then shutting down. If you are using a desktop-class system and the computer has a sleep button, the sleep button is disabled by default, as are closing the lid options for portable computers. Additionally, servers are configured to turn off the display after 10 minutes of inactivity.

Windows 8.1 and Windows Server 2012 R2 support the Advanced Configuration and Power Interface (ACPI) 5.0 specification. Windows uses ACPI to control system and device power state transitions, putting devices in and out of full-power (working), low-power, and off states to reduce power consumption.

The power settings for a computer come from the active power plan. You can access power plans in Control Panel by tapping or clicking System And Security and then tapping or clicking Power Options. Windows Server 2012 R2 includes the Power Configuration (Powercfg.exe) utility for managing power options from the command prompt. At a command prompt, you can view the configured power plans by entering powercfg /l. The active power plan is marked with an asterisk.

The default, active power plan in Windows Server 2012 R2 is called Balanced. The Balanced plan is configured to do the following:

The sharing and discovery configuration in Network And Sharing Center controls basic network settings. When network discovery settings are turned on and a server is connected to a network, the server can see other network computers and devices and is visible on the network. When sharing settings are turned on or off, the various sharing options are allowed or restricted.

In Windows 8.1 and Windows Server 2012 R2, networks are identified as one of the following network types:

These network types are organized into three categories: private, domain, and public. Each network category has an associated network profile. Because a computer saves sharing and firewall settings separately for each network category, you can use different block and allow settings for each network category. When you connect to a network, a dialog box is displayed in which you can specify the network category. If you select Private, and the computer determines that it is connected to the corporate domain to which it is joined, the network category is set as Domain Network.

Based on the network category, Windows Server configures settings that turn discovery on or off. The On (enabled) state means that the computer can discover other computers and devices on the network and that other computers on the network can discover the computer. The Off (disabled) state means that the computer cannot discover other computers and devices on the network and that other computers on the network cannot discover the computer.

Using Advanced Sharing Settings in Network And Sharing Center, you can enable discovery and file sharing. However, discovery and file sharing are blocked by default on a public network, which enhances security by preventing computers on the public network from discovering other computers and devices on that network. When discovery and file sharing are disabled, files and printers you have shared from a computer cannot be accessed from the network. Additionally, some programs might not be able to access the network.

To allow a server to access a network, you must install TCP/IP networking and a network adapter. Windows Server uses TCP/IP as the default wide area network (WAN) protocol. Normally, networking is installed during installation of the operating system. You can also install TCP/IP networking through local area connection properties.

The TCP and IP protocols make it possible for computers to communicate across various networks and the Internet by using network adapters. Windows 7 and later releases of Windows have a dual IP-layer architecture in which both Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) are implemented and share common transport and network layers. IPv4 has 32-bit addresses and is the primary version of IP used on most networks, including the Internet. IPv6, alternatively, has 128-bit addresses and is the next-generation version of IP.

IPv4’s 32-bit addresses are commonly expressed as four separate decimal values, such as 127.0.0.1 or 192.168.10.52. The four decimal values are referred to as octets because each represents 8 bits of the 32-bit number. With standard unicast IPv4 addresses, a variable part of the IP address represents the network ID, and a variable part of the IP address represents the host ID. A host’s IPv4 address and its media access control (MAC) address used by the host’s network adapter have no correlation.

IPv6’s 128-bit addresses are divided into eight 16-bit blocks delimited by colons. Each 16-bit block is expressed in hexadecimal form, such as FEC0:0:0:02BC:FF:BECB:FE4F:961D. With standard unicast IPv6 addresses, the first 64 bits represent the network ID, and the last 64 bits represent the network interface. Because many IPv6 address blocks are set to 0, a contiguous set of 0 blocks can be expressed as “::”, a notation referred to as double-colon notation. Using double-colon notation, the two 0 blocks in the previous address can be compressed as FEC0::02BC:FF:BECB:FE4F:961D. Three or more 0 blocks would be compressed in the same way. For example, FFE8:0:0:0:0:0:0:1 becomes FFE8::1.

When networking hardware is detected during installation of the operating system, both IPv4 and IPv6 are enabled by default; you don’t need to install a separate component to enable support for IPv6. The modified IP architecture in Windows 7 and later releases of Windows is referred to as the Next Generation TCP/IP stack, and it includes many enhancements that improve the way IPv4 and IPv6 are used.

For Windows 8.1 and Windows Server 2012 R2, Group Policy Preferences have been updated to support IPv6 addresses for TCP/I Printers and VPN connections. Item-level Targeting options also allow you to configure IPv6 address ranges.

For traffic routing between virtual and physical networks, Windows Server 2012 R2 includes Windows Server Gateway, which is integrated with Hyper-V Network Virtualization. You can use Windows Server Gateway to route network traffic regardless of where resources are located, allowing you to support integration of public and private cloud services with your internal networks in addition to multitenant implementations with Network Address Translation (NAT) and virtual private network (VPN) connections.

Windows Server 2012 R2 supports a multimaster replication model. In this model, any domain controller can process directory changes and then replicate those changes to other domain controllers automatically. Windows Server distributes an entire directory of information, called a data store. Inside the data store are sets of objects representing user, group, and computer accounts in addition to shared resources such as servers, files, and printers.

Domains that use Active Directory are referred to as Active Directory domains. Although Active Directory domains can function with only one domain controller, you can and should configure multiple domain controllers in the domain. This way, if one domain controller fails, you can rely on the other domain controllers to handle authentication and other critical tasks.

Microsoft changed Active Directory in several fundamental ways for the original release of Windows Server 2008. As a result, Microsoft realigned the directory functionality and created a family of related services, including the following:

Microsoft introduced additional changes in Windows Server 2012 R2. These changes include a new domain functional level, called Windows Server 2012 R2 domain functional level, and a new forest functional level, called Windows Server 2012 R2 forest functional level. The many other changes are discussed in Chapter 7

Windows Server 2008 and later releases support read-only domain controllers (RODCs) and restartable AD DS. An RODC is an additional domain controller that hosts a read-only replica of a domain’s Active Directory data store. RODCs are ideally suited to the needs of branch offices, where a domain controller’s physical security cannot be guaranteed. Except for passwords, RODCs store the same objects and attributes as writable domain controllers. These objects and attributes are replicated to RODCs through unidirectional replication from a writable domain controller that acts as a replication partner.

Because RODCs by default do not store passwords or credentials other than for their own computer account and the Kerberos Target (Krbtgt) account, RODCs pull user and computer credentials from a writable domain controller that is running Windows Server 2008 or later. If allowed by a password replication policy that is enforced on the writable domain controller, an RODC retrieves and then caches credentials as necessary until the credentials change. Because only a subset of credentials is stored on an RODC, this limits the number of credentials that can possibly be compromised.

Restartable AD DS is a feature that allows an administrator to start and stop AD DS. In the Services console, the Active Directory Domain Services service is available on domain controllers, allowing you to easily stop and restart AD DS in the same way as for any other service that is running locally on the server. While AD DS is stopped, you can perform maintenance tasks that would otherwise require restarting the server, such as performing offline defragmentation of the Active Directory database, applying updates to the operating system, or initiating an authoritative restore. While AD DS is stopped on a server, other domain controllers can handle authentication and logon tasks. Cached credentials, smart cards, and biometric logon methods continue to be supported. If no other domain controller is available and none of these logon methods applies, you can still log on to the server by using the Directory Services Restore Mode account and password.

All domain controllers running Windows Server 2008 or later support restartable AD DS—even RODCs. As an administrator, you can start or stop AD DS by using the Domain Controller entry in the Services utility. Because of restartable AD DS, domain controllers running Windows Server 2008 or later have three possible states:

When working with AD DS in the Stopped state, you should keep in mind that dependent services are also stopped when you stop AD DS. This means that File Replication Service (FRS), Kerberos Key Distribution Center (KDC), and Intersite Messaging are stopped before Active Directory is stopped, and that even if they are running, these dependent services are restarted when Active Directory restarts. Further, you can restart a domain controller in Directory Services Restore Mode, but you cannot start a domain controller in the Active Directory Stopped state. To get to the Stopped state, you must first start the domain controller in the customary way and then stop AD DS.

DNS is a name-resolution service that resolves computer names to IP addresses. Using DNS, the fully qualified host name computer84.cpandl.com, for example, can be resolved to an IP address, which allows it and other computers to find one another. DNS operates over the TCP/IP protocol stack and can be integrated with WINS, Dynamic Host Configuration Protocol (DHCP), and Active Directory Domain Services.

DNS organizes groups of computers into domains. These domains are organized into a hierarchical structure, which can be defined on an Internet-wide basis for public networks or on an enterprise-wide basis for private networks (also known as intranets and extranets). The various levels within the hierarchy identify individual computers, organizational domains, and top-level domains. For the fully qualified host name computer84.cpandl.com, computer84 represents the host name for an individual computer, cpandl is the organizational domain, and com is the top-level domain.

Top-level domains are at the root of the DNS hierarchy; they are also called root domains. These domains are organized geographically, by organization type, and by function. Normal domains, such as cpandl.com, are also referred to as parent domains. They’re called parent domains because they’re the parents of an organizational structure. Parent domains can be divided into subdomains that can be used for groups or departments within an organization.

Subdomains are often referred to as child domains. For example, the fully qualified domain name (FQDN) for a computer within a human resources group could be jacob.hr.cpandl.com. Here, jacob is the host name, hr is the child domain, and cpandl.com is the parent domain.

Active Directory domains use DNS to implement their naming structure and hierarchy. Active Directory and DNS are tightly integrated, so much so that you should install DNS on the network before you install domain controllers that use Active Directory. During installation of the first domain controller on an Active Directory network, you’re given the opportunity to install DNS automatically if a DNS server can’t be found on the network. You are also able to specify whether DNS and Active Directory should be fully integrated. In most cases, you should respond affirmatively to both requests. With full integration, DNS information is stored directly in Active Directory. This allows you to take advantage of Active Directory’s capabilities.

The difference between partial integration and full integration is very important:

If you look at the way DNS information is replicated throughout the network, you can see more advantages to full integration with Active Directory. With partial integration, DNS information is stored and replicated separately from Active Directory. Having two separate structures reduces the effectiveness of both DNS and Active Directory and makes administration more complex. Because DNS is less efficient than Active Directory at replicating changes, you might also increase network traffic and the amount of time it takes to replicate DNS changes throughout the network.

To enable DNS on the network, you need to configure DNS clients and servers. When you configure DNS clients, you tell the clients the IP addresses of DNS servers on the network. Using these addresses, clients can communicate with DNS servers anywhere on the network, even if the servers are on different subnets.

When the network uses DHCP, you should configure DHCP to work with DNS. To do this, you need to set the DHCP scope options 006 DNS Servers and 015 DNS Domain Name. Additionally, if computers on the network need to be accessible from other Active Directory domains, you need to create records for them in DNS. DNS records are organized into zones; as mentioned earlier in this chapter, a zone is simply an area within a domain.

When you install the DNS Server service on an RODC, the RODC is able to pull a read-only replica of all application directory partitions that are used by DNS, including ForestDNSZones and DomainDNSZones. Clients can then query the RODC for name resolution as they would query any other DNS server. However, as with directory updates, the DNS server on an RODC does not support direct updates. This means that the RODC does not register name server (NS) resource records for any Active Directory–integrated zone that it hosts. When a client attempts to update its DNS records against an RODC, the server returns a referral to a DNS server that the client can use for the update. The DNS server on the RODC should receive the updated record from the DNS server that receives details about the update by using a special replicate-single-object request that runs as a background process.

Windows 7 and later releases add support for DNS Security Extensions (DNSSEC). The DNS client running on these operating systems can send queries that indicate support for DNSSEC, process related records, and determine whether a DNS server has validated records on its behalf. On Windows servers, this allows your DNS servers to securely sign zones and to host DNSSEC-signed zones. It also allows DNS servers to process related records and perform both validation and authentication.

WINS is a service that resolves computer names to IP addresses. Using WINS, the computer name COMPUTER84, for example, can be resolved to an IP address that enables computers on a Microsoft network to find one another and transfer information. WINS is needed to support pre–Windows 2000 systems and earlier applications that use NetBIOS over TCP/IP, such as the .NET command-line utilities. If you don’t have pre–Windows 2000 systems or applications on the network, you don’t need to use WINS.

WINS works best in client/server environments in which WINS clients send single-label (host) name queries to WINS servers for name resolution and WINS servers resolve the query and respond. When all your DNS servers are running Windows Server 2008 or later, deploying a Global Names zone creates static, global records with single-label names that do not rely on WINS. This allows users to access hosts by using single-label names rather than FQDNs and removes the dependency on WINS. To transmit WINS queries and other information, computers use NetBIOS. NetBIOS provides an application programming interface (API) that allows computers on a network to communicate. NetBIOS applications rely on WINS or the local LMHOSTS file to resolve computer names to IP addresses. On pre–Windows 2000 networks, WINS is the primary name resolution service available. On Windows 2000 and later networks, DNS is the primary name resolution service and WINS has a different function. This function is to allow pre–Windows 2000 systems to browse lists of resources on the network and to allow Windows 2000 and later systems to locate NetBIOS resources.

To enable WINS name resolution on a network, you need to configure WINS clients and servers. When you configure WINS clients, you tell the clients the IP addresses for WINS servers on the network. Using the IP addresses, clients can communicate with WINS servers anywhere on the network, even if the servers are on different subnets. WINS clients can also communicate by using a broadcast method through which clients broadcast messages to other computers on the local network segment that are requesting their IP addresses. Because messages are broadcast, the WINS server isn’t used. Any non-WINS clients that support this type of message broadcasting can also use this method to resolve computer names to IP addresses.

When clients communicate with WINS servers, they establish sessions that have the following three key parts:

After a client establishes a session with a WINS server, the client can request name-resolution services. The method used to resolve computer names to IP addresses depends on how the network is configured. The following four name-resolution methods are available:

If WINS servers are available on the network, Windows clients use the p-node method for name resolution. If no WINS servers are available on the network, Windows clients use the b-node method for name resolution. Windows computers can also use DNS and the local files LMHOSTS and HOSTS to resolve network names.

When you use DHCP to assign IP addresses dynamically, you should set the name resolution method for DHCP clients. To do this, you need to set DHCP scope options for the 046 WINS/NBT Node Type. The best method to use is h-node. You’ll get the best performance and reduce traffic on the network.

LLMNR fills a need for peer-to-peer name-resolution services for devices with an IPv4 address, an IPv6 address, or both, allowing IPv4 and IPv6 devices on a single subnet without a WINS or DNS server to resolve each other’s names—a service that neither WINS nor DNS can fully provide. Although WINS can provide both client/server and peer-to-peer name-resolution services for IPv4, it does not support IPv6 addresses. DNS, alternatively, supports IPv4 and IPv6 addresses, but it depends on designated servers to provide name-resolution services.

Windows 7 and later releases support LLMNR. LLMNR is designed for both IPv4 and IPv6 clients in configurations where other name-resolution systems are not available, such as the following:

LLMNR is designed to complement DNS by enabling name resolution in scenarios in which conventional DNS name resolution is not possible. Although LLMNR can replace the need for WINS in cases where NetBIOS is not required, LLMNR is not a substitute for DNS because it operates only on the local subnet. Because LLMNR traffic is prevented from propagating across routers, it cannot accidentally flood the network.

As with WINS, you use LLMNR to resolve a host name, such as COMPUTER84, to an IP address. By default, LLMNR is enabled on all computers running Windows 7 and later releases, and these computers use LLMNR only when all attempts to look up a host name through DNS fail. As a result, name resolution works like the following for Windows 7 and later releases:

You can also use LLMNR for reverse mapping. With a reverse mapping, a computer sends a unicast query to a specific IP address, requesting the host name of the target computer. An LLMNR-enabled computer that receives the request sends a unicast reply containing its host name to the originating host.

LLMNR-enabled computers are required to ensure that their names are unique on the local subnet. In most cases, a computer checks for uniqueness when it starts, when it resumes from a suspended state, and when you change its network interface settings. If a computer has not yet determined that its name is unique, it must indicate this condition when responding to a name query.

For additional flexibility in your command-line scripting, you might want to use Windows PowerShell. Windows PowerShell is a full-featured command shell that can use built-in commands called cmdlets, built-in programming features, and standard command-line utilities. A command console and a graphical environment are available.

Although the Windows PowerShell console and the graphical scripting environment are installed by default, several other Windows PowerShell features are not installed by default. They include the Windows PowerShell 2.0 engine, which is provided for backward compatibility with existing Windows PowerShell host applications, and Windows PowerShell Web Access, which lets a server act as a web gateway for managing the server remotely by using Windows PowerShell and a web client.

The Windows PowerShell console (Powershell.exe) is a 32-bit or 64-bit environment for working with Windows PowerShell at the command line. On 32-bit versions of Windows, you’ll find the 32-bit executable in the %SystemRoot%System32WindowsPowerShellv1.0 directory. On 64-bit versions of Windows, you’ll find the 32-bit executable in the %SystemRoot%SysWow64WindowsPowerShellv1.0 directory, and the 64-bit executable in the %SystemRoot%System32WindowsPowerShellv1.0 directory.

On the desktop, you can open the Windows PowerShell console by tapping or clicking the Windows PowerShell button on the taskbar. This option is included by default. On 64-bit systems, the 64-bit version of Windows PowerShell is started by default. If you want to use the 32-bit Windows PowerShell console on a 64-bit system, you must select the Windows PowerShell (x86) option.

You can start Windows PowerShell from a Windows command shell (Cmd.exe) by entering the following:

powershell

After starting Windows PowerShell, you can enter the name of a cmdlet at the prompt, and the cmdlet will run in much the same way as a command-line command. You can also execute cmdlets in scripts. Cmdlets are named by using verb-noun pairs. The verb tells you what the cmdlet does in general. The noun tells you what specifically the cmdlet works with. For example, the Get-Variable cmdlet gets all Windows PowerShell environment variables and returns their values, or it gets a specifically named environment variable and returns its value. The common verbs associated with cmdlets are as follows:

At the Windows PowerShell prompt, you can get a complete list of cmdlets by entering get-help *-*. To get Help documentation on a specific cmdlet, enter get-help followed by the cmdlet name, such as get-help get-variable. Windows PowerShell V3 and later use online and updatable Help files. Because of this, you might see only basic syntax for cmdlets and functions. To get full Help details, you’ll have to either use online Help or download the Help files to your computer. For online Help, add the -online option to your get-help command, as shown here:

get-help get-variable -online

Use the Update-Help cmdlet to download and install the current Help files from the Internet. Without parameters, Update-Help updates the Help files for all modules installed on the computer. However, Update-Help does the following:

You can override these restrictions by using the -Force parameter. You can save Help files to the local computer by using Save-Help.

All cmdlets also have configurable aliases that act as shortcuts for executing a cmdlet. To list all aliases available, enter get-alias at the Windows PowerShell prompt. You can create an alias that invokes any command by using the following syntax:

new-item –path alias:AliasName –value:FullCommandPath

Here AliasName is the name of the alias to create, and FullCommandPath is the full path to the command to run, such as the following:

new-item –path alias:sm –value:c:windowssystem32compmgmtlauncher.exe

This example creates the alias sm for starting Server Manager. To use this alias, you simply type sm and then press Enter when you are working with Windows PowerShell. It’s important to note that Windows PowerShell 3 and later versions automatically import required modules the first time you use a related command. With Windows PowerShell 2, you needed to explicitly import a module before you could run any of its commands.

The Windows PowerShell remoting features are supported by the WS-Management protocol and the Windows Remote Management (WinRM) service that implements WS-Management in Windows. Computers running Windows 8 and later, and also Windows Server 2012 or later, include WinRM 3.0 or later. If you want to manage a Windows server from a workstation, you need to be sure that WinRM 3.0 and Windows PowerShell are installed and that the server has a WinRM listener enabled. A Microsoft Internet Information Services (IIS) extension, installable as a Windows feature called WinRM IIS Extension, lets a server act as a web gateway for managing the server remotely by using WinRM and a web client.

winrm set winrm/config/client '@{TrustedHosts="RemoteComputer"}'

winrm set winrm/config/client '@{TrustedHosts="CorpServer56"}'

winrm quickconfig

WinRM already is set up to receive requests on this machine.
WinRM already is set up for remote management on this machine.

winrm set ConfigPath @{ParameterName="Value"}

winrm set winrm/config/winrs @{MaxShellsPerUser="10"}

LISTING 1-1 Sample configuration for listeners

Listener
    Address = *
    Transport = HTTP
    Port = 80
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 192.168.1.225

winrm create winrm/config/listener?Address=*+Transport=HTTP

winrm create winrm/config/listener?Address=*+Transport=HTTPS

winrm set winrm/config/listener?Address=IP:192.168.1.225+Transport=HTTP @{Enabled="true"}

winrm set winrm/config/listener?Address=IP:192.168.1.225+Transport=HTTP @{Enabled="false"}

winrm set winrm/config/client/auth @{Basic="true"}

winrm set winrm/config/client/auth @{Basic="false"}

winrm set winrm/config/client @{TrustedHosts="<local>"}

winrm set winrm/config/client @{TrustedHosts=""}