Scenario – When you try to enable the Server-GUI-Shell feature on Windows 2012 R2 server core, you get some error. This TechNet article talks about the scenario we have mentioned here - https://support.microsoft.com/en-us/kb/2913316

Ideally you can install any Windows 2012 R2 server features from the local WinSxS directory (if it’s not removed as a part of deployment plan). When you install Windows Server Core, the files needed for GUI functionality are removed from the installation. So while installing the Server-GUI-Shell feature, this feature is not available on the Server Core operating system and you must provide an alternate path ( - source parameter, location to WinSxS folder or WIM file ) for feature installation. If you have access to internet then server can install the feature from Windows update, but as most of the time we don’t have internet access on Domain controllers, this method won't help.

As documented in the above article, we can provide the path to a WIM file but for that we need to have WIM file updated with the latest Windows updates, and we need to keep the WIM file updated on a regular basis. The easiest option is to copy the WinSxS folder from another server (running Windows 2012 R2 GUI edition) and provide the folder location as a source path. Steps given here talk about the process of installing Server-GUI-Shell feature using the WinSxS folder.

1. Before installing GUI-Shell feature on a domain controller, copy WinSxS folder from a Windows 2012 R2 server running in full GUI installation mode to a local directory. If you are installing it on multiple domain controllers, you can copy the WinSxS folder on a network share. Install-WindowsFeatureuses the machine account credentials to access the installation source. If the installation source is located on a network share, ensure that the machine account has permissions to read from the network share.

Default location for the WinSxS folder - C:\Windows\WinSxS

2. Copy the WinSxS folder to any local directory. For e.g. C:\Sw\WinSxS folder as shown in the given screenshot.

3. Once the WinSxS folder is copied locally on the DC, run the following command with the -source parameter to enable the GUI mode.

Install-Windowsfeature server-gui-shell –Source < path to WinSxS folder>

NOTE: When you copy the WinSxS folder make sure the source server is fully patched and has the latest Windows update. Once the GUI Shell feature is installed, you can go ahead and delete the folder from local drive if you are using local folder for installation. In case of Network share, make sure you are using the latest copy of WinSxS folder and re-copy the folder when new patches are applied on the server.

4. Use this command to uninstall the Server GUI feature if you have to revert back to Core installation.

Uninstall-WindowsFeature Server-Gui-Mgmt-Infra -Restart

5. When you want to re-enable the GUI-Shell on the same box you won't need to specify the source path as the binaries will be available on the server just like other features, after it was installed for the first time.

Install-WindowsFeature server-gui-shell

Sometimes you may come across a scenario where you want to use Windows KMS service to activate clients in a workgroup or in an untrusted forest. This could be a test / Dev environment where you have setup a new test forest and want to use the production KMS setup for activating clients in the test forest rather than installing a new KMS instance in test forest.

In this article we will look at configuring KMS service for an untrusted forest and for clients in a workgroup. This process doesn’t require any changes on the existing KMS server configuration, all changes we need to make are either in the target forest or on the workgroup clients.

In case you are new to KMS, you can refer to this TechNet article to know more about KMS - https://technet.microsoft.com/en-us/library/ff793434.aspx

Before we look into the steps to configure KMS in a different forest or workgroup, lets looks at some important KMS concepts:

KMS Activation

KMS activation requires TCP/IP connectivity. By default, KMS hosts and client computers use DNS to publish and find the KMS service. The default settings can be used, which require little to no administrative action, or KMS hosts and client computers can be manually configured based on network configuration and security requirements. So as mentioned when you install the KMS server in an AD domain, it publishes its SRV record in the Active Directory forest and no manual configuration is needed. As long as clients have KMS keys installed they will discover KMS service in the domain and get activated. If DNS dynamic update is not available or the KMS host does not have rights to publish the RRs, the DNS records must be published manually, or you must configure client computers to connect to specific KMS hosts.

NOTE: In this scenario, as we are configuring clients in a different forest we need to manually configure the clients to point to the KMS server. This can be done either by configuring the KMS server on each of the client using Slmgr.vbs command or creating a SRV record for KMS service in the test forest. Obviously we need the KMS port opened between the client and the KMS server ( default 1688 or any other custom port configured for KMS in your environment .

Client Discovery of the KMS Service

By default, KMS clients query DNS for KMS service information. The first time a KMS client queries DNS for KMS service information, it randomly chooses a KMS host from the list of SRV RRs that DNS returns.

KMS Activation Renewal

KMS activations are valid for 180 days—the activation validity interval. To remain activated, KMS client computers must renew their activation by connecting to the KMS host at least once every 180 days. By default, KMS client computers attempt to renew their activation every seven days. If KMS activation fails , the client will retry every two hours. After a client computer’s activation is renewed, the activation validity interval begins again.

1. Configure clients in a Workgroup : Use this option if you want to activate clients in a workgroup and you have handful of clients to activate. You can run these commands manually or can create a batch file if you have more clients to configure.

Use slmgr.vbs /skms command to configure the KMS server FQDN / IP address on each of the clients.

( Run these commands from elevated command prompt )

slmgr.vbs /skms <KMS server>:<port>

User slmgr.vbs /ato command to manually activate the client

slmgr.vbs /ato

Note : By default clients running Volume license edition of Windows are KMS clients and you don't need to install the KMS client key. If you have MAK or retail edition of Windows client, you can convert that to a KMS client by installing the GVLK key using command slbhr.vbs /ipk as shown above. More details here - https://technet.microsoft.com/en-us/library/jj612867.aspx

       2.    Creating SRV record for the KMS host in an untrusted forest

Another option is to create an SRV resource record for the KMS service in untrusted forest that points to KMS server in a different forest.

Using DNS Manager, in the appropriate forwarding lookup zone, create a new SRV RR using the appropriate information for the location. By default, KMS listens on TCP port 1688, and the service is _VLMCS. Table below contains example settings for a SRV RR.

Table . SRV Resource Record

NOTE: As you are creating this SRV record in a different forest, you first need to create an A record that points to the KMS server. Once the A record is created you can configure the SRV record.

Once the SRV RR is configured, KMS clients will discover the KMS service using DNS and will send request for activation to the KMS server.

Features on Demand is a feature, introduced in Windows® 8 and Windows Server 2012, that allows you to remove role and feature files (sometimes called feature payload) from the operating system to conserve disk space, and install roles and features from remote locations or installation media instead of from local computers. You can remove feature files from running physical or virtual computers. You can also add feature files to or remove feature files from Windows image (WIM) files or offline virtual hard disks (VHDs) to create a reproducible copy of Features on Demand configurations. For more information on Windows features on demand please refer : https://technet.microsoft.com/en-us/library/jj127275.aspx

In a Features on Demand configuration, when feature files are not available on a computer, if an installation requires those feature files, Windows Server 2012 R2 or Windows Server 2012 can be directed to get the files from a side-by-side feature store (a shared folder that contains feature files, and is available to the computer on the network), from Windows Update, or from installation media.

This article talks about installing the Windows roles and features from side-by-side feature store containing the WinSxS folder and the SxS folder on a network share.

You can use the Uninstall-WindowsFeature cmdlet both to uninstall roles, role services, and features from servers and offline VHDs that are running Windows Server 2012 R2 or Windows Server 2012, and to delete feature files.

For e.g. as you see in the below screenshot I have removed the WINS feature from the server in my lab. "Install State" column shows the feature status as removed once the feature is removed from the server. When I try to install the feature I get the error "provide the path of the source files to install the roles or features".

When we configure the side-by-side feature store, we can have a install.WIM file that contains the full image of the operating system or WinSxS folder hosted on a network share. We also need to copy the SxS folder from operating system media to the network share for installation.

Install.WIM file contains multiple OS images in it, to find the image that you want to use for installation of roles and features you can use the below command. It provides the index for each OS image available in the Install.WIM file. Also as you will notice in the below screenshot you can have the WIM file either on the local server or on a remote network share, I have WIM file hosted on my file server.

Or I can have a install.WIM file hosted locally. Both the commands used in the above screenshot and the below screenshot provide the same result.

I want to use the Windows Server 2012 R2 ServerStandard image for installation of features. Let me try installing the WINS feature again this time by giving the source WIM file path and the image index.

Install-WindowsFeature -Name WINS -source "WIM:\\adfs1\sw\windows 2012 r2\install.wim:2

You add prefix WIM to the source file path, when providing the path for the WIM file. We don’t need to add this prefix if we give the direct path to the WinSxS folder on a network share.

Or install it from the local WIM file

Install-WindowsFeature -Name WINS -source "WIM:\\z:\sw\windows 2012 r2\install.wim:2"

We can also configure the source path to the WinSxS share or the WIM file through Group Policies. When configured, we don’t need to provide the source path while installing the feature, as it automatically picks the source path configured in group policies. Configuring optional installation path via GPO helps administrators to install the services that they need without having knowledge of the source file path.

Apply the GPO

Remove the WINS feature and Install it again, this time without specifying the source path location for WIM file as that is already configured in Group Policies.

We can also try this for .NET framework feature.

Uninstall and remove the .NET framework 3.5 from the server.

Now try to install the .NET 3.5 feature from PowerShell, as currently GPO is not configured to point to SXS folder it gives error and doesn’t install the feature. Existing setting in GPOS only contains the path to the WIM file.

Now let's add the network path to the SXS folder as well in the GPO settings for "optional component installation and component repair". So now I have two paths configured in GPO setting, one pointing to the WIM file and other pointing to the SxS folder.

Run gpupdate /force on the target server to ensure the GPO is applied

After GPO is updated you can verify the same from GPresult or RSOP.

Try installing the .NET 3.5 feature now, this feature is installed from the SxS folder on a network share for which path is now configured in the GPO. You don’t have to specify the source path in the command as its configured via GPO. Configuring the optional installation path in GPO helps administrators to install the services that they need without having knowledge of the source file path.

We can perform same tasks from Add server roles and features wizard:

1. Go to Remove roles and features to uninstall the .NET framework 3.5
2. Uninstall the .NET framework 3.5 features
3. Restart the machine to complete the removal.
4. Remove the location to SxS folder from the GPO and run Gpupdate /force on the Windows server machine to apply the new GPO settings

Now try installing the .NET framework 3.5 features back using Add Roles and services.

For testing, we don’t specify the source file path for installation

Installation fails as expected because the source file path was not given neither its configured in the GPO

Let's modify the GPO again, to add the network path to the source file folder.

Run Gpupdate/ Force on the server to ensure GPO setting is updated. Run RSOP to verify the applied GPO on target server

You can also verify if the GPO is applied to the server and the network path is populated in Regedit.

Try installing the feature again

This time the installation succeeds on the server.

Similar process can be followed to install the other server roles and features which were removed earlier from the server.

iSCSI target allows your Windows Server to share block storage remotely. iSCSI leverages the Ethernet network and does not require any specialized hardware. iSCSI target is a service available in Windows 2012 R2 and can enabled from Add Roles and Features Wizard.

Target: Targets are created in order to manage the connections between the iSCSI target server and the servers that need to access them. You assign logical unit numbers (LUNs) to a target, and all servers that log on to that target will have access to the LUNs assigned to it.

iSCSI Target Server: iSCSI target server is the server where iSCSI target service is running. In Windows 2012 there is a service called iSCSI service that you can install to configure iSCSI target server.

iSCSI virtual disk: iSCSI virtual disks are created on iSCSI target server and associated to the iSCSI target. iSCSI virtual disk represents an iSCSI LUN, which are connect to the clients using iSCSI initiator.

iSCSI initiator: Microsoft® Internet iSCSI Initiator enables you to connect a host computer that is running Windows® 7 / Windows Server® 2008 R2 or higher to an external iSCSI-based storage array through an Ethernet network adapter. iSCSI initiator service runs on the client and used to make a connection to the iSCSI Target by logging on to a Target server.

For more details you can refer :

Windows iSCSI initiator feature - https://technet.microsoft.com/en-us/library/ee338474(v=WS.10).aspx

Manage iSCSI Targets - https://technet.microsoft.com/en-us/library/cc726015.aspx 

This article talks about how to configure the iSCSI service in Windows 2012 R2.

1. Go to Add Roles and Features Wizard and install the iSCSI target server role under file server role.

2. Install the iSCSI target server role.

3. Once the iSCSI service is installed you can go ahead create the virtual iSCSI virtual disks and then connect it to the servers you want. Click on New iSCSI virtual Disk:

4. As Windows 2012 R2 allows you to manage other servers, you can select the server where you want to create the iSCSI VHD.

5. Provide a name to the iSCSI virtual disk. As you would notice now it has support has for .vhdx file.

6. Different options that you can select for your disk including fixed size, dynamically expanding disks and differencing disk. As I do not have a dedicated storage for the disk, I want to select the Dynamically expanding storage.

7. If you have an iSCSI target created, you can add the iSCSI virtual disk to the same iSCSI target or created a new iSCSI target. Once an iSCSI initiator connects to the iSCSI target all virtual iSCSI virtual disks will be available to the server.

8. Provide a name to the iSCSI target.

9. Add the iSCSI initiator server which will access the iSCSI target. There can be more the one initiator that you can specify here, I have added two servers under iSCSI initiator.

10. Add the iSCSI initiator that will access this iSCSI target.

11. Select an authentication method that is used to connect to the iSCSI target. As this is just a lab I didn’t select any  authentication method.

12. Target is created

Connecting iSCSI initiator to the iSCSI target server

Typically, the iSCSI initiator and iSCSI Target are on different machines (physical or virtual). You will need to provide the iSCSI Target server IP or host name to the initiator, and the initiator will be able to do a discovery of the iSCSI Target. All the Targets which can be accessed will be presented to the initiator.

1. Once the iSCSI target is configured, go to the Windows 2012 R2 server where you want to connect to the iSCSI virtual disk. Open the iSCSI intiator from server tools and provide the IP address / hostname for the iSCSI target server.

2. It displays the targets which are configured on the server. Connect to the iSCSI target. Once connected to the iSCSI target, it provides you access to all the iSCSI virtual disks that are associated to the iSCSI target.

Advanced configuration by specify IPs for iSCSI connection: If you want to dedicate iSCSI traffic to a specific set of the NICs, you can specify that in the “Connect using”. By default, any IPs can be used for iSCSI connection.

3. Create new volume

Once the connection is established, the iSCSI virtual disk will be presented to the initiator as a disk. By default, this disk will be offline,. For typical usage, you want to create a volume, format the volume and assign with a drive letter so it can be used just like a local hard disk.

In the previous article - https://blogs.technet.com/b/amitd/archive/2014/05/07/configure-adfs-and-device-registration-service-in-windows-2012-r2.aspx we looked at the installation of ADFS service in Windows 2012 R2 and enabling the Device registration service. This article talks about the installation and configuration of Web Application Proxy service in Windows 2012 R2.

The know the features supported by Web Application Proxy service you can refer my previous article - https://blogs.technet.com/b/amitd/archive/2014/04/18/web-application-proxy-in-windows-2012-r2.aspx

1. Installing Web Application proxy

2. Click Next

3. Select the Web Application Proxy role service:

4. Configure the Web Application Proxy service to establish trust with the federation service:

5. Provide the name for the federation service and the admin account credentials on the federation servers.

6. You need to ensure the same certificate which was configured on ADFS federation server is installed on Web Application Proxy server as well. Select the correct cert as given in the screenshot below:

Click Next and finish the configuration to complete the installation of Web Application Proxy (WAP)

From TechNet: https://technet.microsoft.com/en-us/library/dn486831.aspx

Important
You do not need to publish the Device Registration Service to the Web Application Proxy. The Device Registration Service will be available through the Web Application Proxy once it is enabled on a federation server.

Now you can test the workplace join feature from any supported device. Devices running Windows 8.1, Windows RT 8.1, or a non-Microsoft OS such as Apple's iOS supported the workplace join feature.

        In this article we will look at the installation of ADFS service and enabling Device Registration service in Windows 2012 R2.

Installing ADFS federation server:

1. Install the ADFS role service from Windows Server manager. In Windows 2012 R2 you can remotely install the roles on server.

2. Click Next > Next > Next > Install to install the ADFS role.

3. Go to the server manager notification and click on Configure the ADFS service

4. Make sure the requirements given in the below screenshot are met before you proceed to next step. Select whether this is the first federation server in a federation server farm or a new server in existing federation farm.

3. Provide the credentials for domain admin account to configure ADFS service as mentioned below:

4. Select the ADFS certificate which is installed on the ADFS server. Obviously the federation service name should be same as the name used in the ADFS certificate.

5. Here you can specify a domain user account or Group Managed Service Account. Group Managed Service Account (GMSA) is a new feature in Windows 2012, which is an improvement to the managed service account in Windows 2008 R2. GMSA are managed domain accounts that provide automatic password management and simplified SPN management, including delegation of management to other administrators. The group Managed Service Account provides the same functionality within the domain but also extends that functionality over multiple servers.

6. You can select a SQL server database or the Windows internal database to host the ADFS configuration database

7. Click configure and that finishes the ADFS configuration.

8. There are few additional steps to enable the Device registration service:

Initialize the ADDeviceRegistration service on ADFS server

Enabled the ADFS Device Registration service

Enable device authentication in ADFS management console:

Starting with Windows 8 and Windows 2012, you can use Active Directory Based Activation (ADBA) method for volume activation in addition to existing volume activation methods i.e. Key Management System (KMS) and Multiple Activation Key (MAK).  This article provide brief details on various existing methods with the detailed description on Active Directory Based Activation.

Key Management Service - With KMS, IT pros can complete activations on their local network, eliminating the need for individual computers to connect to Microsoft for product activation. KMS is a lightweight service that does not require a dedicated system and can easily be co-hosted on a system that provides other services. By default, volume editions of Windows 7 and Windows Server 2008 R2 connect to a system that hosts the KMS service to request activation. No action is required from the user. KMS activation can be used for machines joined to the domain as well as machine which are part of workgroup.

KMS requires a minimum number of computers (physical or virtual machines) in a network environment. The organization must have at least five computers to activate Windows Server 2008 R2 and at least 25 computers to activate clients that are running Windows 7. These minimums are referred to as activation thresholds.

To use KMS activation with Windows 7, the computer must have the qualifying OS license (often obtained through OEMs as part of the new PC purchase) and contain a Windows Marker in BIOS.

Multiple Activation Key - MAK is used for one-time activation with Microsoft’s hosted activation services. There are two ways to activate computers using MAK. The first method is MAK Independent activation, which requires that each computer independently connect and be activated with Microsoft either over the Internet or by telephone. The second method is MAK Proxy activation. With this method, a computer acting as a MAK proxy gathers activation information from multiple computers on the network, and then sends a centralized activation request on their behalf. MAK Proxy activation is configured using the Volume Activation Management Tool (VAMT).

Active Directory Based Activation - ADBA is a new feature in Windows 2012 and can be used to activate computers running Windows 8 / Windows 2012 or higher operating system. So if you only have clients running Win 8 / Win 2012 in your environment, ADBA provides much simpler option for volume activation.

With ADBA, any client computer gets activated automatically when it is joined to the domain. Activation will cease if the client computer is disjoined from the domain or if the client computer is not able to communicate to the domain controller for 180 days. As ADBA doesn't have option to activate the computers in workgroup, you need to look at some other options ( MAK/phone/KMS activation ) for workgroup computers.

Important things to remember while working with ADBA:

• Active Directory schema must be updated to Windows 2012 or higher to support the creation of Activation object.
• Can be installed on any member Windows 2012 / Windows 2012 R2 member server
• Can only be used for computers running Windows 8 / Windows 2012 or higher operating system. If you have machines running older operating systems, KMS can be used in combination of ADBA.
• You need the KMS host key (CSVLK) while configuring the ADBA service
• Activation object is created in Schema and replicated to every domain controller. As long as client can connect to the domain controller they can access the Activation object for volume activation.
• No dedicated computer is required to run the service as the service is distributed throughout the forest
• There is no minimum threshold that clients has to meet for activation unlike KMS
• ADBA Cannot be used to activate workgroup computers
• ADBA can be used for activation of Microsoft Office 2013

Web Application Proxy serves as a barrier between the Internet and your corporate applications. In many organizations, when you deploy Web Application Proxy and publish applications through it, those applications will be available to external users on devices that are not joined to your domain; for example, personal laptops, tablets, or smartphones. These devices are not domain-joined and as such, they are described as unmanaged devices, and are untrusted within the corporate network. Since you want your users to be able to access important information whenever and wherever they are located, you must mitigate the security risk of allowing users access to corporate resources from these unmanaged and untrusted devices. Web Application Proxy provides a number of security features to protect your corporate network from external threats. Web Application Proxy uses AD FS for authentication and authorization to ensure that only users on devices who authenticate and are authorized can access your corporate applications.

Web Application Proxy must always be deployed with AD FS. This enables you to leverage the features of AD FS, such as, single sign-on (SSO). This enables users to enter their credentials one time and on subsequent occasions, they will not be required to enter their credentials. SSO is supported by Web Application Proxy for backend servers that use claims-based authentication; for example SharePoint claims-based applications, and Integrated Windows authentication using Kerberos constrained delegation. Integrated Windows authentication-based applications can be defined in AD FS as relying party trusts which can define rich authentication and authorization policies that are enforced in requests to the application.

Publishing Application in WAP:

When you publish applications through Web Application Proxy, the process by which users and devices are authenticated before they gain access to applications is known as preauthentication. Web Application Proxy supports two forms of preauthentication:

• AD FS preauthentication—When using AD FS for preauthentication, the user is required to authenticate to the AD FS server before Web Application Proxy redirects the user to the published web application. This ensures that all traffic to your published web applications is authenticated.

• Pass-through preauthentication—Users are not required to enter credentials before they connect to published web applications.

In the 2nd part we will discuss installation of Web application Proxy (WAP) and configuration of ADFS Proxy and publishing device registration service.

ADFS has undergone many changes in Windows 2012 R2, new improvements in ADFS are:

• ADFS is a role service in Windows 2012 R2
• Support for Multi factor authentication which can be applied globally or per Relying Party
• A brand new Device Registration service that allows you to register non domain joined devices to your Corporate Active Directory which is known as workplace joined. Workplace joined is a mid-state between domain joined and workgroup computers. You need to manually enable this service once ADFS is installed and need to have the subject name for the Device registration service on the certificate used for ADFS. This service can be used as a second factor authentication to ensure that an application can be accessed from devices which are workplace joined.
• Web Application Proxy - ADFS Proxy is used to publish the ADFS service to external clients. In Windows 2012 R2, a new service Remote Access Role is used to install the ADFS proxy service. To configure the ADFS Proxy you need to install the Web Application Proxy service and enable the ADFS Proxy service there. Apart from being used as an ADFS Proxy, Web application Proxy can be used as a reverse proxy service for many other applications, a functionality which is also provided by TMG.
• Password change from Workplace joined devices
• New PowerShell commands for federation server and ADFS Proxy

Prerequisites – Before you install the ADFS service, make sure the following prerequisites are met:

Certificate

You need a third party certificate for ADFS service which is trusted by clients. Following subject names are required in certificate:

Subject Name (CN): adfs1.contoso.com  ( or whatever is the name for ADFS service )

Subject Alternative Name (DNS): adfs1.contoso.com

Subject Alternative Name (DNS): enterpriseregistration.contoso.com (for device registration service which is used by clients to connect to device registration service)

This certificate should be installed on federation server as well as on Web Application Proxy server

ADFS Service account

Create a group managed service account (GMSA) that is used for ADFS service account while installing ADFS. FSGMSA group managed account is used in this demo.

You can also use a domain service account for ADFS service account.

DNS service records

Create A record for ADFS service that point to ADFS farm or standalone ADFS server

Create an alias for device registration service i.e. Enterpriseregistration.contoso.com that points to ADFS server

Configure name resolution between the ADFS federation and Web Application Proxy