Workshop on Windows Server 2012

Topics covered on Workshop

DHCP Scope Splitting. A Dynamic Host Configuration Protocol (DHCP) split-scope configuration using

multiple DHCP servers allows for increased fault tolerance and redundancy over

using only one DHCP server.

This step-by-step guide contains an introduction to using DHCP with a split

scope on a secondary server, with delay, and instructions for setting up a test lab

using two DHCP servers and one DHCP client.

Requirements of DHCP Scope Splitting.

You must have Three computers running with Windows Server 2012

Computer1: Promote DC.

Computer2 and Computer3: Member of Domain and install DHCP Service.

Configure DHCP Scope Splitting:

1. In the DHCP console tree, right-click Scope [172.16.0.0] SS Scope, and then

click Advanced > Split-Scope.

2. The DHCP Split-Scope Configuration wizard is launched.

3. On the Percentage of Split page, set the configuration for a ratio of 80:20 by

assigning DHCP Server 1 to exclude addresses 172.16.1.164 to

172.16.1.204, and DHCP Server 2 to exclude 172.16.1.4 to 172.16.1.163. See

the example below.

4. Click Next, and then on the Delay in DHCP Offer page, configure DHCP

Server 1 with a value of 0 (default) and configure Added DHCP Server

(DHCP Server 2) for 1000 milliseconds. This enables DHCP Server 2 to offer

DHCP OFFER messages only after a delay of 1000 milliseconds, thereby

preventing the exhaustion of IPv4 addresses from the required scope of

DHCP Server 2.

VM Migration using Hyper-V.

Hyper-V role migration involves moving the virtual machines, virtual networks,

and all the associated settings from one physical computer to another physical

computer in the enterprise. The process supports moving from a server running

Hyper-V in Windows Server 2012 to a server running Hyper-V in Windows Server

2012 R2. The Hyper-V role does not depend on any other roles.

Installing Hyper-V Role in windows Server 2012 R2

1. Install Windows Server 2012 R2 on the new server hardware.

2. Install the Hyper-V role on the server.

3. Configure the following Hyper-V settings, for example:

○ The default location for virtual hard disks and virtual machine

configuration files.

○ Live migration settings. Even if live migration was not previously

configured, you must enable and configure live migration on both

servers.

○ Virtual switches.

○ Hyper-V Administrators local group membership.

4. Install the latest updates.

5. You must have Three computers running with Windows Server 2012

6. Computer1: Promote DC.

7. Computer2 and Computer3: Member of Domain and install DHCP Service.

Perform this procedure on the source server running Hyper-V in Windows Server

2012.

To move the virtual machine to Hyper-V in Windows Server 2012 R2

1. On the source server running Hyper-V in Windows Server 2012, open the

Hyper-V Manager console, and then select the virtual machine that you

want to move.

2. From the Actions pane, click Move. This action opens the Move Wizard.

1. On the Choose Move Type page, select Move the virtual machine.

2. On the Specify Destination Computer, specify the name or server

that is running Windows Server 2012 R2.

3. On the Choose Move Options page, select Move only the virtual

machine.

Iscsi Target and Initiator

8. 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: 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.

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

The iSCSI initiator and iSCSI Target are on different machines (physical or virtual). You

will need to provide the iSCSI Target server IP or hostname 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 initiator 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.

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.

Capture image using WDS

How to Create a Capture Image by Using WDS Console

"A capture image is created from an existing boot image. You will create a new capture

image by right-clicking on an existing boot image and then selecting Create Capture

Image option (see the following figure). The Create Capture Image Wizard will start."

"The default details in the Image Name and Image Description fields will be derived from

those same details in the source boot image. You should customize them to make it clear

that this is a capture image rather than a normal boot image.

The Location And File Name filed is used to specify where the new WIM file for the

capture image will be created. I am going to show you a little shortcut. The wizard will

lead you to think that you should create the new WIM file in a temporary location and

then add it again in a later step. I feel like that is a bit of wasted effort. Instead, I

recommend that you simply create the new capture image file in the image store location

for boot images. That will eliminate the additional step. You should create 32-bit images

in \Remoteinstall\Boot\x86\Images and 64-bit images in \Remoteinstall\Boot\x64\Images. "

Look at the following figure:

"The source boot image will be used as a template for the new capture image file. The

new capture image WIM file will be added in the location that you have specified.

The screen in the following figure will appear when the image creation has completed

successfully. Clear the Add Image To The Windows Deployment Server Now check box if

you have followed my advice on where to create the image. This option is used when you

have created the capture image in another location and want to add it to the correct

location."

Returning to the WDS console, you can right-click on you server and select Refresh.

Browse into Boot Images and you should see your new capture image. This is a new WIM

file that is independent of the source boot image and consumes disk space. You will

need to remember to update this capture image with any new driver packages that you

add from this point on. Remember that you may also need to have 32-bit and 64-bit

capture images.

You will now use this capture image to boot up the reference machine and capture the

generalized image.

How to Create An Image by Using a Capture Image

Power up the reference machine and boot it up on the network. Choose the capture boot

image when the PXE client starts.

The boot image will download over the network and start. You can skip the welcome

screen to get to the Directory To Capture screen, as shown in the following figures:

You have to enter three pieces of information. You should select the volume letter that

you want to capture using WDS. This highlights a limitation of WDS; you can only

capture and deploy a single volume. You might notice something odd here. The volume

we are capturing is shown as D:, even though it is the C: drive when the reference

machine is booted up. There is a handy solution you can use if you are a little confused

about the volume that you are capturing.

1. Start command prompt in Windows PE by pressing Shift+F10.

2. Navigate the volumes (cd) and list their contents to see which volume letter it is

that you need to select. You can so this using diskpart and by running the list

volume command.

3. Enter the image name and description as you want them appear in the WDS

console and to users when they are deploying images to their machines. You can

change the name and description later in the console.

4. The New Image Location screen is where you configure the location of the new

image that is to be created and if and how you want the image to be uploaded to

the WDS server.

5. Click Browse to select a location to create the new installation image in and to

name the file. You can create the new image on the same volume that you are

capturing if there is sufficient space. You will need an additional local (not

network-based) volume if there is not enough space.

6. Optionally select the option to upload the new image to the WDS server. If you do

want to do this, click the Connect button to authenticate with the WDS server.

Once you have entered valid credentials, you can select an Image Group to add

the new image to. This will use Single Instance Storage (SIS) to reduce the amount

of disk space that is needed to store the image. Make sure you choose an image

group that matches the operating system, edition, and architecture of your new

image.

The image is captured and will be uploaded to your WDS server if configured. The image

will then be available for further configuration (such as access permissions) and

deployment to other machines.

Note --> Remember that you will need to refresh the WDS console (if it was open already)

to see the new installation image.

VPN with RADIUS Authentication and Digital Certificates.

VPN:

Virtual private networks (VPNs) are point-to-point connections across a private or public

network, such as the Internet. The remote access server answers the call, authenticates

the caller, and transfers data between the VPN client and the organization’s private network.

Properties of VPN connections

VPN connections that use PPTP, L2TP/IPsec, and SSTP have the following properties:

● Encapsulation

● Authentication

● Data encryption

Encapsulation

With VPN technology, private data is encapsulated with a header that contains routing

information that allows the data to traverse the transit network. For examples of

encapsulation.

Authentication

Authentication for VPN connections takes three different forms:

1. User-level authentication by using PPP authentication

2. To establish the VPN connection, the VPN server authenticates the VPN client that

is attempting the connection by using a Point-to-Point Protocol (PPP) user-level

authentication method and verifies that the VPN client has the appropriate

authorization. If mutual authentication is used, the VPN client also authenticates

the VPN server, which provides protection against computers that are

masquerading as VPN servers.

3. Computer-level authentication by using Internet Key Exchange (IKE)

4. To establish an Internet Protocol security (IPsec) security association, the VPN

client and the VPN server use the IKE protocol to exchange either computer

certificates or a preshared key. In either case, the VPN client and server

authenticate each other at the computer level. Computer certificate authentication

is highly recommended because it is a much stronger authentication method.

Computer-level authentication is only performed for L2TP/IPsec connections.

5. Data origin authentication and data integrity

6. To verify that the data sent on the VPN connection originated at the other end of

the connection and was not modified in transit, the data contains a cryptographic

checksum based on an encryption key known only to the sender and the receiver.

Data origin authentication and data integrity are only available for L2TP/IPsec

connections.

Data encryption

7. To ensure confidentiality of the data as it traverses the shared or public transit

network, the data is encrypted by the sender and decrypted by the receiver. The

encryption and decryption processes depend on both the sender and the receiver

using a common encryption key.

8. Intercepted packets sent along the VPN connection in the transit network are

unintelligible to anyone who does not have the common encryption key. The

length of the encryption key is an important security parameter. You can use

computational techniques to determine the encryption key. However, such

techniques require more computing power and computational time as the

encryption keys get larger. Therefore, it is important to use the largest possible

key size to ensure data confidentiality.

RADIUS

After the Routing and Remote Access and Demand-Dial Interface wizards complete,

Windows authentication and Windows accounting are selected by default. You can

change these defaults from Windows authentication and Windows accounting to Remote

Authentication Dial-In User Service (RADIUS) authentication and RADIUS accounting, or

you can choose separate providers for authentication and accounting. For a deployment

that supports only a site-to-site connection, use Windows authentication and Windows

accounting. However, you can change these defaults if the same answering router will

support both the site-to-site connection and remote access users, and you want to use

RADIUS as either the authentication provider or the accounting provider.

Use the following procedures to accomplish these tasks:

Configure the authentication provider on the answering router

Configure the accounting provider on the answering router

Configure the authentication provider on the answering router

Configure either Windows authentication or RADIUS authentication. If you select RADIUS

authentication, add the answering router as a RADIUS client on the Network Policy

Server (NPS) server. For information about how to add the answering router as a RADIUS

client.

To use Windows Authentication

1. Open the Routing and Remote Access MMC snap-in.

2. Right-click the server name for which you want to configure authentication, and

then click Properties.

3. On the Security tab, in Authentication provider, click Windows Authentication.

To use RADIUS Authentication

1. Open the Routing and Remote Access MMC snap-in.

2. Right-click the server name for which you want to configure RADIUS

authentication, and then click Properties.

3. On the Security tab, in Authentication provider, click RADIUS Authentication, and

then click Configure.

4. In the RADIUS Authentication dialog box, click Add.

5. In the Add RADIUS Server dialog box, configure the settings for your RADIUS

authentication server, and then click OK.

Configure the accounting provider on the answering router

Configure either Windows accounting or RADIUS accounting. If you select RADIUS

accounting, add the answering router as a RADIUS client on the NPS server. For

information about how to add the answering router as a RADIUS client.

To use Windows Accounting

1. Open the Routing and Remote Access MMC snap-in.

2. Right-click the server name for which you want to configure Windows Accounting,

and then click Properties.

3. On the Security tab, in Accounting provider, click Windows Accounting, and then

click OK.

To use RADIUS Accounting

1. Open the Routing and Remote Access MMC snap-in.

2. Right-click the server name for which you want to configure RADIUS accounting,

and then click Properties.

3. On the Security tab, in Accounting provider, click RADIUS Accounting, and then

click Configure.

4. In the RADIUS Accounting dialog box, click Add.

5. In the Add RADIUS Server dialog box, configure the settings for your RADIUS

accounting server, and then click OK.

Certificate-based Authentication Protocols

Certificates are digital documents that are issued by certification authorities (CAs), such

as Active Directory Certificate Services (AD CS) or the VeriSign public CA.

Certificates are used for network access authentication because they provide strong

security for authenticating users and computers and eliminate the need for less secure

password-based authentication methods.

In this section

Certificate types

When you use certificate-based authentication methods, it is important to understand the

following types of certificates and how they are used:

● CA certificate

When present on client and server computers, tells the client or server that it can trust

other certificates, such as certificates used for client or server authentication, that are

issued by this CA. This certificate is required for all deployments of certificate-based

authentication methods.

● Client computer certificate

Issued to client computers by a CA and used when the client computer needs to prove its

identity to a server running NPS during the authentication process.

● Server certificate

Issued to NPS servers by a CA and used when the NPS server needs to prove its identity

to client computers during the authentication process.

● User certificate

Issued to individuals by a CA and typically distributed as a certificate that is embedded

on a smart card. The certificate on the smart card is used, along with a smart card reader

that is attached to the client computer, when individuals need to prove their identity to

NPS servers during the authentication process.