Friday, February 26, 2016

Install Hyper-V Inside Hyper-V VMs.

Introduction

In this article we show how to virtualize one Hyper-V machine on a VM with Hyper-V installed.

Following procedure is only for laboratories. This option is not supported by Microsoft.

Requirements

A physical host Hyper-V with a VM for preparation and installation of Hyper-V.

Procedure

In preparation of a laboratory you need to virtualize a machine on another virtual machine that is working with Hyper-V. When making the installation of Hyper-V VM presented in the error "Hyper-V can not be installed: The hypervisor is already running."

When attempting to install the Server Manager will display the error "Hyper-V can not be installed: The hypervisor is already running."



Good for this procedure you will be able to perform the installation via the PowerShell Feature. More you can not start the VM's with "Start Option".

In PowerShell type the following command "That will perform the installation of Hyper-V in online mode" most do not restart the equipment.

Enable-WindowsOptionalFeature –Online -FeatureName Microsoft-Hyper-V –All –NoRestart



This process will perform the installation of Hyper-V Tools.
Install-WindowsFeature RSAT-Hyper-V-Tools –IncludeAllSubFeature
Installing all Windows Cluster features.

Install-WindowsFeature RSAT-Clustering –IncludeAllSubFeature



Installing the feature Multipath-IO.
Install-WindowsFeature Multipath-IO
After that we will restart the server after all all package installations.
Restart-Computer
After the restart the VM you can now validate that the console Hyper-V has been installed and you can start to test their laboratories.


Wednesday, February 17, 2016

Securing a Connection with an SSL Certificate



SSL security technology protects most websites that deal with critical security data. SSL establishes a secure, encrypted link between a server and a  client. Most commonly, the connection is between a web server and a browser or email client on a client computer. SSL is commonly referred to as a security protocol, because it specifies algorithms for encryption and necessary variables for connection encryption. The purpose of securing a
connection with SSL is to protect data, such as credit card numbers, logon credentials, and other critical data, while the data transfers between a client and a server.


To establish a connection protected by SSL, you must install the certificate on the server. Your internal CA or a public CA can issue a certificate for SSL. For websites available on the Internet, it is common to have a certificate issued by a public CA because of the trust issues. Howev er, you can also use a certificate issued by your local CA. A connection can be secured with both types of  certificates, but most clients that connect to the website where the certificate is installed cannot trust an internally issued certificate. The fact that the certificate is untrusted will not prevent it from securing a connection, but it will present clients with a warning message when they connect to your website. Most companies want to avoid this, so the most secure websites on the Internet use public certificates. Internet browsers come with a preinstalled list of trusted CAs, and they store this list in the trusted root CA store.


 Note: Buying a public SSL certificate does not automatically guarantee that all clients will trust the certificate. Make sure that you choose a certificate vendor that is trusted globally and
has its CA certificates present in the client’s preinstalled trusted root CA store.




Securing a Connection with an SSL Certificate

 
Each certificate has a key pair associated with it after it is issued. The key pair consists of a public key and a private key. These keys work together in an encryption process. Data that is encrypted with a public key can be decrypted only with a corresponding private key, and vice versa. Each key pair is unique. Besides having a key pair, each certificate also has its subject name that specifies the identity of the server or website where the certificate is installed.
When a web browser connects to a secure website, the client and server establish an SSL connection. The SSL connection establishes during the SSL handshake. This handshake process occurs through the
following steps:
 


1. The user types or clicks an HTTPs URL in a web browser.
2. The web browser software connects to a website and requests for the server to identify itself.
3. The web server sends its SSL certificate. With the certificate, the server also distributes its public key to the client.
4. The client performs a check of the server certificate. It checks the subject name and compares it with the URL that it used to access the server. It also checks if any of the CAs in the trusted root CA store issue the certificate and it checks the certificate revocation list distribution point (CDP) locations to verify if the certificate is revoked.
5. If all checks pass, the client generates a symmetric encryption key. The client and server use a symmetric key for decrypting data because the public and private key pairs are not very efficient in
encrypting and decrypting large amounts of data. The client generates a symmetric key and then encrypts this key with the server’s public key. After that, the client sends the encrypted symmetric key to the server.
6. The server uses its private key to decrypt the encrypted symmetric key. Now both the server and the client have a symmetric key, and the secure data transfer can begin.


This process involves several very important checks. First, the server proves its identity to the client by presenting its SSL certificate. If the server name in the certificate matches the URL that the client requested, and if a trusted CA issues the certificate, the client trusts that the server has valid identity. The client has also checked the validity of the certificate by checking its lifetime and CDP location for the certificate revocation lists (CRLs). This means that establishing an SSL session does more than manage
encryption; it also provides authentication from a server to a client.
 


Note: Client authentication is not part of the classic SSL handshake. This means that a client does not have to provide its identity to the server. However, you also can configure your website to require client authentication. The client also can use a certificate to authenticate itself.


Note: A certificate can be issued only for a server name or alias, not for a full URL. For example, a certificate with the common name www.adatum.com will also protect URL  www.adatum.com/sales or similar.


Source :- MOC-20412  

How Client Computers Locate Domain Controllers Within Sites

When you join a Windows operating system client  to a domain and then restart it, the client  completes a domain controller location and registration process. The goal of this registration process is to locate the domain controller with the most efficient and closest location to the client’s location based on IP subnet information. The process for locating a domain controller is as follows: 





1. The new client queries for all domain controllers in the domain. As the new domain client restarts, it receives an IP address from a DHCP server, and is ready to authenticate to the domain. However, the client does not know where to find a domain controller. Therefore, the client queries for a domain controller by querying the _tcp folder, which contains the SRV records for all domain controllers in the domain.


2. The client attempts an LDAP ping to all domain controllers in a sequence. DNS returns a list of all matching domain controllers and the client attempts to contact all of them on its first startup.

3. The first domain controller responds. The first domain controller that responds to the client examines the client’s IP address, cross-references that address with subnet objects, and informs the client of the site to which the client belongs. The client stores the site name in its registry, and then queries for domain controllers in the site-specific _tcp folder.


4. The client queries for all domain controllers in the site. DNS returns a list of all domain controllers in the site.


5. The client attempts an LDAP ping sequentially to all domain controllers in the site. The domain controller that responds first authenticates the client.


6. The client forms an affinity. The client forms an affinity with the domain controller that responded first, and then attempts to authenticate with the same domain controller in the future. If the domain controller is unavailable, the client queries the site’s _tcp folder again, and again attempts to bind with the first domain controller that responds in the site.


If the client moves to another site, which may be the case with a mobile computer, the client attempts to authenticate to its preferred domain controller. The domain controller notices that the client’s IP address is associated with a different site, and then refers the client to the new site. The client then queries DNS for domain controllers in the local site
.



Source :- MOC-20412

Tuesday, February 16, 2016

OWA blank page | Exchange 2013, 2016


Symptoms


You try to log into Outlook Web App (or now called Outlook on the Web) using Exchange 2013 or 2016. You’re presented with a login screen then after you sign in, you are presented with a blank screen. This often happens after a restart or an upgrade. See below:

image

After logging in:

image


Cause


The cause of this is that the Exchange Back End site in IIS on your MBX server is no longer bound to a certificate (SSL certificate “Not Selected”). See below:

image

Resolution


To resolve this issue, open up IIS Manager on your Exchange server:

image

Then right click on Exchange Back End and click on Edit Bindings. You’ll be presented with a list of site bindings.

image

Double click on the https entry in the list. You should now see the below window:

image

In the SSL certificate drop down, select the Microsft Exchange certificate:

image

Click OK then click Close.

You should now be able to log into OWA:

image

Repeat for your other servers if needed.

Exchange 2013, 2016 - Autodiscover SRV record

In this post, I’ll demonstrate how to configure Exchange 2013 or 2016 to use an autodiscover SRV record instead of an A record.


How does an SRV record work with Exchange and Outlook?


Outlook 2007 and higher will attempt a number of different methods to find the autodiscover settings for your particular domain. The methods are tried in the order below and once an autodiscover response is received, no further methods are tried. In this example, our domain is litwareinc.com:
  1. Attempt to connect to the Service Connection Point in Active Directory. (This is configured using the Set-ClientAccessServer and the AutodiscoverServiceInternalUri parameter and specifies the URL to the autodiscover.xml file. It only works for domain-joined computers)
  2. Attempt to connect to https://litwareinc.com/autodiscover/autodiscover.xml
  3. Attempt to connect to https://autodiscover.litwareinc.com/autodiscover/autodiscover.xml 
  4. Attempt to locate the autodiscover.xml URL using the SRV method. (NB: Outlook 2007 requires the June 2007 update rollup: https://support.microsoft.com/en-us/kb/940881)
If none of these methods provides a valid autodiscover response then autodiscover fails.


What is an SRV record?


An example of an SRV record for Exchange 2010, 2013 or 2016 is below. In this example, our Exchange server namespace is mail.litwareinc.com.

Service: _autodiscover
Protocol: ._tcp
Port Number: 443
Host: mail.litwareinc.com
Priority: 0
Weight: 0

The Service name specifies the name of the service. For Exchange Autodiscover, this must be _autodiscover.

The Protocol informs the client whether this service uses TCP or UDP.


The Port number informs the client which port to connect on. 


The Host informs the client of the hostname it should be connecting to for this particular service. 


The Priority specifies which target server the client should connect to first. If two target servers have the same priority then the client looks at the weight for each and decides which to connect to based on which has the highest weight.


The Weight specifies the relative weight when priorities are the same. Larger weights have proportionately higher probability of being selected.



Remove the autodiscover A record


Removing the autodiscover.litwareinc.com A record means that clients will not be able to connect to this address. This is helpful as we now no longer need autodiscover.litwareinc.com as a name on our certificate and can use a single name certificate for Exchange to cut costs and simplify the namespace. 


Do I need autodiscover names on my certificate?


No, as long as there is no autodiscover.litwareinc.com A record in internal or external DNS, there is no need for this name on the certificate. As the client cannot resolve the IP, there is no way it can connect using this name. The client will then use the next method in the search for the autodiscover settings.




How to create an SRV record


Before you do this, ensure that you have set up an A record for mail.litwareinc.com in your internal and external DNS.

You need to create an SRV record in both your internal and external DNS. Use your DNS provider documentation to get instructions on how to set this SRV record up in you external DNS.

To create an SRV record in internal DNS, go through the steps below:

1) Log into a domain controller which hosts the litwareinc.com zone

2) Right click on the litwareinc.com zone and select Other New Records

image

3) Select Service Location (SRV) from the list

image

4) Click Create Record, enter the details below then click OK:

Service: _autodiscover
Protocol: _tcp
Port Number: 443
Host: mail.litwareinc.com
Priority: 0
Weight: 0

image

6) Check that your record appears by clicking on the _tcp subdomain under the litwareinc.com zone:

image

5) Check that your record was created successfully using nslookup

To do this, use the commands below:

nslookup
set q=srv
_autodiscover._tcp.litwareinc.com

image

Above, we can see that the SRV record exists and that it has provided the host mail.litwareinc.com.

Test Autodiscover


To check that it works, I have a client running Outlook 2013 that is not on the domain and we’ll go ahead and create a new Outlook profile:

image

image

image

We can see that we get this notification which states that we are redirected to mail.litwareinc.com which is as per our SRV record. 

image

We can select “Don’t ask me about this website again” so we are no longer prompted or you can add a registry entry to allow redirections to mail.litwareinc.com without prompting. See here for instructions on how to do that using regedit or deploy the setting using logon scripts or Group Policy.

image

This has worked and the account is set up correctly. We didn’t get an error to state that autodiscover.litwareinc.com is not on the certificate because this name is not used in the process.


Confirm settings using Outlook Test E-mail AutoConfiguration tool


To use this tool, see here. The results of the test can be seen below where we are getting a valid response:

image

If we click on the log tab, we can see the process that Outlook went through to get the autodiscover response. It fails on a number of different methods then eventually attempts the SRV record lookup and this provides the response.

image



Source :- http://markgossa.blogspot.in/search/label/Autodiscover