www.electricmonk.org.uk

Using Trusts in Windows environments

September 20, 2013 Forest Trusts No comments

What is a Trust?

A trust is a relationship, which you establish between domains, that makes it possible for users in one domain to be authenticated by a domain controller in the other domain.

By using Windows Server 2008 domain and forest trusts, service administrators can create or extend collaborative relationships between two or more domains or forests. Windows Server 2008 domains and forests can also trust Kerberos realms and other Windows Server 2008 forests, as well as Windows Server 2003 domains, Microsoft® Windows® 2000 Server domains, and Microsoft Windows NT® Server 4.0 domains.

When a trust exists between two domains, the authentication mechanisms for each domain trust the authentications coming from the other domain. Trusts help to provide controlled access to shared resources in a resource domain (the trusting domain) by verifying that incoming authentication requests come from a trusted authority (the trusted domain). In this way, trusts act as bridges that allow only validated authentication requests to travel between domains.

How a specific trust passes authentication requests depends on how it is configured. Trust relationships can be one-way, providing access from the trusted domain to resources in the trusting domain, or two-way, providing access from each domain to resources in the other domain. Trusts are also either nontransitive, in which case a trust exists only between the two trust partner domains, or transitive, in which case a trust automatically extends to any other domains that either of the partners trusts.

In some cases, trust relationships are established automatically when domains are created. In other cases, administrators must choose a type of trust and explicitly establish the appropriate relationships. The specific types of trusts that are used and the structure of the resulting trust relationships in a given trust implementation depend on such factors as how Active Directory Domain Services (AD DS) is organized and whether different versions of Windows coexist on the network.

The key thing to remember is that the direction of trust is the opposite to the direction of access. An outgoing trust allows incoming access and an incoming trust allows outgoing access

Trust Directions

One-way: incoming

Use this option when you want to allow authentication requests to be routed from your domain or forest (referred to as “this domain” or “this forest” in the wizard) to resources residing in a second domain or forest (referred to as “specified domain” or “specified forest” in the wizard). “One-way” in One-way: incoming means that this selection will create a one-way trust that can route authentications to resources in only one direction, while user access to those resources flows in the other direction. “Incoming” in One-way: incoming refers to the direction of the trust itself, not the direction in which authentication requests will flow. In other words, as shown in the following illustration, a “one-way incoming trust” means that your domain or forest will be the domain or forest that receives access to the resources in the other domain.

One way:Outgoing

Use this option when you want to allow authentication requests to be routed to your domain or forest (referred to as “this domain” or “this forest” in the wizard) from users residing in a second domain or forest (referred to as “specified domain” or “specified forest” in the wizard). “One-way” in One-way: outgoing means that this selection will create a one-way trust that can route authentications to resources in only one direction, while user access to those resources flows in the other direction. “Outgoing” in One-way: outgoing refers to the direction of the trust itself, not the direction in which authentication requests will flow. In other words, as shown in the following illustration, a “one-way, outgoing trust” means that your domain or forest will provide access to resources that are located in your domain to users who are located in the other domain or forest.

Types of Trust

When to create an external trust

You can create an external trust to form a one-way or two-way, nontransitive trust with domains that are outside your forest. External trusts are sometimes necessary when users need access to resources in a Windows NT 4.0 domain or in a domain that is located in a separate forest that is not joined by a forest trust

When to create a shortcut trust

Shortcut trusts are one-way or two-way, transitive trusts that administrators can use to optimize the authentication process.

Authentication requests must first travel a trust path between domain trees. In a complex forest this can take time, which you can reduce with shortcut trusts. A trust path is the series of domain trust relationships that authentication requests must traverse between any two domains. Shortcut trusts effectively shorten the path that authentication requests travel between domains that are located in two separate domain trees

When to create a realm trust

You can establish a realm trust between any non-Windows Kerberos version 5 (V5) realm and an Active Directory domain. This trust relationship allows cross-platform interoperability with security services that are based on other versions of the Kerberos V5 protocol, for example, UNIX and MIT implementations. Realm trusts can switch from nontransitive to transitive and back. Realm trusts can also be either one-way or two-way.

When to create a forest trust

You can create a forest trust between forest root domains if the forest functional level is Windows Server 2003 or higher. Creating a forest trust between two root domains with a forest functional level of Windows Server 2003 or higher provides a one-way or two-way, transitive trust relationship between every domain in each forest. Forest trusts are useful for application service providers, organizations undergoing mergers or acquisitions, collaborative business extranets, and organizations seeking a solution for administrative autonomy.

Using one-way, forest trusts

A one-way, forest trust between two forests allows members of the trusted forest to use resources that are located in the trusting forest. However, the trust operates in only one direction. For example, when a one-way, forest trust is created between forest A (the trusted forest) and forest B (the trusting forest), members of forest A can access resources that are located in forest B, but members of forest B cannot access resources that are located in forest A, using the same trust.

Using two-way, forest trusts

A two-way, forest trust between two forests allows members from either forest to use resources that are located in the other forest, and domains in each respective forest trust domains in the other forest implicitly. For example, when a two-way, forest trust is established between forest A and forest B, members of forest A can access resources that are located in forest B, and members of forest B can access resources in forest A, using the same trust.

Checklist for creating Trusts

Ensure that DNS is set up properly.
If there is a root DNS server that can be the root DNS server for both of the forest DNS namespaces, make it the root server by ensuring that the root zone contains delegations for each of the DNS namespaces. Also, update the root hints of all DNS servers with the new root DNS server
If there is no shared root DNS server and the root DNS servers for each forest DNS namespace are running a Windows Server operating system, configure DNS conditional forwarders in each DNS namespace to route queries for names in the other namespace.
If there is no shared root DNS server and the root DNS servers for each forest DNS namespace are not running a Windows Server operating system, configure DNS secondary zones in each DNS namespace to route queries for names in the other namespace.
Create the forest trust.

Permissions

Permissions required to create trusts is domain admin or enterprise admin group.

What tool do you use to create Trusts?

You can use the Active Directory Domains and Trusts snap-in to create trust relationships between domains by going Start > All Programs > Administrative Tools > Active Directory Domains and Trusts. Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure.

Creating a Forest Trust

Open Active Directory Domains and Trusts. To open Active Directory Domains and Trusts in Windows Server® 2012, click Start , type domain.msc

In the console tree, right-click the domain that you want to administer, and then click Properties. Check your Domain and Forest Functional Level

Click Trusts

On the Trusts tab, click New trust, and then click Next

On the Trust Name page, type the Domain Name System (DNS) name (or NetBIOS name) of the domain, and then click Next

On the Trust Type page, click Forest trust, and then click Next

Choose the Direction of the trust

Next you will need to create the sides of the trust relationship

Specify the user name and password of the Active Directory domain administrator, then click Next.

Select Forest-wide authentication to authorize users to use resources in the local forest or those identified by the administrator, then click Next.

Select Forest-wide authentication to authenticate Active Directory forest users to use resources in the forest or those identified by the administrator, then click Next.

Trust creation complete. Review your settings

Confirm Outgoing Trust

Confirm Incoming Trust

Complete the new trust wizard

Verifying the Trust

To verify that the DNS configuration is correct there are several commands you can run in a command prompt or Firewall.

nslookup
netdom
nltest

Common ports which need to be open for trusts to work

123/UDP – W32Time
135/TCP – RPC Endpoint Mapper
464 – Kerberos password change
49152-65535/TCP – RPC for LSA, SAM, Netlogon (*)
389/TCP/UDP – LDAP
636/TCP – LDAP SSL
3268/TCP – LDAP GC
3269/TCP – LDAP GC SSL
53/TCP/UDP – DNS
49152 -65535/TCP – FRS RPC (*)
88/TCP/UDP – Kerberos
445/TCP – SMB
49152-65535/TCP – DFSR RPC (*)

(*) For information about how to define RPC server ports that are used by the LSA RPC services, see the following Microsoft Knowledge Base articles:

224196: Restricting Active Directory replication traffic and client RPC traffic to a specific port
“Domain controllers and Active Directory” section in 832017: Service overview and network port requirements for the Windows Server system

Port Query Tool

Microsoft do a port query tool which is really useful for checking connectivity

http://www.microsoft.com/en-us/download/confirmation.aspx?id=24009

SQL Server 2012 Installable Features

August 29, 2013 SQL Server No comments

It’s often good to have a brief explanation of the features that are installable through the SQL 2012 Wizard so here they are below for reference

Database Engine

Includes the Database Engine, the core service for storing, processing and securing data. The Database Engine provides controlled access and rapid transaction processing and also provides rich support for sustaining high availability. The Database Engine also provides support for the utility control point in the SQL Server Utility. Only Database Engine Services and Analysis Services can be clustered.

SQL Server Replication

Includes a set of technologies for copying and distributing data and database objects from one database to another and synchronizing between the databases for consistency. You can use replication to distribute data to different locations and to remote and mobile users over local and wide area networks, dial-up connections, wireless connections and the Internet.

Full Text Search

Includes the Search engine that supports Full-Text Extraction for fast text search as well as Semantic Extraction for key phrases (likely tags) and similarity search on content stored in SQL Server. Data Quality Service: -Includes Data quality database objects.

Analysis Services

Includes Analysis Services and tools used to support online analytical processing (OLAP) and data mining. Only Database Engine Services and Analysis Services can be clustered.

Reporting Services – Native

Includes Reporting Services, a server-based application for creating, managing, and delivering reports to email, multiple file formats, and interactive Web-based formats. The Native mode server provides all processing and management functionality through Reporting Services components. Reporting Services cannot be clustered.

Shared Feature

Each shared feature is installed once within a defined scope and operates within that scope. The defined scope can span all SQL Server versions on a computer (e.g., SQL Server Browser), can be isolated to one major version of SQL Server (e.g., SQL Server Management Tools), or can be isolated to one or more minor versions.

Reporting Service – Shared

Includes Reporting Services, a server-based application for creating, managing, and delivering reports to email, multiple file formats, and interactive Web-based formats. SharePoint integrated mode integrates the report server with SharePoint products. The report viewing and report management experience are integrated with SharePoint sites and libraries. Reporting Services cannot be clustered.

Reporting Services Add in

Includes management and user interface components to integrate a SharePoint product with an SSRS report server in SharePoint integrated mode. The add-in only needs to be installed on server running a SharePoint product.

Data Quality

Includes Data quality client objects.

SQL Server Data Tools

Installs the SQL server development environment, including the tool formerly named Business Intelligence Development Studio. Also installs the business intelligence tools and references to the web installers for database development tools.

Client Tools Connectivity

Includes components for communication between clients and servers.

Integration Services

Includes the designer, runtime, and utilities that enable Integration Services to move, integrate, and transform data between data stores.

Client Tools SDK

Includes the software development kit containing resources for programmers.

Documentation Component

Installs only the components that you use to view and manage the documentation for SQL Server 2012. By default, the Help Viewer component uses the online library. After installing SQL Server, you can use the Help Library Manager component to download documentation to your local computer.

Management Tool – Basic

Includes Management Studio support for the Database Engine and SQL Server Express, SQL Server command-line utility (SQLCMD), SQL Server PowerShell provider, and Distributed Replay Administration Tool.

Management Tool – Complete

Adds the following components to the basic management tools installation: Management Studio support for Reporting Services, Analysis Services, and Integration Services technologies, SQL Server Profiler, Database Tuning Advisor, and SQL Server Utility management.

Distributed Replay Controller

Includes the Distributed Replay Controller which orchestrates the actions of the distributed replay clients.

Distributed Replay Client

Includes the Distributed Replay Client. Multiple Distributed Replay Clients work together to simulate a workload against an instance of SQL Server.

SQL Client Connectivity SDK

Includes SQL Server Native Client (ODBC / OLE DB) SDK for database application development.

Master Data Services

Includes Master Data Services, the platform for integrating data from disparate systems across an organization into a single source of master data for accuracy and auditing purposes. Installs the Master Data Services Configuration Manager, assemblies, PowerShell snap-in, and folders and files for Web applications and services.

Redistributable Features

SQL Server redistributable and shared features are installed when needed: Error and Usage Reporting, SQL Server Native Client, MSXML version 6.0, Sync Services for ADO.NET, and SQL Server Browser.

VCAP-DCA 5 Exam Experience

August 27, 2013 VCAP5 DCA No comments

Here is my overview of how my VCAP-DCA 5 exam went. Hopefully I can give you some helpful pointers bulleted below

Quick Overview

26 Live labs consisting of several tasks to complete
3.5 Hours to complete the exam
A short survey pre exam on your VMware skills
You have some VMware Documentation to assist you

Things to remember

You need to be quick. I found 3.5 Hours is very tight for time giving you roughly 8 minutes per question
Try and memorize the Admin password, it will save you from flicking between screens
Use the icons to connect to servers, don’t RD into vCenter then use the client.
If you can’t answer something, don’t waste time, move on to the next question
If you have set something to run which is taking some time, don’t hang around, move on to the next task or question if you can
I found sometimes the lab wasn’t the fastest when changing between screens but I understand there isn’t a lot anyone can do about this and is probably down to how fast the testing Center connection is
You can only go backwards and forwards so keep a note of what questions you want to go back to on your pad you are given by the test center
You have got documentation but you don’t have much time to go raking through this unless you absolutely know where something is
It is almost vital that you build your own lab to test out all the Blueprint points
Read as much documentation as you can
Read other peoples blogs and experiences
The Trainsignal videos are really useful as preparation for this exam
Read the questions and make sure you haven’t missed any of the tasks which they are asking you to do or not do!
The VMware Optimize and Scale class is also very useful but expensive
I found this to be one of the best exams I have taken. It was a real world exam and far more useful than simply answering multiple choice
Don’t panic, just imagine you are at your desk at work
Understand basic PowerShell
If you have any issues, report them quickly so the test center can contact VMware and let them know. I had one issue with my test and the lady was very quick in assisting me and letting me get back to the exam as quickly as possible

Optimising SQL Server for VMware vCenter

July 19, 2013 SQL Server, vCenter No comments

SQL Modifications

I am using Microsoft SQL Server 2008 R2 running on Microsoft Windows Server 2008 R2. It is always worth having some knowledge about your Database software whether it be Oracle, SQL or DB2 etc and worth knowing how to optimise this software to work correctly for VMware vCenter whilst maintaining backups and maintenance plans for further minimization of issues and/or performance problems

Memory

Right-click the topmost SQL Server object, usually named with the machine name or local.
Choose Properties.
Choose the Memory page.
Set “Maximum Server Memory (in MB)” to something useful for the server. Probably something like 25%-50% of the RAM on the host.
The more memory you can give it the better, as the database will cache data in RAM, but you also want to leave room in RAM for the OS (2 GB) and some file cache.

Recovery Model

Right-click the relevant Database in SQl Management Studio
Click Properties
Select Options
Set the Recovery Model to “Simple.” Click OK.

Configure Microsoft SQL Server TCP/IP for JDBC

If the Microsoft SQL Server database has TCP/IP disabled and the dynamic ports are not set, the JDBC connection remains closed. The closed connection causes the vCenter Server statistics to malfunction. You can configure the server TCP/IP for JDBC.

This task applies to remote Microsoft SQL Server database servers. You can skip this task if your database is local.

Select Start > All Programs > Microsoft SQL Server > Configuration Tool > SQL Server Configuration Manager
Select SQL Server Network Configuration
Protocols for Instance name
Enable TCP/IP
Open TCP/IP Properties and set the entries as per the below screen print
Click on the IP Addresses tab

Restart the SQL Server service from SQL Server Configuration Manager > SQL Server Services.
Start the SQL Server Browser service from SQL Server Configuration Manager > SQL Server Services.

Maintenance of your SQL Server Databases

Start the Microsoft SQL Server Management Studio again and log in as the sa user. Open the Management folder.

Right-click Maintenance Plans. Select Maintenance Plan Wizard.

Click Next
On the Select Plan Properties page give it the name WeeklyMaintenancePlan. Select Single schedule for the entire plan or no schedule

Click the Change button to pick when you want it to run.

Schedule the job to occur when there is little occurring on the system. E.g No backups or antivirus scanning
Click Next and choose your Maintenance Tasks

Select the order for the Maintenance Tasks to run in

For Define Database Integrity Check Select All databases, including indexes.
You have the choices below

Click OK and it will bring you back to the Define Database Integrity Check

For Define Reorganize Index select All databases, compact large objects.

For Define Rebuild Index select All Databases, reorganize pages with the default amount of free space. Also check Keep index online while reindexing. Note: The Keep index online option appears to be an Enterprise version feature, and you may see failures with it enabled on other SQL Server versions.

For Define Update Statistics select All Databases, all existing statistics, full scan

Next on the Define Backup Database (Full) Task, enter the following

Backup Type = Full
Databases = All Databases
Backup Set will expire after = 14 Days
Backup to Disk = Selected
Create a backup file for every Database = Selected
Choose a folder according to where you want to back up
Backup File Extension = bak
Set backup compression = Use the default server settings. The Compress Backup option seems like a good one but it isn’t supported on 64-bit SQL Server. It’ll let you set it, then fail on execution
Next Define Maintenance Cleanup Task

Delete files of the following type = Backup Files
Search Folder and delete files based on an extension = Choose your backup folder
File extension = bak
File age = 4 weeks or your choice
Next you are on to the Report Options Page

Check the Summaries and Click Finish

Go into the Maintenance Plans folder now, right click on this job, and choose Execute to see if it runs. Check the logs if it doesn’t.
Your location may be different but as a rough guide, the log location is c:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Log

Defragmenting VirtualCenter performance data indexes on a Microsoft SQL database

For troubleshooting or maintenance purposes it may be necessary to defragment the indexes on your Microsoft SQL database server.
Fragmentation of indexes occurs when the logical order of pages is different from the physical order on the disk. In VirtualCenter fragmentation occurs most noticeably due to the statistics collection and consolidation.

When the indexes are excessively fragmented, performance of queries to the VirtualCenter database is slow.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003990

Warning: If you do not have experienced DB administrators, shutdown the VMware VirtualCenter Server service and do a backup prior to performing any kind of database maintenance. If you have experienced DB administrators you can do the tasks online

Regular Reorganize Database Task

One of the performance suggestions buried in the VMware KB is to regularly reorganize the indexes, since the historical statistics tables get unwieldy. You can do this manually or schedule a job to do it by running the Maintenance Plan Wizard. Choose only Reorganize Indexes and set the schedule to recur every six hours, every day (or however often you want.This keeps the logical fragmentation of the indices down.

Click through the pages of the wizard until you get to “Define Reorganize Index Task.” Have it only reindex VCDB, choose “Tables and views” in the Object selection, and check “Compact large objects.” Click through until you’re done.

Using VMware’s Host Agent Pre Upgrade Checker and Database Pre Upgrade Checker

July 17, 2013 Upgrading No comments

About the vCenter Host Agent Pre-Upgrade Checker

The vCenter Host Agent Pre-Upgrade Checker produces a report showing known issues that might prevent a successful upgrade of the vCenter Host Agent software.

To ensure a successful upgrade to vCenter Server 5, you must diagnose and fix any potential problems on the managed ESX/ESXi hosts. You can run the vCenter Host Agent Pre-Upgrade Checker for in-place upgrades from vCenter Server 4.x to vCenter Server 5.0

vCenter Host Agent runs on all managed ESX/ESXi hosts. This software coordinates actions received from vCenter Server. When you add a host to vCenter Server, the agent is installed on the physical ESX/ESXi host. When you upgrade to vCenter Server 5, the agent residing on each ESX/ESXi host must be upgraded as well.

During a vCenter Server upgrade, the existing agent software is uninstalled and the updated agent software is installed in its place. If the upgrade fails, the updated agent software might not be installed and the host might become unreachable by VirtualCenter 2.5 Update 6 or later, vCenter Server 4.x, or by vCenter Server 5.0. To avoid this condition, you can run the vCenter Host Agent Pre-Upgrade Checker before you try to upgrade to vCenter Server 5.

The vCenter Host Agent Pre-Upgrade Checker checks to make sure that the agent software is ready to be upgraded. Some of the checks include checking to make sure that the host is reachable, the disk space is sufficient, the network is functioning, the file system is intact, and required patches are applied. Each time you run the tool, the system queries VMware.com and downloads any new updates for the tool. This action ensures that as new upgrade issues are discovered, the tool remains as useful as possible

Important

A successful vCenter Host Agent pre-upgrade check does not guarantee a successful upgrade to vCenter Server 5. An upgrade to vCenter Server involves multiple components, and the tool checks only one component: the vCenter Host Agent. Also, the tool checks only known issues. Other issues might be present that the tool does not check.

The vCenter Host Agent Pre-Upgrade Checker does not fix the reported issues. You must resolve the reported issues manually and rerun the tool to verify that the issues are resolved.

Run the vCenter Host Agent Pre-Upgrade Checker

Prerequisites

Verify that VirtualCenter 2.5 Update 6 or later or vCenter Server is installed on a Windows machine that is supported by vCenter Server 5.
Verify that the VirtualCenter 2.5 Update 6 or vCenter Server machine has a DSN configured that is compatible with vCenter Server 5.
Verify that the VirtualCenter 2.5 Update 6 or vCenter Server database is supported by vCenter Server 5. If necessary, upgrade the database to work with vCenter Server 5. The MSDE database was supported in experimental mode in VirtualCenter Server 2.0.x, but is not supported in vCenter Server 5. The vCenter Host Agent Pre-Upgrade Checker will not detect the database. Upgrade to a supported database before using the tool. See Supported Database Upgrades.
Verify that the ESX/ESXi hosts are managed by VirtualCenter 2.5 Update 6 or later or by vCenter Server. Verify that VirtualCenter Agent or vCenter Host Agent software is running on each managed ESX/ESXi host.
Verify that Microsoft .NET Framework Version 2.0 is installed on the VirtualCenter 2.5 Update 6 or later system.
Verify that you have Internet connectivity from the VirtualCenter 2.5 Update 6 or later or vCenter Server system. This allows new updates to be applied to the tool and allows you to view the reports and the Knowledge Base (KB) articles associated with the reports.

Procedure

On the VirtualCenter 2.5 Update 6 or later or vCenter Server system you are upgrading from, download the vCenter Server 5 installation package or insert the vCenter Server 5 installation DVD. Take one of the following actions to start the Pre-Upgrade Checker.

In the installation package or on the DVD, navigate to \vpx\agentupgradecheck and run the AgentUpgradeChecker.exe executable file.
Start the vCenter Server installer autorun.exe and select vCenter Host Agent Pre-Upgrade Checker from the Utility list.

Next

Select the DSN for the VirtualCenter or vCenter Server system you are upgrading from and select the login credentials that are appropriate for that DSN.
If you are not sure which credential type to select, check which authentication type is configured for the DSN (Control Panel > Administrative Tools > ODBC Data Sources > System DSN). If the DSN requires a login for the credential type in use, enter a user name and password and click Next.
Select an option for scanning all hosts or specific hosts.

Click Run Precheck.The tool takes 30-40 seconds for each host.
When the check is complete, click Next.
View the pre-upgrade reports.
To view the report for an individual host, click the link next to the host name.
To view a summary report for all hosts, click View Report.

You have a list of issues to resolve before you upgrade to vCenter Server 5

From the report, use the linked KB articles to research and resolve the issues for each host. After you resolve the issues, rerun the vCenter Host Agent Pre-Upgrade Checker. Repeat this process until you resolve all the reported issues, and proceed with your upgrade to vCenter Server 5.

VMware’s Database Pre Upgrade Checker

Before you upgrade vCenter Server, you can run the VMware vCenter Server Database Pre-Upgrade Checker on your current vCenter Server database to reveal problems that could prevent the upgrade or affect the performance of your database after the upgrade. You can use the Pre-Upgrade Checker for these upgrades:

On a VirtualCenter 2.5 Update 6 or later database before you upgrade to vCenter Server 4.x.
On a vCenter Server 4.0.x database before you upgrade to vCenter Server 4.1.x, 5.0.x, or 5.1.x.
On a vCenter Server 4.1.x database before you upgrade to vCenter Server 5.0.x or 5.1.x.
On a vCenter Server 5.0.x database before you upgrade to vCenter Server 5.1.x.

Note: You do not need to run the Pre-Upgrade Checker for minor update releases: for example, from version 4.0 to version 4.0 Update 3.

What the Pre-Upgrade Checker Checks

The Pre-Upgrade Checker compares your VCDB database signature profile with a known correct standard for your VCDB database version. A database signature profile is a representation of database structure and dependent objects. The Pre-Upgrade Checker creates a signature profile configuration file for your existing (pre-upgrade) database and compares it with the known correct signature profile for your VCDB database version. If the Pre-Upgrade Checker identifies a difference between your database signature profile and the known VCDB signature profile, the check fails. If your VCDB database signature profile matches the known signature profile, the check verifies that your database can be upgraded.

The Pre-Upgrade Checker also performs these checks.

Check for multiple schemas in the customer database.
Database user and role check. Checks that the given database user has the correct privilege to upgrade.
Table and structure check. No data checks are included in this check.
SQL compatibility mode check for Microsoft SQL Server. Determines whether the compatibility mode is set to an appropriate and supported level.

The Pre-Upgrade Checker outputs a single .zip file, which contains both the database signature file and the message log from running the Pre-Upgrade Checker.

Note: The Pre-Upgrade Checker works only with vCenter Server installations on Windows. The Pre-Upgrade Checker does not work with the vCenter Server Appliance

VMware Link

Follow this link for install and further information

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2004286

Installing SSO as part of the vSphere 5.x Upgrade process

July 12, 2013 SSO No comments

SSO

vSphere 5.1 introduces vCenter Single Sign On as part of the vCenter Server management infrastructure. This change affects vCenter Server installation, upgrading, and operation. Authentication by vCenter Single Sign On makes the VMware cloud infrastructure platform more secure by allowing the vSphere software components to communicate with each other through a secure token exchange mechanism, instead of requiring each component to authenticate a user separately with a directory service like Active Directory

How vCenter Single Sign-On Affects vCenter Server Upgrades

When you upgrade to vCenter Server 5.1, the upgrade process installs vCenter Single Sign-On first and then upgrades vCenter Server.
In upgrades to vCenter Server versions earlier than vCenter Server 5.1, both the local operating system users and Active Directory users that are registered with vCenter Server before the upgrade continue to work with the upgraded vCenter Server. This behavior changes in vCenter Server 5.1.
In vCenter Server 5.1, if vCenter Single Sign-On is running on a virtual machine or physical machine that is joined to an Active Directory domain, Single Sign-On will automatically discover the existing Active Directory domain and add it as an identity source during the Single Sign-On installation process. If Single Sign-On is not running on a virtual machine or physical machine that is in the same domain as Active Directory, you must use the vSphere Web Client to log in to vCenter Server and add the Active Directory domain to Single Sign-On.
If you install vCenter Single Sign-On and vCenter Server on the same physical machine or virtual machine, Single Sign-On recognizes existing local operating system users. After the upgrade, you can log in to vCenter Server with a registered local operating system user ID.
If you install vCenter Single Sign-On and vCenter Server on different hosts or virtual machines, the former local operating system users who managed login access to vCenter Server are not available to Single Sign-On.
When you install vCenter Single Sign-On in multisite mode or clustered high availability mode, all pre-upgrade permissions for local operating system users are lost. In vCenter Server 5.1, the term “local operating system users” refers to those local users in the Single Sign-On host machine instead of the vCenter Server host machine or virtual machine.
After the upgrade, if no super administrator remains (the administrative user or group for the root folder), you must provide a valid user or group to be used as super administrator during installation. This situation can occur due to changes in user stores from pre-5.1 to 5.1 versions of vSphere.

vCenter Single Sign-On Deployment Modes

vCenter Server provides several ways to deploy vCenter Single Sign-On to best serve your vSphere environment

You can deploy vCenter Single Sign-On in one of three modes.

Basic

Basic Mode installs a standalone version of vCenter Single Sign-On. Multiple vCenter Server and Inventory Service instances can point to it. If the Single Sign-On server or the virtual machine hosting the server fails, administrators cannot access vCenter Server, but ESXi hosts continue to function normally. Multiple Active Directory and OpenLDAP instances can be added as identity sources.

High Availability Cluster

Cluster Mode installs to two or more vCenter Single Sign-On Instances in High Availability mode. All instances use the same database and point to the same identity sources. Single Sign-On administrator users, when connected to vCenter Server through the vSphere Web Client, will see the primary Single Sign-On instance.

Multisite

Multisite is designed for deployments with multiple physical locations. Installing a Single Sign-On instance at each site allows fast access to local authentication-related services. Each Single Sign-On instance is connected to the local instances of the AD (LDAP) servers and has its own database with local users and groups. In each datacenter, you can install Single Sign-On in standalone or clustered mode, pointing to the identity sources in that location.

Multisite deployment is useful when a single administrator needs to administer vCenter Server instances that are deployed on geographically dispersed sites. To view all vCenter Server instances from a single vSphere Web Client, you must configure the vCenter Server instances in Linked Mode.

vCenter Single Sign On Components

vCenter Single Sign On includes these components: STS (Security Token Service), an administration server, vCenter Lookup Service, and the RSA SSPI service.

When you install vCenter Single Sign-On, the following components are deployed.

STS (Security Token Service)

The STS service issues Security Assertion Markup Language (SAML) tokens. These security tokens pass information about a system user between an identity provider and a web service. This service enables a user who has logged on through vCenter Single Sign-On to use multiple web-service delivered applications without authenticating to each one.

Administration Server

The Administration Server configures the vCenter Single Sign-On server and manages users and groups.

vCenter Lookup Service

The Lookup Service contains topology information about the vSphere infrastructure, enabling vSphere components to connect to each other securely.

RSA SSPI service

The Security Support Provider Interface ia a Microsoft Windows based API used to perform authentication against Security Support Providers such as NTLM and Kerberos.

Identity Sources for vCenter Server with vCenter Single Sign On

vCenter Server 5.1 with vCenter Single Sign On adds support for several new types of user repository. vCenter Server versions earlier than version 5.1 supported Active Directory and local operating system users as user repositories. vCenter Server 5.1 supports the following types of user repositories as identity sources.

Active Directory
OpenLDAP
Local operating system
System

Required vCenter Single Sign-On Database Users

When you use an existing database rather than the database bundled with vCenter Single Sign-On, the installation process requires database users with certain permissions.

When you install Single Sign-On installation using an existing database, the installer requires you to enter the user names and passwords of an existing database administrator and a database user.

When you install Single Sign-On with the bundled Microsoft SQL Server 2008 R2 Express database, the installer creates two users:

A database administrator user (for example, RSA_DBA) and password, which are used to set up the Single Sign-On database schema.
A database user (for example, RSA_USER) and password, which are used to perform certain steps after the installation. The installer prompts you to enter the passwords for these users.

The RSA_DB is used for creating the schema (DDL) and requires DBO Permissions. RS_USER reads and writes data (Only DML)

Prerequisite for the vCenter Single Sign On Database

Create a vCenter Single Sign On database, unless you plan to install the bundled database.
If you are using an existing database with your vCenter Single Sign-On installation or upgrade, make sure that the table spaces are named RSA_DATA and RSA_INDEX. Any other table space names will cause the vCenter Single Sign-On Installation to fail.
If you are using an existing database for Single Sign On, to ensure that table space is created for the database, run the script rsaIMSLiteDBNameSetupTablespaces.sql. The script is included in the vCenter Server installer download package, at

vCenter Server Installation directory\Single Sign On\DBScripts\SSOServer\Schema\msssql

You can run the script prior to the vCenter Server upgrade, or during the upgrade, when you are prompted by the Single Sign On installer. You can leave the installer to run the script, and resume the installer after you run the script.
If you are using an existing database for Single Sign On, you must create a database user (RSA_USER) and database administrator (RSA_DBA) to use for the Single Sign On database installation and setup. To create these users, run the script rsaIMSLiteDBNameSetupUsers.sql. The script is included in the vCenter Server installer download package, at

vCenter Server Installation directory\Single Sign On\DBScripts\SSOServer\Schema\msssql

Procedure

Log into your SQL Management Server
Open SQL Management Studio
Double click on the first script

This will automatically open in SQL Management Studio
Read the notes at the top of the script
There are several places you need to change paths according to your environment – see below where it says CHANGE ME

Next Click Execute on the SQL Management Studio Toolbar
It should say Command(s) completed successfully and you should see the newly created RSA Database

Next double click on the second script

This will open in SQL Management Studio and you will need to modify the passwords as you require as per below

Click Execute
It should say Command(s) completed successfully
You should now see the following permissions set on the RSA Database Properties

And check the Default Security in SQL Management Studio to make sure your users have been created

Check the Properties of the RSA_USER account
Make sure it is mapped to the RSA Database

Check the Properties of the RSA_DBA account
Make sure it is mapped to the RSA Database

Procedure following the vCenter SQL Scripts

In the software installer directory, double-click the autorun.exe file to start the installer.
Select vCenter™Single Sign On and click Install.

Follow the prompts in the installation wizard to choose the installer language

Agree to the end user patent and license agreements.

Select Create the primary node for a new Single Sign On installation.

Select Install basic vCenter Single Sign On. Note: Even if you don’t want multiple instances now, you may want them in the future therefore you can keep your options open by selecting the second option – “Create the primary node for a new vCenter Single Sign-On installation

Set the password for the vCenter Single Sign-On administrator account.
The password must have at least eight characters, at least one lowercase character, one uppercase character, one number, and one special character.

Select the database type for vCenter Single Sign-On. I am going to use “Use an existing supported database”

Enter in the details of your previously created SSO DB and relevant users. If you are using an existing database, enter the JDBC connection information.

If you get the following error, do the following

Go to SQL Server Configuration Manager > SQL Server Network Configuration > Protocols for MSSQLSERVER. Double click on TCP/IP and make sure under IPAll, you have the correct SQL Port number.

and you will get this box

Note: I had another SQL Instance using 1433 which I had to change to another port number then change my MSSQLSERVER Instance TCP Port to 1433. Note: Restart the relevant services following these changes
Also check the following setting. Go to SQL Server Configuration Manager > SQL Server Network Configuration > Right click on Protocols for MSSQLSERVER. Force encryption should be No at the moment

Enter the FQDN or IP address for the vCenter Single Sign-On host machine.

(Optional) Enter the SSPI service account information.

You can use the default Windows NetworkService account, or enter the account information for a administrator user. This step applies only if you logged in as a domain account user to install Single Sign-On.
Choose a destination folder for installation

Choose your SSL Port

Ready to Install > Click Install

Useful Video Walkthrough courtesy of Christopher Wahl

http://wahlnetwork.com/2013/02/04/successfully-installing-vcenter-sso-part-1-sql-database/

VMware SSO FAQ

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2034918

Cloning Virtual Machines in VMware

July 11, 2013 Cloning No comments

Understanding Clones

A clone is a copy of an existing virtual machine. The existing virtual machine is called the parent of the clone. When the cloning operation is complete, the clone is a separate virtual machine — though it may share virtual disks with the parent virtual machine.

Changes made to a clone do not affect the parent virtual machine. Changes made to the parent virtual machine do not appear in a clone.

A clone’s MAC address and UUID are different from those of the parent virtual machine.

If you want to save the current state of the virtual machine, so you can revert to that state in case you make a mistake, take a snapshot. If you want to make a copy of a virtual machine for separate use, create a clone.

Full and Linked Clones

There are two types of clone:

A full clone is an independent copy of a virtual machine that shares nothing with the parent virtual machine after the cloning operation. Ongoing operation of a full clone is entirely separate from the parent virtual machine.

A linked clone is a copy of a virtual machine that shares virtual disks with the parent virtual machine in an ongoing manner. This conserves disk space, and allows multiple virtual machines to use the same software installation.

Full Clones

A full clone is an independent virtual machine, with no need to access or maintain an ongoing connection to the parent virtual machine. Because a full clone does not share virtual disks with the parent virtual machine, full clones generally perform better than linked clones. However, full clones take longer to create than linked clones. Creating a full clone can take several minutes if the files involved are large.

Linked Clones

A linked clone is made from a snapshot of the parent. All files available on the parent at the moment of the snapshot continue to remain available to the linked clone. Ongoing changes to the virtual disk of the parent do not affect the linked clone, and changes to the disk of the linked clone do not affect the parent.

A linked clone must access the parent. Without access to the parent, a linked clone is disabled.

Linked clones are created swiftly, so you can easily create a unique virtual machine for each task you have. You can also easily share a virtual machine with other users by storing the virtual machine on your local network, where other users can quickly make a linked clone. This facilitates collaboration: for example, a support team can reproduce a bug in a virtual machine, and an engineer can quickly make a linked clone of that virtual machine to work on the bug

The Clone Virtual Machine Wizard

The Clone Virtual Machine Wizard guides through the process of making a clone. You do not need to locate and manually copy the parent virtual machine files. The Clone Virtual Machine Wizard automatically creates a new MAC address and other unique identifiers for the clone.

Warning: Before you power on the virtual machine clone, understand the following

Virtual machines clones are issued a new Universally Unique Identifier (UUID). This affect user scripts and API calls to the UUID of the virtual machine.
Virtual machines clones are issued new MAC addresses for attached virtual network adapters. This may have an effect on software or licensing that is sensitive to MAC address changes.
Guest operating systems for virtual machine clones may share computer names and static IP addresses with their original counterparts. Be sure to account for this prior to power-on

Procedure

Right click on the VM you want to clone

Select Clone

Put in a name and choose your Inventory location

Choose the Host

Choose your Virtual Disk Format
Choose your Datastore

Click Next
Choose to Power on the Machine after creation
Choose one of the 2 Customisation options (I have an existing specification)
It is not recommended to choose Do Not Customise

Click Next
Review and edit virtual hardware if you need to
Finish

Guest Operating System Customization Requirements in VMware

July 11, 2013 Guest O/S Customization No comments

What is Guest Operating System Customization

Customizing guest operating systems can help prevent conflicts that can result if virtual machines with identical settings are deployed from a template or cloning, such as conflicts due to duplicate computer names and IP Addresses

You can specify the customization settings by choosing to launch the Guest Customization wizard during the cloning or deployment process. Alternatively, you can create customization specifications, which are customization settings stored in the vCenter Server database. During the cloning or deployment process, you can select a customization specification to apply to the new virtual machine.

Quick Note on Sysprep

The guest operating system customization feature in vCenter Server uses the functions of the Sysprep tool.

Microsoft has a different version of Sysprep for each release and service pack of Windows. You must use the version of Sysprep specific to the operating system you are deploying.The differences are not immediately visible in the packaging and documentation of the service packs

You will find the various versions of sysprep in the following directories on vCenter

Guest Operating System Customization Requirements

Guest operating system customization is supported only if a number of requirements are met.

The most current version of VMware Tools must be installed on the virtual machine or template to customize the guest operating system during cloning or deployment.
The guest operating system being customized must be installed on a disk attached as SCSI node 0:0 in the virtual machine configuration.
Virtual machines that reside on hosts running ESX Server 3.0.x or earlier have additional disk requirements:

Windows Requirements

On a Windows guest operating system, the active partition (the partition containing boot.ini) and the system partition (the partition containing the system directory, for example, \WINNT or WINDOWS) must be on the same virtual disk. The active partition and the system partition do not need to be the same partition
Microsoft Sysprep tools must be installed on the vCenter Server system. See Installing the Microsoft Sysprep Tools.
Microsoft Sysprep tools must be installed on the vCenter Server system. See Installing the Microsoft Sysprep Tools.
The ESX/ESXi host that the virtual machine is running on must be 3.5 or later
Guest operating system customization is supported on multiple Windows operating systems. To verify customization support for Windows operating systems and compatible ESX/ESXi hosts, see VMware vSphere Compatibility Matrix

Linux Requirements

On a Linux guest operating system, the virtual disk containing the system partition (the partition containing the /etc directory) must reside on the SCSI 0:0 node.)
Perl must be installed in the Linux guest operating system.
The clone or template must have a root volume formatted with an ext2, ext3, or ReiserFS file system

Procedure

Log into vCenter
Click Home > Customization Specification Manager
Click New
Choose Windows or Linux for the Target Virtual Machine O/S
Choose a name for your Customization Specification Information

Click Next
Type in Name and Organisation

I would use Choose “Use the Virtual Machine Name”

Click Next
Put in your Volume Licensing Key
Include Server Licensing Information if you are customising a server guest operating system
Select Per Seat or Per Server

Click Next
Put in a password for the Admin account
Select whether you want to login automatically (Choice is up to you)

Click Next
Choose Timezone

Click Next
Specify any Run once commands

Click Next and this takes you into Network customisation
You can choose Typical or Custom.

Typical will just assign a DHCP Address which you can change afterwards
With Custom, you get the following choices

If you click New, it will let you add a new adapter say if you wanted a second nic for backup

If you click the radio button to the side, you get a whole set of options as per below

Click Next
Choose whether you want to join your domain automatically

Click Next
Generate a new SID

Click Next
Review your settings

Finish

Upgrading vSphere 4.1 to vSphere 5.1

July 2, 2013 Upgrading No comments

Upgrading is a multistage process in which procedures must be performed in a particular order. Follow the process outlined in this high-level overview to ensure a smooth upgrade with a minimum of system downtime. Make sure that you understand the entire upgrade process before you attempt to upgrade. If you do not follow the safeguards, you might lose data and lose access to your servers. Without planning, you might incur more downtime than is necessary

vCenter Single Sign-On
Inventory Service
vCenter Server

Datacentres continue to evolve. This evolution involves increasingly larger and more complex datacentres. Due to technologies such as cloud computing and distributed applications, administrators must have scalable tools and services to manage these environments in the most efficient manner possible. The longer you do not upgrade the less new beneficial features you will be able to take advantage of to provide an improved and scalable platform

Example Environment

This is an upgrade document targeted at

1 x MS Windows 2008 R2 VMware vCenter VM
1 x MS SQL Server 2008 R2 VM running the VMware vCenter DB + Update Manager DB
25 x VMware ESXi 4.1 U3 Hosts
No external Certificates

Planning Tasks

The upgrade to vCenter Server 5.1 includes a database schema upgrade and an upgrade of the vCenter Server Software.

vSphere 5.1 introduces vCenter Single Sign On service as part of the vCenter Server management infrastructure. This change affects vCenter Server installation, upgrading, and operation

You need to check every single point of the VMware Upgrade Guide and make sure you know exactly what you are doing and how to recover from any potential issues

Always use the “Run as Administrator” option. It can cause you to get random error messages because your account even if it is administrator can be denied rights to certain actions

Check the Interoperability Matrix

Check Host BIOS Version and Upgrade if necessary

Make sure hosts reach the minimum hardware configuration

Make sure vCenter meets the minimum hardware requirements

Make sure Single Sign On meets the minimum hardware requirements

Make sure Inventory Service meets the minimum requirements (if installed separately)

Make sure Inventory Service meets the minimum requirements (if installed on the same server as vCenter)

Make sure the server you install vSphere client on is supported

Make sure the server and web browser is supported for vSphere Web Client

Check JVM Settings (Can be set during vCenter Install)

Check the Database Authentication Mode

Make sure TCP/IP is enabled in SQL Server Configuration Manager

Always check with your vendor. E.g Dell, HP, IBM to see if they offer a customised ISO for VMware vSphere EXi5.X. These can provide extra features and functionality you may not get from the vanilla version via VMware

Make sure Active Directory, DNS and time synchronisation is working correctly

Upgrade your current licensing via your portal

Backup your vCenter and vCenter Update Manager Database via Backup Software and within SQL Management Studio

Backup SSL Certs to a separate location

Run the vCenter Host Agent Pre-Upgrade Checker and resolve any issues

Snapshot the vCenter DB Server and the vCenter VM (If Virtual Servers)

Stop the VMware Virtual Center Service

Important Notes about SSO

Install vCenter Single Sign On

Confirm Active Directory Domains

Install the vCenter Web Client

Upgrade the Inventory Service

Important Notes about the vCenter Install

Install vCenter

Upgrade the vSphere Client to v5.1

Upgrade Update Manager

Upgrade the Update Manager Client Plugin

Upgrade the Hosts

Upgrade VMware Tools

Upgrade VM Hardware Version

Upgrade Datastores from VMFS3 to VMFS5

Upgrade Virtual Distributed Switches to v5.1

Understanding DNS on Windows Server 2012

June 26, 2013 DNS No comments

Installing DNS

The process of deploying a DNS server on a Windows Server 2012 computer involves installing the DNS Server role by using the Add Roles and Features Wizard in Server Manager. The actual installation requires no additional input; there are no additional pages in the wizard and no role services to select. Once you install the DNS Server role, the computer is ready to perform caching-only name resolution services for any clients that have access to it. The role also installs the DNS Manager console, which you use to configure the DNS server’s other capabilities

DNS Queries

An iterative query is one where the DNS server may provide a partial answer to the query (or give an error). DNS servers must support non-recursive queries.

A recursive query is one where the DNS server will fully answer the query (or give an error). DNS servers are not required to support recursive queries and both the resolver (or another DNS acting recursively on behalf of another resolver) negotiate use of recursive service using bits in the query headers

Types of DNS Record

Creating zones

A zone is an administrative entity you create on a DNS server to represent a discrete portion of the DNS namespace. Administrators typically divide the DNS namespace into zones to store them on different servers and to delegate their administration to different people. Zones always consist of entire domains or subdomains. You can create a zone that contains multiple domains as long as those domains are contiguous in the DNS namespace. For example, you can create a zone containing a parent domain and its child, because they are directly connected, but you cannot create a zone containing two child domains without their common parent, because the two children are not directly connected.

The DNS server in Windows Server 2012 can support as many as 200,000 zones on a single server, although it is hard to imagine a scenario that would require that many. In most cases, an administrator creates multiple zones on a server and then delegates most of them to other servers, which then become responsible for hosting them.
Every zone consists of a zone database, which contains the resource records for the domains in that zone. The DNS server in Windows Server 2012 supports three zone types, which specify where the server stores the zone database and what kind of information it contains. These zone types are as follows

Forward Lookup Zone

A forward lookup zone is a DNS zone in which hostname to IP address relations are stored. When a computer requests the IP address of a specific hostname, the forward lookup zone is queried and the result is returned.

Reverse Lookup Zone

A reverse lookup zone does just the opposite. When a computer requests the hostname of an IP address, the reverse lookup zone is queried and the result is returned.

Primary/Active Directory Integrated Zone

Zones that are integrated with Active Directory Domain Services (AD DS) use directory replication to transfer zone data between DNS servers. Zones that are not integrated with AD DS (that is, that store zone data in files) use conventional zone transfer to propagate zone changes among primary and secondary DNS server. Zones that are integrated with AD DS usually require little or no management apart from the management of the corresponding AD DS forests and domains. Active Directory–integrated zones do not ordinarily employ secondary DNS servers.

Secondary Zones

Secondary servers can be used as backups for DNS clients. This allows you to use secondary servers as a means to create fault tolerant and load balanced DNS query traffic on your network and reserve your DNS-enabled primary servers for use only by those clients that need them to perform dynamic registration and updates of their A and PTR RRs. Secondary DNS servers maintain a read-only copy of zone data that is transferred periodically from the primary DNS server for the zone. You can configure DNS clients to query secondary DNS servers instead of (or in addition to) the primary DNS server for a zone, reducing demand on the primary server and ensuring that DNS queries for the zone will be answered even if the primary server is not available.

Stub zones

Stub zones are used when you want a DNS server hosting a parent zone to remain aware of the authoritative DNS servers for one of its child zones. If the stub zone for a child zone is hosted on the same DNS server as the parent zone, the DNS server hosting the stub zone will receive a list of all new authoritative DNS servers for the child zone when it requests an update from the stub zone’s master server . This method of updating the DNS server hosting the parent zone maintains a current list of the authoritative DNS servers for the child zone as they are added and removed.

A conditional forwarder is not an efficient method of keeping a DNS server hosting a parent zone aware of the authoritative DNS servers for a child zone. If you used this method, whenever the authoritative DNS servers for the child zone changed, the conditional forwarder setting on the DNS server hosting the parent zone would have to be manually configured with the IP address for each new authoritative DNS server for the child zone.

Caching Server

Caching servers can also be arranged in a hierarchy. This makes sense in cases where the network capacity is limited and/or network latency between the DNS client and the rest of the Internet is high. When connecting a laptop to the Internet through a slow dial-up connection it makes sense to run a caching server right on the laptop. This way each click on a hyperlink on the same web-site will not cause DNS related traffic over the dial-up link. Such a local caching server is often configured to send all queries for which it does not have cached answers to the ISPs caching server in turn. Sometimes corporate networks have local caching servers that in turn send queries to a corporate caching server before they are sent out to the Internet. This way the corporate caching server can build a large cache based on queries from the whole enterprise.

Types of DNS Configuration

Interfaces

Use this tab to select the IP Addresses that the DNS Server will use to listen to queries

Forwarder

A forwarder is a Domain Name System (DNS) server on a network that you can use to forward DNS queries for external DNS names to DNS servers outside that network. You can also use conditional forwarders to forward queries according to specific domain names.

A DNS server on a network is designated as a forwarder when you configure the other DNS servers in the network to forward the queries that they cannot resolve locally to that DNS server. By using a forwarder, you can manage name resolution for names outside your network, such as names on the Internet

To use forwarders to manage the DNS traffic between your network and the Internet, configure your network’s firewall to allow only a dedicated set of DNS servers to communicate with the Internet. When you configure other DNS servers in your network to forward queries that they cannot resolve locally to these designated DNS servers, they act as your forwarders. DNS servers that forward queries to the Internet should not host zones to avoid exposing your internal network namespace to external attackers.

Advanced

Use this tab to set Advanced Settings

Root Hints

Use this tab to specify the servers to be used for root hints when forwarders are not configured or do not respond. The 13 root name server names are located in a domain called root-servers.net and are named using letters of the alphabet. The servers are scattered around the world on different subnets to provide fault tolerance.

Debug Logging

Use this tab to configure packet-level logging for debugging purposes.

Event Logging

Use this tab to specify the types of events that will be recorded in the DNS event log.

Trust Anchors

Trust Anchors is the new feature in Windows Server 2008 R2 and Windows 7. We can now sign and host DNSSEC-signed (Domain Name System Security Extension) zones to provide more security in our DNS infrastructure.

Monitoring

Use this tab to perform tests to verify the correct server configuration.

Security

Use this tab to set permissions for the DNS Server

Conditional forwarders

A conditional forwarder setting configures the DNS server to forward a query it receives to a DNS server depending on the DNS name contained in the query. In situations where you want DNS clients in separate networks to resolve each others’ names without having to query DNS servers on the Internet, such as in the case of a company merger, you should configure the DNS servers in each network to forward queries for names in the other network. DNS servers in one network will forward names for clients in the other network to a specific DNS server that will build up a large cache of information about the other network. When forwarding in this way, you create a direct point of contact between two networks’ DNS servers, reducing the need for recursion.

Stub zones do not provide the same server-to-server benefit because a DNS server hosting a stub zone in one network will reply to queries for names in the other network with a list of all authoritative DNS servers for the zone with that name, instead of the specific DNS servers you have designated to handle this traffic. This configuration complicates any type of security settings that you want to establish between specific DNS servers running in each of the networks.

Zone Delegation

Domain Name System (DNS) provides the option of dividing up the namespace into one or more zones, which can then be stored, distributed, and replicated to other DNS servers. When you are deciding whether to divide your DNS namespace to make additional zones, consider the following reasons to use additional zones:

You want to delegate management of part of your DNS namespace to another location or department in your organization.
You want to divide one large zone into smaller zones to distribute traffic loads among multiple servers, improve DNS name resolution performance, or create a more-fault-tolerant DNS environment.
You want to extend the namespace by adding numerous subdomains at once, for example, to accommodate the opening of a new branch or site.

If, for any of these reasons, you can benefit from delegating zones, it might make sense to restructure your namespace by adding additional zones. When you are deciding how to structure zones, use a plan that reflects the structure of your organization.

When you delegate zones within your namespace, remember that for each new zone that you create, you need delegation records in other zones that point to the authoritative DNS servers for the new zone. This is necessary both to transfer authority and to provide correct referral to other DNS servers and clients of the new servers that are being made authoritative for the new zone.

When a standard primary zone is first created, all the resource record information is stored as a text file on a single DNS server. This server acts as the primary master for the zone. Zone information can be replicated to other DNS servers to improve fault tolerance and server performance.

When you are structuring your zones, there are several good reasons to use additional DNS servers for zone replication:

Added DNS servers provide zone redundancy, which makes it possible for DNS names in the zone to be resolved for clients if a primary server for the zone stops responding.
Added DNS servers can be placed so as to reduce DNS network traffic. For example, adding a DNS server to the opposing side of a low-speed, wide area network (WAN) link can be useful in managing and reducing network traffic.
Additional secondary servers can be used to reduce loads on a primary server for a zone.

« Older Entries Recent Entries »

Using Trusts in Windows environments

SQL Server 2012 Installable Features

VCAP-DCA 5 Exam Experience

Optimising SQL Server for VMware vCenter

Using VMware’s Host Agent Pre Upgrade Checker and Database Pre Upgrade Checker

Installing SSO as part of the vSphere 5.x Upgrade process

Cloning Virtual Machines in VMware

Guest Operating System Customization Requirements in VMware

Upgrading vSphere 4.1 to vSphere 5.1

Understanding DNS on Windows Server 2012

Electric Monk

Don't think about what can happen in a month. Don't think what can happen in a year. Just focus on the 24 hours in front of you and do what you can to get closer to where you want to be :-)

Search

Calendar

Social Media and RSS

vExpert

Recent Posts

Archives

Categories

Fatcow Webhosting

Electric Monk

Don't think about what can happen in a month. Don't think what can happen in a year. Just focus on the 24 hours in front of you and do what you can to get closer to where you want to be :-)

Search

Calendar

Social Media and RSS

vExpert

Recent Posts

Archives

Categories

Tags

Fatcow Webhosting