Outline:

1. Active Directory structure, creating GPOs.

2. Creating and issuing a new certificate template, obtaining a Public SSL

Authorization Certificate.

3. Accessing IPv6. Networking toolset. Creating a routing table.

4. Remote access on Windows Server

5. Interacting with the main server. WAC for managing core servers. Sconfig utility
Group Policy structure is modeled after the Active Directory structure, in that
it has both physical and logical components. At the core of Active Directory's
physical architecture is an extensible storage engine that reads and writes
information to the Active Directory data store. This engine makes use of the
logical, object-based hierarchy that represents data store information.

Group Policy structure is similar to that of Active Directory, because it

maintains both a logical and physical representation of GPOs, as follows:

Logical component: Consists of a Group Policy container object, which is

stored in the Group Policy Objects container of Active Directory. The Group
Policy container object contains attributes that specify basic GPO
information, such as the following:

• GPO display name

• GPO path to the extension policy and Group Policy template (GPT)
files.
• GPO version number
• GPO status
• Access control list (ACL)
• GUID-references to the CSEs that are to be invoked when the core
Group Policy engine on the Group Policy client processes the
GPO.

When the Group Policy administrator creates a GPO, Active Directory creates
a Group Policy container object for that GPO, as described in
section 2.1.3.2.1. This Group Policy container is a container object of the
groupPolicyContainer class and is named with a GUID that identifies the GPO.
The Group Policy container is stored under the CN=Policies,CN=System
container within the domain. The Administrative tool and the Group Policy
client locate this container according to its DN, which is the exact path to the
Group Policy container object in the Active Directory data store.

Physical component: Consists of the Group Policy file share component that
stores GPT and Group Policy extension settings on a domain controller or
other server.
The physical component of a GPO is represented through a series of files
containing Administrative template and extension policy settings that are
stored on disk. These files contain numerous policy settings along with the
state of these settings. These files are stored in Machine and User
subdirectories along with the associated GPO version file gpt.ini, in the
following path, which is also known as the GPO path: <dns domain
name>\<Group Policy file share-name>\<dns domain
name>\Policies\<guid>\.

Whenever the Group Policy administrator creates a new GPO, the <guid>
folder in this path is automatically created and named with the GUID of the
GPO. Within the <guid> folder are Machine and User subdirectories that
contain extension policy settings and Administrative template configuration
items. During policy administration, when the Group Policy administrator
creates or modifies Group Policy extension or Administrative template
settings, the Administrative tool locates the policy files according to the
<guid> in the GPO path. During policy application, the Group Policy client
locates the policy files in the same manner

Applies To: Windows Server 2012

To create a new GPO, use the Active Directory Users and Computers MMC
snap-in.

Administrative credentials

To complete this procedure, you must be a member of the Domain

Administrators group, or otherwise be delegated permissions to create new
GPOs.

To create a new GPO

1. On a computer that has the Group Policy Management feature

installed, click the Start charm, and then click the Group Policy
Management tile.
2. In the navigation pane, expand **Forest:**YourForestName,
expand Domains, expand YourDomainName, and then
click Group Policy Objects.
3. Click Action, and then click New.
4. In the Name text box, type the name for your new GPO.
Note Be sure to use a name that clearly indicates the purpose of the GPO.
Check to see if your organization has a naming convention for GPOs.

5. Leave Source Starter GPO set to (none), and then click OK.
6. If your GPO will not contain any user settings, then you can
improve performance by disabling the User
Configuration section of the GPO. To do this, perform these
steps:
1. In the navigation pane, click the new GPO.
2. In the details pane, click the Details tab.
3. Change the GPO Status to User configuration settings
disabled.

What is a Group Policy

Group policy can represent policy settings in the locally in the file system or
in Active Directory Domain Services. When used with Active Directory, Group
Policy settings are contained in a Group Policy Object (GPO). A GPO is a
virtual collection of policy settings, security permissions, and scope of
management (SOM) that you can apply to users and computers in Active
Directory. A GPO has a unique name, such as a GUID. Clients evaluate GPO
settings using the hierarchical nature of Active Directory.

Policy settings are divided into policy settings that affect a computer and
policy settings that affect a user. Computer-related policies specify system
behavior, application settings, security settings, assigned applications, and
computer startup and shutdown scripts. User-related policies specify system
behavior, application settings, security settings, assigned and published
applications, user logon and logoff scripts, and folder redirection. Computer
settings override user-related settings.

To create Group Policy, an administrator can use the Local Group Policy
Editor (gpedit.msc), which can be a stand-alone tool and the settings stored
locally. We recommend that you use the Group Policy Object Editor as an
extension to an Active Directory-related MMC snap-in. The Group Policy
Object Editor allows you to link GPOs to selected Active Directory sites,
domains, and organizational units (OUs). Linking applies the policy settings
in the GPO to the users and computers in those Active Directory objects.
GPOs are stored in both Active Directory and in the SYSVOL folder on each
domain controller.

How Group Policy works

For computers, Group Policy is applied when the computer starts. For users,
Group Policy is applied at sign in. This initial processing of policy can also be
referred to as a foreground policy application.

The foreground application of Group Policy can be synchronous or

asynchronous. In synchronous mode, the computer doesn't complete the
system start until computer policy is applied successfully. The user logon
process doesn't complete until user policy is applied successfully. In
asynchronous mode, if there are no policy changes that require synchronous
processing, the computer can complete the start sequence before the
application of computer policy is complete. The shell can be available to the
user before the application of user policy is complete. The system then
periodically applies (refreshes) Group Policy in the background. During a
refresh, policy settings are applied asynchronously.

To learn more about how Group Policies work, see Group Policy Processing.

What is an Organizational Unit (OU)

An OU is the lowest-level Active Directory container to which you can assign

Group Policy settings. Typically, you assign most GPOs at the OU level, so
make sure that your OU structure supports your Group Policy-based client-
management strategy. You might also apply some Group Policy settings at
the domain level, particularly password policies. Few policy settings are
applied at the site level. A well-designed OU structure that reflects the
administrative structure of your organization and takes advantage of GPO
inheritance simplifies the application of Group Policy. For example, a well-
designed OU structure can prevent duplicating certain GPOs so that you can
apply these GPOs to different parts of the organization. If possible, create
OUs to delegate administrative authority and to help implement Group
Policy.
n this article

1. Prerequisites
2. Download and Import the Root Certificate from the CA
3. Create a certificate template: Enterprise CAs
4. Request a certificate using a request file
Show 6 more

This article describes how to obtain a certificate and use with Operations
Manager Management Server, Gateway, or Agent using either a Stand-Alone
or Enterprise Active Directory Certificate Services (AD CS) Certificate
Authority (CA) server on the Windows platform.

• To request and accept a certificate, use the certreq command-line

utility. To submit and retrieve a certificate, use a web interface.

Prerequisites

Ensure you've the following:

•AD-CS installed and configured in the environment with web

services or a third party Certificate Authority with certificates that
match the required settings shown.
• HTTPS binding and its associated certificate installed. For
information about creating an HTTPS binding, see How to
Configure an HTTPS Binding for a Windows Server CA.
• A typical desktop experience and not Core servers.
Important

Cryptography API Key Storage Provider (KSP) is not supported for Operations
Manager certificates.

Note
If your organization doesn't use AD CS or uses an external certificate
authority, use the instructions provided for that application to create a
certificate and ensure it meets the following requirements for Operations
Manager, and then follow the Import and Installation steps provided:

Copy
- Subject="CN=server.contoso.com" ; (this should be the FQDN or how the
system shows in DNS)

- [Key Usage]
- Key Exportable=TRUE ; This setting is required for Server Authentication
- HashAlgorithm = SHA256
- KeyLength=2048
- KeySpec=1
- KeyUsage=0xf0
- MachineKeySet=TRUE

- [EnhancedKeyUsageExtension]
- OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
- OID=1.3.6.1.5.5.7.3.2 ; Client Authentication

- [Compatibility Settings]
- Compatible with Windows Server 2003 ; (or newer based on
environment)

- [Cryptography Settings]
- Provider Category: Legacy Cryptography Service Provider
- Algorithm name: RSA
- Minimum Key Size: 2048 ; (2048 or 4096 as per security requirement.)
- Providers: "Microsoft RSA Schannel Cryptographic Provider and
Microsoft Enhan

You can use this procedure to configure the certificate template that Active
Directory® Certificate Services (AD CS) uses as the basis for server certificates
that are enrolled to servers on your network.
While configuring this template, you can specify the servers by Active
Directory group that should automatically receive a server certificate from
AD CS.

The procedure below includes instructions for configuring the template to

issue certificates to all of the following server types:

• Servers that are running the Remote Access service, including RAS
Gateway servers, that are members of the RAS and IAS
Servers group.
• Servers that are running the Network Policy Server (NPS) service
that are members of the RAS and IAS Servers group.

Membership in both the Enterprise Admins and the root domain's Domain
Admins group is the minimum required to complete this procedure.

To configure the certificate template

1. On CA1, in Server Manager, click Tools, and then

click Certification Authority. The Certification Authority
Microsoft Management Console (MMC) opens.
2. In the MMC, double-click the CA name, right-click Certificate
Templates, and then click Manage.
3. The Certificate Templates console opens. All of the certificate
templates are displayed in the details pane.
4. In the details pane, click the RAS and IAS Server template.
5. Click the Action menu, and then click Duplicate Template. The
template Properties dialog box opens.
6. Click the Security tab.
7. On the Security tab, in Group or user names, click RAS and IAS
servers.
8. In Permissions for RAS and IAS servers, under Allow, ensure
that Enroll is selected, and then select the Autoenroll check box.
Click OK, and close the Certificate Templates MMC.
9. In the Certification Authority MMC, click Certificate Templates.
On the Action menu, point to New, and then click Certificate
Template to Issue. The Enable Certificate Templates dialog box
opens.
 10. In Enable Certificate Templates, click the name of the certificate
template that you just configured, and then click OK. For example,
if you did not change the default certificate template name,
click Copy of RAS and IAS Server, and then click OK.

How to manage templates

You must be a member of Domain Admins to access and administer

certificate templates for a domain. To add this snap-in, install the AD CS
management tools on the management computer. The AD CS management
tools are part of the Remote Server Administration Tools (RSAT). You can
install the management tools on a Windows Server computer by running the
following PowerShell command from an elevated PowerShell session:

PowerShellCopy
Install-WindowsFeature RSAT-ADCS

To configure an MMC to use the Certificate Templates snap-in:

1. Right click Start, click Run, and then type mmc.

2. On the File menu, click Add/Remove Snap-in.
3. On the Add and Remove Snap-ins dialog box, double-click the
Certificate Templates snap-in to add it to the list. Click OK.

Create a new certificate template

You can create a new certificate template by duplicating an existing template

and using the existing template's properties as the default for the new
template. Review the list of default certificate templates, and examine their
properties to identify the existing certificate template that most closely
meets your needs. Membership in Domain Admins, or equivalent, is the
minimum required to complete this procedure.

To create a new certificate template:

1. Open the Certificate Templates snap-in and connect to the AC CS

Enterprise root or subordinate server.
2. Right-click the template to copy from, and then click Duplicate
Template.
This guide outlines strategies for transitioning an IPv4 network environment
in Azure to IPv6. This transition is necessary as the number of internet-
connected devices expands and IPv4 addresses near exhaustion. The IPv6
protocol provides a larger pool of internet addresses to accommodate future
growth and offers enhanced security features (native IPSec), flow labeling,
and simplified network configurations. This article helps you understand IPv6,
acquire IPv6 addresses, and transition to IPv6.

Understand IPv6

IPv6 has such a large address space that you should use consistent IPv6
address block sizes that over-allocate IPv6 addresses. This networking
strategy contrasts with IPv4. The limited number of IPv4 addresses forces you
to use the smallest possible subnet size. This table gives you a sense of the
increased size of IPv6:

Expand table
IP version Number of IP addresses
IPv4 4,294,967,296
IPv6 340,282,366,920,938,463,463,374,607,431,768,211,456

Dual stacking. Azure virtual networks support dual stacking. A network that
supports dual stacking can process IPv4 and IPv6 traffic simultaneously. You
can assign a new IPv6 address block to a subnet that has an existing IPv4
block. Services that use IPv6 can coexist with services that use IPv4. You can
therefore start the IPv6 transition before all services support IPv6.

IPv6 in Azure. In your Azure environment, network interfaces receive one of

three types of IPv6 addresses:

• Private IP addresses. To enable IPv6 on private IP addresses, you

apply an IPv6 address range to the virtual network and its subnets.
The network interfaces in subnets get a static or dynamic address,
depending on your configuration. You can see the IP address
assignment in the Azure portal. You can also see it in the virtual
 machine configuration, if you use virtual machines. In the
operating system, this address is shown as the IPv6 address.
• Public IP addresses. You can apply public IPv6 addresses to
network interfaces. Public IP addresses must be globally unique
and routable on the internet. You need to generate a unique IPv6
address that can be used for public endpoints on Azure, like load
balancers or application gateways. You can use the New-
AzPublicIpAddress cmdlet to create an IPv6 public address in
PowerShell.

The operating system configuration doesn't show the public IP

address, but you can see the public IP address in the Azure portal.
You can use public IPv6 addresses for inbound and outbound
communication to and from the internet. You might need to
update the route table with user defined routes to support IPv6.
Many organizations use shared network virtual appliances (NVAs)
for public communication and don't assign a public IP address to
network interfaces. You aren't charged for Azure public IPv6
addresses, although you're charged for IPv4 addresses. For more
information, see IP Addresses pricing.

• Link-local addresses. Link-local addresses are a special type of

private IP address. In IPv6, link-local addresses are automatically
configured on all interfaces. They're used for communication
within a single network segment and aren't routable on the
internet. They come from the fe80::/10 space instead of from your
subnet's address block. You can see the fe80::/10 address
assigned to your interface from within the operating system.

For more information about other specialty address blocks, see IANA IPv6
Special-Purpose Address Registry.

Acquire IPv6 addresses

If your organization already has IPv6 addresses, you can benefit from using
them in your Azure environment. If not, you need to acquire new ones. Using
existing addresses can be more cost-effective and efficient, but acquiring
new ones ensures that you have a sufficient and continuous block of
addresses for your needs. It also reduces the chance of address conflicts. If
you don't have IPv6 space secured for your organization, you can use global
addresses or local addresses.

Global addresses: Global addresses are public IP addresses that are unique
across the internet. You can contact a registrar to request a continuous block
of general allocation or global addresses. These IPv6 addresses can be used
in subnets, virtual networks, and regional supernets in Azure. To have
sufficient space for growth in multiple regions, you should plan to allocate a
/36 address space to your whole Azure environment. You can use global
addresses for both private networks and public endpoints, or you can
allocate different ranges. Unique global addresses can't have IP address
conflicts.

Local addresses: Local addresses are private IP addresses that are used within
a virtual network. You can use IPs in the unique local address range. This
address range functions like the IPv4 private address range, such as
the 10.0.0.0/8 address space. IPv6 reserves the fc00::/7 address blocks for
unique local addresses. These addresses aren't globally reachable, even
though they're a part of the IPv6 Global Unicast Address range.

If you use the unique local address range, your IP addresses might overlap
with the IP address range of another organization. If there's an overlap, you
might experience challenges with integrating networks. For more
information, see the Unique Local IPv6 Unicast Addresses memo.

Transition to IPv6

You should align your plan for assigning IPv6 addresses to your Azure
networks with your organization's IPv6 addressing plan. Your organization
should already have a plan for on-premises IPv6 use, so that you can allocate
space between different locations without overlapping. If you don't have a
plan, you should define one before you start your implementation on Azure.
For more information, see Plan for IP addressing.

Some of the practices that are necessary in IPv4 to conserve addresses aren't
applicable in IPv6. You should over-allocate IPv6 addresses and use a
standard block size for the Azure environment, regions, virtual networks, and
subnets, as shown in the following table. These recommendations apply to
IPv6, not to IPv4 environments. For more information, see Plan for IP
addressing.
Expand table
Scope Size Number of instances
Azure environment /36 1
Region /44 256
Virtual network /56 4,096 per region
Subnet /64 256 per virtual network

Transitioning regions to IPv6. You should use a supernet and assign a /44
IPv6 address space to each Azure region. As with IPv4, a supernet doesn't
have a technical representation in Azure. Instead, you assign and track it in
your IP Address Management system (IPAM). This table illustrates what the
address blocks would look like for multiple regions:

After this IP address space is allocated to the region, you can deploy new
networks and workloads by defining virtual networks and subnets from that
IP space.

Transitioning virtual networks to IPv6. You should assign a /56 IPv6

address space to each virtual network. This assignment facilitates networking
management and streamlines the creation process. It enables you to create
4,096 virtual networks in a region and 256 subnets in a single virtual network.

Transitioning subnets to IPv6. You can continue to use your existing

subnet architecture and assign a /64 address block to each subnet. This
subnet size also enables you to plan your network conceptually. You don't
need to worry about resizing subnets due to address exhaustion.

One significant difference between IPv6 networks and IPv4 networks on

Azure is the minimum size of subnets. The minimum size of IPv6 subnets on
Azure is /64. Each subnet contains 18,446,744,073,709,551,616 hosts, minus

Reusing IPv4 addresses. As you transition to IPv6 addresses, you can

repurpose private IPv4 addresses in different virtual networks within your
Azure environment. This transferability enables you to maintain active
services while transitioning to IPv6 and effectively manage your IP space
during the transition. The reuse option gives you a larger effective IPv4 space.
For any peered virtual network, you must ensure that the IPv4 address ranges
don't overlap.
When you install the Remote Access Server Role with the Add Roles and
Features Wizard or Windows PowerShell, you can choose to install one or
more of the following three role services:

• Direct Access and VPN (RAS) service

• Routing service
• Web Application Proxy service

Anyone of these services can be installed either individually or on the same

server.

Important

Don't attempt to deploy Remote Access on a virtual machine (VM) in

Microsoft Azure. Using Remote Access in Microsoft Azure is not supported.
You can't use Remote Access in an Azure VM to deploy VPN, DirectAccess,
or any other Remote Access feature in Windows Server. For more
information, see Microsoft server software support for Microsoft Azure
virtual machines.

DirectAccess and VPN service

VPN (RAS)

The VPN service uses the connectivity of the internet and a combination of
tunneling and data encryption technologies to connect to remote clients and
offices.

With VPN and Routing service, you can also choose to deploy Always On
VPN. Always On VPN enables Windows 10 clients to securely access shared
resources, intranet Web sites, and the applications on an internal network
without having to manually connect. For more information, see Always On
VPN
DirectAccess

DirectAccess allows connectivity for remote users to organization network

resources without the need for traditional VPN connections. With
DirectAccess connections, remote client computers are always connected to
your organization. There's no need for remote users to start and stop
connections, as is required with VPN connections. In addition, your IT
administrators can manage DirectAccess client computers whenever they're'
running and Internet connected.

Important

For Windows 10 or later, it is recommended to connect using Always On VPN.

DirectAccess should be used only for clients earlier than Windows 10.

Routing service

The Routing service allows you to route network traffic between subnets on
your Local Area Network. Routing provides support for the following
technologies:

• Network Address Translation (NAT) routers

• LAN routers running Border Gateway Protocol (BGP)
• Routing Information Protocol (RIP)
• Multicast-capable routers using Internet Group Management
Protocol (IGMP)
• Demand-dial routing
• Unicast IP Routing

As a full-featured router, you can deploy RAS on either a physical computer

or as a virtual machine (VM) on a computer that's running Hyper-V.

To install Remote Access as a LAN router, either use the Add Roles and
Features Wizard in Server Manager and select the Remote Access server role
and the Routing role service; or type the following command from an
elevated Windows PowerShell prompt, and then press ENTER.

Copy
Install-RemoteAccess -VpnType RoutingOnly
Web Application Proxy service

Web Application Proxy service provides reverse proxy functionality for web
applications inside your corporate network to allow users on any device to
access them from outside the corporate network. Web Application Proxy pre-
authenticates access to web applications using Active Directory Federation
Services (AD FS), and also functions as an AD FS proxy.

To install Remote Access as a Web Application Proxy, either use the Add
Roles and Features Wizard in Server Manager and select the Remote
Access server role and the Web Application Proxy role service; or type the
following command at a Windows PowerShell prompt, and then press
ENTER.

Copy

Install-RemoteAccess -VpnType SstpProxy

For more information, see Web Application Proxy.

For more information about other networking technologies, see Networking

in Windows Server.

Next Steps

Now you've learned about what the Remote Access role is, here are some
articles that might help you during deployment:

• Always On VPN Deployment Guide

• Border Gateway Protocol (BGP)
• RAS Gateway
• RAS Gateway for SDN
• Virtual Private Networking (VPN)

How to enable Remote Desktop

The simplest way to allow access to your PC from a remote device is by using
the Remote Desktop options under Settings. Since this functionality was
added in the Windows 10 Fall Creators update (1709), a separate
downloadable app is also available that provides similar functionality for
earlier versions of Windows.
Windows 10 Fall Creator Update (1709) or later

You can configure your PC for remote access with a few easy steps.

1. On the device you want to connect to, select Start and then
choose the Settings icon on the left.
2. Select the System group followed by the Remote Desktop item.
3. Use the slider to enable Remote Desktop.
4. It's also recommended to keep the PC awake and discoverable to
facilitate connections. Select Show settings to enable.
5. As needed, add users who can connect remotely by clicking Select
users that can remotely access this PC. Members of the
Administrators group automatically have access.
6. Make note of the name of this PC under How to connect to this
PC. You'll need this to configure the clients.

Windows 7 and early version of Windows 10

To configure your PC for remote access, download and run the Microsoft
Remote Desktop Assistant. This assistant updates your system settings to
enable remote access, ensures your computer is awake for connections, and
checks that your firewall allows Remote Desktop connections.

Connect from a client device

To use Remote Desktop to connect to the remote PC you set up, type Remote
Desktop Connection on your local PC, and then select Remote Desktop
Connection. Enter the name of the remote PC, then select Connect.

On your Mac, iOS, or Android device, open the Remote Desktop app
(available for free from the app stores). Add the name of the remote PC, and
then wait for the connection to complete.

Should I enable Remote Desktop?

If you only want to access your PC when you are physically using it, you don't
need to enable Remote Desktop. Enabling Remote Desktop opens a port on
your PC that is visible to your local network.
You can manage a Server Core server in the following ways:

• Using Windows Admin Center

• Using Remote Server Administration Tools running on Windows
10
• Locally and remotely using Windows PowerShell
• Remotely using Server Manager
• Remotely using an MMC snap-in
• Remotely with Remote Desktop Services

You can also add hardware and manage drivers locally, as long as you do
that from the command line.

There are some important limitations and tips to keep in mind when you
work with Server Core:

• If you close all command prompt windows and want to open a

new Command Prompt window, you can do that from the Task
Manager. Press CTRL+ALT+DELETE, click Start Task Manager,
click More Details > File > Run, and then type cmd.exe.
(Type Powershell.exe to open a PowerShell command window.)
Alternatively, you can sign out and then sign back in.
• Any command or tool that attempts to start Windows Explorer
won't work. For example, running start . from a command prompt
won't work.
• There's no support for HTML rendering or HTML help in Server
Core.
• Server Core supports Windows Installer in quiet mode so that you
can install tools and utilities from Windows Installer files. When
installing Windows Installer packages on Server Core, use
the /qb option to display the basic user interface.
• To change the time zone, run Set-Date.
• To change international settings, run control intl.cpl.
• Control.exe won't run on its own. You must run it with
either Timedate.cpl or Intl.cpl.
 • Winver.exe isn't available in Server Core. To obtain version
information use Systeminfo.exe.

Managing Server Core with Windows Admin Center

Windows Admin Center is a browser-based management app that enables

on-premises administration of Windows Servers with no Azure or cloud
dependency. Windows Admin Center gives you full control over all aspects
of your server infrastructure and is useful for management on private
networks that aren't connected to the Internet. You can install Windows
Admin Center on Windows 10, on a gateway server, or on an installation of
Windows Server with Desktop Experience, and then connect to the Server
Core system that you want to manage.

Managing Server Core remotely with Server Manager

Server Manager is a management console in Windows Server that helps you

provision and manage both local and remote Windows-based servers from
your desktops, without requiring either physical access to servers, or the
need to enable Remote Desktop protocol (RDP) connections to each server.
Server Manager supports remote, multi-server management.

To enable your local server to be managed by Server Manager running on a

remote server, run the Windows PowerShell cmdlet Configure-
SMRemoting.exe –Enable.

Managing with Microsoft Management Console

You can use many snap-ins for Microsoft Management Console (MMC)
remotely to manage your Server Core server.

To use an MMC snap-in to manage a Server Core server that is a domain

member:

1. Start an MMC snap-in, such as Computer Management.

2. Right-click the snap-in, and then click Connect to another
computer.
 3. Type the computer name of the Server Core server, and then
click OK. You can now use the MMC snap-in to manage the Server
Core server as you would any other PC or server.

To use an MMC snap-in to manage a Server Core server that isn't a domain
member:

1. Establish alternate credentials to use to connect to the Server Core

computer by typing the following command at a command
prompt on the remote computer:

Copy

cmdkey /add:<ServerName> /user:<UserName>

/pass:<password>

If you want to be prompted for a password, omit the /pass option.

2. When prompted, type the password for the user name you
specified. If the firewall on the Server Core server isn't already
configured to allow MMC snap-ins to connect, follow the steps
below to configure Windows Firewall to allow MMC snap-in. Then
continue with step 3.
3. On a different computer, start an MMC snap-in, such as Computer
Management.
4. In the left pane, right-click the snap-in, and then click Connect to
another computer. (For example, in the Computer Management
example, you would right-click Computer Management (Local).)
5. In Another computer, type the computer name of the Server Core
server, and then click OK. You can now use the MMC snap-in to
manage the Server Core server as you would any other computer
running a Windows Server operating system.

To configure Windows Firewall to allow MMC snap-in(s) to connect

To allow all MMC snap-ins to connect, run the following command:

PowerShellCopy
Enable-NetFirewallRule -DisplayGroup "Windows Remote Management"
To allow only specific MMC snap-ins to connect, run the following:

PowerShellCopy

Enable-NetFirewallRule -DisplayGroup "<rulegroup>"

Where rulegroup is one of the following, depending on which snap-in you

want to connect:

Expand table

MMC snap-in Rule group

Event Viewer Remote Event Log

Management

Services Remote Service Management

Shared Folders File and Printer Sharing

Task Scheduler Performance Logs and Alerts,

File and Printer Sharing

Disk Management Remote Volume Management

Windows Defender Firewall with Advanced Windows Defender Firewall

Security
Remote Management

Note

Some MMC snap-ins don't have a corresponding rule group that allows them
to connect through the firewall. However, enabling the rule groups for Event
Viewer, Services, or Shared Folders will allow most other snap-ins to connect.

Additionally, certain snap-ins require further configuration before they can

connect through Windows Firewall:

• Disk Management. You must first start the Virtual Disk Service
(VDS) on the Server Core computer. You must also configure the
Disk Management rules appropriately on the computer that is
running the MMC snap-in.