AD RMS Infrastructure Concepts

AD RMS infrastructure

AD RMS, like any IT service, relies on some infrastructure to work. In the case of AD RMS there are several components that work together in order for the solution to deliver a useful service. The most relevant ones are:
· AD RMS servers and clusters
· The AD RMS SQL Server database
· Active Directory
· The Rights Management Services client and RMS-enabled applications in the client
· AD RMS-integrated server applications



While there are other components that work along with AD RMS to make the whole thing work, those should cover the most important ones needed to understand other topics in this blog.

AD RMS Servers and Clusters

AD RMS provides its services to other elements as a web-service, and it is thus hosted inside Internet Information Services in a Windows Server. It normally runs over HTTPs (though running it over HTTP is also possible) providing a few web service operations that can be consumed by clients and services to perform information protection and consumption tasks.
AD RMS actually not only uses IIS in the hosting server, but it also uses Message Queuing to interact with the AD RMS database which we will be discussing later. That ensures that operations in the AD RMS services that need to send data to the database can be performed asynchronously and that in turn increases performance and resiliency of the database services.
Multiple AD RMS servers are typically joined together forming AD RMS clusters, which are basically collections of identically-configured AD RMS servers connected to the same AD RMS database and working together to resolve requests from other clients and servers. In an AD RMS cluster it doesn’t matter which server resolves a request, so the requests are typically load balanced through a mechanisms such as Network Load Balancing in Windows or an external load balancer.

AD RMS Database

As stated, a group of identical AD RMS servers form an AD RMS cluster. Servers in a cluster don’t host persistent service-related data in their own disks. All configurations, logs, persistent status and operation data and caches are actually hosted externally to the AD RMS servers in a SQL Server database called the AD RMS Database. That way, all servers share a common configuration and if a server fails users can continue to work through other servers in the cluster.
There’s actually not a single AD RMS database but three. Those three databases are typically hosted in the same server and are:
· The AD RMS Configuration Database, which hosts all the configurations defining the behavior of the cluster such as its URLs and caching behavior, as well as copies of some certificates and other items needed to keep the service running. It typically also holds the core certificates and keys for the AD RMS servers themselves.
· The AD RMS Caching database, which is used to cache frequently used data about the users and groups defined in Active Directory, in order to avoid impacting the performance of AD every time the service needs anything from the directory.
· The AD RMS Logging Database, in which AD RMS puts information about transactions that have been performed by the service. This information is not used by AD RMS for anything other than for reporting.

Active Directory

AD RMS uses Active Directory to authenticate users of the system within the forest where it is installed. It also uses AD to obtain information about the email address of the users, which is used as the users’ identifier thorough the system, and to obtain information about group membership when the rights assigned to a document refer to a group instead of an individual user.
As stated above, AD RMS caches data from AD in the AD RMS AD Caching database in order to avoid hitting the domain controllers too hard.

Client-side components

AD RMS typically works together with client-side components to perform the encryption, decryption and policy enforcement tasks.
The main client-side components in an AD RMS system are the Rights Management Services client and AD RMS-enabled applications.
The Rights Management Services client, which comes installed as part of Windows Vista SP1 and later and in Windows 7, and that can be installed in earlier versions of Windows, deals with all the key management, communicates with the AD RMS services in requesting licenses and providing certificates and communicates with the client applications to perform the encryption and decryption of content. It also provides a secure environment for all these tasks to occur, helping prevent tampering and potential key disclosures.

AD RMS enabled server-side applications

While most AD RMS-related operations are performed between the clients and the AD RMS servers, having some level of integration between certain server-side services and AD RMS can provide for a better user experience and more efficient IT services. For example, Exchange Server 2010 can acquire licenses for content on behalf of the users so users don’t have to wait for a license to be acquired when they open email they have in their inbox. It also provides the ability to create and consume protected content in the browser when using OWA, along with other capabilities.

Windows 2008 Clustering

Where is the cluster log in Windows 2008 ?
This short answer is its no longer there. On our Windows 2008 cluster node if we navigate to %systemroot%\system32\LogFiles\Cluster your wont find the cluster.log file anymore.
Why ? Its been replaced by a much more sophisticated event based tracing system.
The Vista\Windows Server 2008 Event Model is the next generation of Windows Event Logging and replaces the current version of the Event Log shipped in Microsoft® Windows® 2003 Server, Microsoft® Windows® XP, Windows 2000, and previous versions of Microsoft® Windows NT®.
The new model is a major update to the NT Event Log service. It maintains 100% backwards compatibility with the existing APIs and functionality and fully leverages the existing NT Event Log instrumentation in the applications and services. At the same time, it eliminates some of the limitations of the NT Event Log and provides additional features to better support monitoring and diagnostics of Windows applications, services, components, and drivers.
In a future post I will go through the new Logging and tracing features for clusters in Windows 2008 but for now lets look at how to get access to the old familiar cluster.log file.
Here's how to go about it.
1.   Go to a command prompt
2.  Type "Cluster /Cluster:yourclustername log /gen /copy "C:\temp". You should get output as follows




3. Navigate to the c:\temp directory and there you will find the .log files for each node of your cluster.
The cluster log can now be opened in Notepad.
Please note that you need to run this command after each change as its not dynamically updated like the old .log file.

Overiview of authentication mechanisms in AD LDS

Hello All,

I have been working with a customer on application authentication project with AD LDS (Active Directory Lightweight Directory Services) and ADAM (Active Directory in Application Mode) and I thought it might be interested to share my experience on this blog.  There are many things to share but I will focus this blog entry on available authentication options and will try to break it down their usage depending on the scenario.

Since this entry explores only the authentication aspect of AD LDS or ADAM, this can apply to both products.  I will stick with AD LDS for the remainder of the blog for the sake of clarity.  If you are not familiar with AD LDS or ADAM, look at the Windows Server Tech Center page at http://technet.microsoft.com/en-us/library/cc731868.aspx.  Brian Puhl’s recorded session at http://www.microsoft.com/emea/spotlight/sessionh.aspx?videoid=342  covers when to use AD LDS or AD DS.

You can use one of three authentication mechanisms available with AD LDS to authenticate:  AD LDS principal authentication, Windows principal authentication and AD LDS proxy authentication.

AD LDS principal authentication is the most common scenario that I have seen at customer implementations.  Customers who have legacy applications which require specific directory applications for simple LDAP authentication and they do not want to extend schema of their AD DS.  It is a simple LDAP authentication which allows users to bind with DN (distinguished name) of their AD LDS account in X.500 format and its password.  User account policies such as account locked out and password complexity are enforced by the local security policy of the machine that AD LDS instance is configured, if the server is in a workgroup.  Active Directroy Domain account polices are applied, if the server belongs to a domain.  The drawback in this authentication type is that users’ password are transmitted in clear text format so it requires additional step to configure LDAP over SSL.  The instructions on how to configure LDAP over SSL for AD LDS is at http://technet.microsoft.com/en-us/library/cc725767.aspx. 

Let’s look at Windows principal authentication (also known as SSPI authentication).  Customers are usually not aware of this authentication type.  This approach allows users to authenticate to AD LDS instance using their AD DS domain account or local user accounts on the server that AD LDS instance is hosted.  In order for users to authenticate using their domain account, the server that the AD LDS instance is hosted must be a member of the domain.  The authentication using the domain account leverages Kerberos protocol (although may fall back to NTLM depending on the AD domain policies) and thus more secure than using a local account which leverages NTLM.  This MSDN article http://msdn.microsoft.com/en-us/magazine/dvdarchive/cc300806.aspx explains the capabilities of different authentication protocols and explains why Kerberos protocol is more secured than using other Windows authentication type.  Using Windows principal authentication obviates the need to configure LDAP over SSL as it leverages Kerberos or NTLM Sign and Encrypt mechanism to encrypt the traffic.  It is also easier to manage domain accounts with domain policies and security groups.  If the Windows principal is leveraged to authenticate to an AD LDS instance, users must provide their windows credentials with user name and the domain.  The con of Windows principal authentication is that it cannot accommodate legacy and non-Windows applications which still require binding with an X.500 path.

The third option is ADAM proxy user authentication, also known as bind redirection, in which users authenticate with their AD LDS principals but can leverage their corresponding AD DS passwords.  Proxy authentication allows reduced sign on for users where users still need to leverage DN of AD LDS account to authenticate but can use the same password as their AD DS account.  This option simplifies the account management as account management can be done from AD DS.  This option requires the server the AD LDS instance is hosted to join to the AD DS domain or needs a trust relationship with the AD DS domain in which users’ AD DS account resides.  This option also requires additional synchronization tools like Identity Lifecycle Manager 2007 or Forefront Identity Manager 2010 (currently in Beta) to synchronize the objectSID of AD DS user account to the corresponding AD LDS account.  LDAP over SSL should be configured for users to authenticate with their AD LDS account in order to keep their domain account password secure.  This technet article http://technet.microsoft.com/en-us/magazine/2008.12.proxy.aspx provides more insight into proxy authentication.

This article http://technet.microsoft.com/en-us/library/cc784622.aspx explains how to set up each of the authentication available in AD LDS.  

My recommendation is to leverage Windows principal authentication leveraging users’ AD DS domain accounts when possible for the reasons mentioned above unless applications cannot support Windows authentication.  If your environment has synchronization product like ILM, Bi-directional proxy authentication should be explored to simplify the account management. 

Using Hyper-V Server 2008 R2 for VDI

When configuring a Virtual Desktop Infrastructure using Remote Desktop Services in Windows Server 2008 R2, you need the Remote Desktop Virtualization Host role service.

how can you enable the Remote Desktop Virtualization Host?

When you search for the available features on Hyper-V Server you can use DISM. For example “dism /online /Get-Features /Format:table”. This may give the following output:





Now I did not find the Remote Desktop Virtualization Host feature in this list :-). Through PowerShell however, I found out it to be the VmHostAgent feature.
I had the Server Manager cmdlets installed on the Hyper-V Server host. This gives a much more readable output of features. This is what I used in PowerShell:
Import-Module ServerManager
Get-WindowsFeature

Now you can see the Remote Desktop Virtualization Host feature with a Name of RDS-Virtualization.

Enabling the feature is now simple.
DISM
dism /online /Enable-Feature /FeatureName:VmHostAgent
! Make sure you type VmHostAgent with correct casing !

PowerShell
Add-WindowsFeature –Name RDS-Virtualization

Why Companies Switch from VMware to Microsoft® Virtualization

VMware vSphere Ports

vSphere Network Ports Diagram

Active Directory SRV Records

The Primary Purpose of DNS

Sometimes, particularly in troubleshooting, you have to go back to basics.  Keep in mind that the primary point of DNS is to map a server's name to an IP address.  Example:  LogonServer  -  10.209.12.20.
Users need a range of resources, from printers and home directories to global catalog servers and Kerberos authentication for logon.  The role of DNS is to respond to users requests for the resource by providing the IP address of the servers. 
The extra dimension of DNS with Active Directory is the _SRV records.  These service records tell you not only the server's IP address but also the services that it offers.  Here is a kerberos example: _kerberos 88 (Port) LogonServer.TopBanana.com.
User's perspective - "I want to logon."
DNS with Active Directory - "I will look in the _SRV records for a server which offers Kerberos authentication."
DNS host record - "Here is the IP address of that server you need".

Integrating DNS and Active Directory

The key reason for integrating DNS and AD is efficiency.  This is particularly true where you have lots of replication traffic.  Even if you have a fast network, it makes sense for DNS changes to be replicated along side Active Directory changes, rather than having their own separate system.
Window 2000 (and later) DNS systems use IXFR - Incremental Zone Transfer, this means that only changes are replicated, not the whole database.  The disgraceful situation in NT 4.0 was that if you added one DNS record then all records were transferred during the update thus creating unwanted extra network traffic.

Importance of Naming and DNS

DNS names and Active Directory names.

The confusion arises because both DNS and Microsoft's Active Directory use the domain word.  It may be better if you think of, and refer to, DNS zones and Active Directory domains.  It is often a very good idea to have the DNS zone and the Active Directory name the same.  For example DNS zone TopBanana.com, Active Directory root domain TopBanana.com.  However this arrangement can add to the confusion unless you are clear about the distinction between DNS and Active Directory.

Naming your Active Directory Forest

It is crucial to understand all the implications of your naming conventions, especially the relationship between domain name and DNS name.  Learn from the mistakes of others.  One urban myth circulating has it that all the first 10 companies who installed Windows 2000 Active Directory, had to go back to the drawing board and start again.  What was their problem?  In each case they got their naming strategy wrong.  (or they did not have a strategy).
The first question is are you going to use an existing DNS name?  If you are using and existing domain name will you use the same name for your first domain.  A supplementary question, will the Root domain, be blank or will it be your HQ domain?  There are no right or wrong answers to these questions, what I am saying is that once you make your decisions you have detailed plans to ensure it works and that you do not have to rip it all up and start again.
How many domains do you need, I do have a few here - as few as possible.  Good reasons for having more than one domain, multi national company, incompatible security needs, different language versions of Windows 2003.  Bad reasons for having a new domain, there is a new manager in division, a region want complete control of its IT.
If you do find this planning to much then either make a single domain work for you, or else employ a network architect who is used to this sorting out these naming dilemmas.

 

Practical configuration of DNS and DCPROMO

The scenario, you are about to install your first Active Directory domain controller.  Remember that when ever you install Windows Server 2003 it begins life as a member server.  To install Active Directory go to the Start Menu, then Run, DCPROMO and so create a domain controller.  But before you do that check out DNS.
Begin in the System Icon, Computer Name (Tab), Change, More.. Primary DNS Suffix of this Computer.  Make sure the settings are as per plan.
Double check the Network Connections, Local Area Network, TCP/IP properties, Use the following DNS server address,  does this point to itself, or to the correct DNS server.  I would fill in both DNS server boxes if you have two DNS servers.
Install DNS through the Add or Remove Programs, Windows Components, Networking Components, Details.  DNS.  If this is your first server I would run DCPROMO without any more configuration at this stage.  My tactic is to let the Wizard add and populate the Forward Lookup Zone.

Seven post installation Active Directory and DNS checks

1. Once DCPROMO creates Active Directory records in DNS, then I would create the reverse lookup zone and test it with NSLOOKUP.
2. Check the Event Viewer which is now just under the DNS server object.  Look up any suspicious error messages in TechNet.
3. Right click the DNS server, Properties, Monitor (Tab), Test Now.  Should the Recursive query fail investigate the Root Hints. (I have never seen the Simple Query fail.)
4. If you are not connected to the internet.  You may wish to create a '.' (dot, period, full stop) root domain and point the Root ".) to your domain.
5. Many of us believe that you have not proved Active Directory is working properly until you have installed a second domain controller and seen replication of users.
6. Set a date to switch to 'Raise Domain Functional Level'.  I used to call this switching to Native Mode, but now it is more complex.  When you have no more NT 4.0 BDC, raising the domain level turns on features like Universal Groups, group nesting, RAS Policies as well as extra Exchange functionality.
7. Once DCPROMO installs Active Directory, then I would check that at least 4 _mcsdcs records are created, if not I would start and stop the Netlogon service check again.  Still no _mcsdcs records, I would have a reboot, take a 10 minute break and look again in DNS. 
   
   Experience tells me this either DCPROMO works and there is no problem or else it very stubborn.  If still no sign of Active Directory records in DNS, I would run DCPROMO, demote and start again at the beginning.  In the case of a test installation, I would change the Computer name and the domain suffix before trying again.

What DNS entries (SRV Records) does Windows 2000/2003 add when you create a domain?

In order for Active Directory to function properly, DNS servers must provide support for Service Location (SRV) resource records described in RFC 2052, A DNS RR for specifying the location of services (DNS SRV). SRV resource records map the name of a service to the name of a server offering that service. Active Directory clients and domain controllers use SRV records to determine the IP addresses of domain controllers. Although not a technical requirement of Active Directory, it is highly recommended that DNS servers provide support for DNS dynamic updates described in RFC 2136, Observations on the use of Components of the Class A Address Space within the Internet.
The Windows 2000 DNS service provides support for both SRV records and dynamic updates. If a non-Windows 2000 DNS server is being used, verify that it at least supports the SRV resource record. If not, it must be upgraded to a version that does support the use of the SRV resource record. For example, Windows NT Server 4.0 DNS servers must be upgraded to Service Pack 4 or later to support SRV resource records. A DNS server that supports SRV records but does not support dynamic update must be updated with the contents of the Netlogon.dns file created by the Active Directory Installation wizard while promoting a Windows 2000 Server to a domain controller. The Netlogon.dns file is described in the following section.
So now you understand that Windows 2000 domains rely heavily on DNS entries. If you enable dynamic update on the relevant DNS zones, W2K creates these entries automatically:

• _ldap._tcp.<DNSDomainName>

Enables a client to locate a W2K domain controller in the domain named by <DNSDomainName>. A client searching for a domain controller in the domain dpetri.net would query the DNS server for _ldap._tcp.dpetri.net.

• _ldap._tcp.<SiteName>._sites.<DNSDomainName>

Enables a client to find a W2K domain controller in the domain and site specified (e.g., _ldap._tcp.lab._sites.dpetri.net for a domain controller in the Lab site of dpetri.net).

• _ldap._tcp.pdc._ms-dcs.<DNSDomainName>

Enables a client to find the PDC flexible single master object (FSMO) role holder of a mixed-mode domain. Only the PDC of the domain registers this record.

• _ldap._tcp.gc._msdcs.<DNSTreeName>

Enables a client to find a Global Catalog (GC) server. Only domain controllers serving as GC servers for the tree will register this name. If a server ceases to be a GC server, the server will deregister the record.

• _ldap._tcp. ._sites.gc._msdcs.<DNSTreeName>

Enables a client to find a GC server in the specified site (e.g., _ldap._tcp.lab._sites.gc._msdcs.dpetri.net).

• _ldap._tcp.<DomainGuid>.domains._msdcs.<DNSTreeName>

Enables a client to find a domain controller in a domain based on the domain controller’s globally unique ID. A GUID is a 128-bit (8 byte) number that generates automatically for referencing Active Directory objects.

• <DNSDomainName>

Enables a client to find a domain controller through a normal Host record.

After running DCPROMO, A text file containing the appropriate DNS resource records for the domain controller is created. The file called Netlogon.dns is created in the %systemroot%\System32\config folder and contains all the records needed to register the resource records of the domain controller. Netlogon.dns is used by the Windows 2000 NetLogon service and to support Active Directory for non-Windows 2000 DNS servers.

If you are using a DNS server that supports the SRV resource record but does not support dynamic updates (such as a UNIX-based DNS server or a Windows NT Server 4.0 DNS server), you can import the records in Netlogon.dns into the appropriate primary zone file to manually configure the primary zone on that server to support Active Directory.

Introduction to DNS in Windows Server 2003

This page begins with the basic concepts of DNS and moves on to troubleshooting.  The golden rule when dealing with DNS is this, remember that the name of the DNS game is name resolution.  By that I mean we humans like friendly names like cisco.com, whereas computer like dotty dot number like 10.1.13.20.  What DNS does is to keep a mapping of the two parts:
IP Address = 10.1.13.20   -   Resource = BigServer.cisco.com 
One trait I noticed with DNS is that many of its features come in pairs, this symmetry will help you to remember and to understand how DNS operates.

Query and Registration

Whether you are configuring or whether you are troubleshooting there are two aspects of DNS to consider:
a) Registration --> sending information to the DNS server database.
b) Query <-- retrieving IP addresses from the DNS hierarchical system.

Registration The best way to register clients is through DHCP.  The DHCP server gives out not only the client's IP address, but also the address of the DNS servers. The good news is that DNS is now dynamic (DDNS).  This means that if a client changes it's IP address, then either the client updates DNS directly, or DHCP will act on the clients behalf and send a message to update the (A) Host record in DNS. Query From the client's point of view, when it needs to know the IP address of a resource, it contacts the DNS server(s) named in the TCP/IP property sheet.  Best practice is to give out this DNS server IP through DHCP.  What you need to configure in DHCP is Option Type 006 - DNS.

Recursive and Iterative DNS Queries

Recursive

Recursive queries are the default method.  A recursive query means that the DNS server takes full responsibility for finding the IP address that the client wants.  Take as an example, a client wants to query google.com.  It is unlikely that the server is authoritative, or has a Host record for Google.com.  So, the DNS server contacts the root server for the IP address of .com servers; it then contacts those .com servers and asks for the IP address of google.com.  Finally the DNS server sends the information to the client.
Woops!  I left out the very first step.  The root of the DNS system is a dot (period) "."  In Server 2003,  the icon representing the DNS server has a 'Root Hints' tab.  Here you find the IP addresses of all the top level domains.  It is because DNS is hierarchical, that it scales so well, and is superior to WINS which only offers a limited, flat-field system.
                          "."  (Root of DNS)
.com    .org  .net  .edu   .mil   .gov    .co.uk  

Iterative

Iterative means the server returns the best answer it can.  In the above example the DNS server would say to the client.  'I do not know where google.com is, here is the IP address of the root servers, you go and query them.'

Forward and Reverse Lookup

Forward Lookup

A forward query is where you know the hostname, but your operating system needs the IP address to locate the resource.  The best way to create your Active Directory forward lookup zone is for DCPROMO to create it when the member server is promoted.  Example "DNS, please tell me the IP address of LogonServer".  Response from DNS, LogonServer 10.209.12.20.

Reverse Lookup

I always think of reverse lookup as a hackers tool, where they know the IP address but want to know the hostname.  A classic situation would be that you can ping an IP address, and want to know what the hostname of that address.
Ping - 10.209.12.20.    
NSLookup - 10.209.12.20        Reply from DNS LogonServer 10.209.12.20.
In fact there are many legitimate reasons for using reverse lookups, authenticating mail servers and troubleshooting with NSLookup to name two.  Windows Server 2003 is very friendly in helping you create the reverse zone (technically called in-addra.arpa).  Where it is less friendly is that you have to create the PTR or pointer records yourself.  However if you are organized and create the reverse lookup zone before you populate the forward lookup zone, then you can check a box saying - "Update Associated Pointer (PTR) Record"

Troubleshooting

Again we have a pair of utilities.  IPCONFIG and NSLookup are your key DNS commands.  Both are available at the command prompt on Windows 2003, XP and even NT 4.0 machines.

IPCONFIG

IPCONFIG has two new switches /registerdns and /flushdns.  If you need to add a record to DNS, then IPCONFIG / registerdns will save you a reboot.  Perhaps a connection is failing because of stale, invalid, cached IP address, IPCONFIG / flushdns will clear the cache and you can make that connection.
There is also another pair of switches, /release and /renew for use when refreshing DHCP leases.  Also remember IPCONFIG /all to check on DNS and DHCP server settings.

NSLookup comes in two modes

a) Non-interactive where you just want a quick lookup of a server name, example: NSLookup 10.209.12.20
b) Interactive mode which is more difficult to master.  Here  you type:
NSLookup
>
My best advice when you reach the prompt is to type: help.
Example ls -t NS topbanana.com 
This would list all records of type Name Servers in the topbanana.com domain.
If you experiment with NSLookup and nothing happens, then remember that you need a Reverse Lookup Zone with (PTR) pointer records.  Once you create those PTR records, NSLookup will return that server name.
I use NSLookup when I am troubleshooting from a client machine and I wish to list the DNS records.  It saves a long walk to the DNS server and gets around having to install the AdminPak just to view the DNS records.

Presentation Server 4.0 Migration - Citrix

Presentation Server 4.0 Migration

Contents
Preparing for Migration
Supported migrations and restrictions
o Mixed farms with both Presentation Server 3.0 and 4.0 servers
o Service Pack 2005.04
Migration Steps
o Migration of Licenses
o Migration of MetaFrame XP FR3 and Presentation Server 3.0 software
o Migration of MetaFrame XP FR2 or earlier software

Preparing for Migration
This article we discusses how to plan for your migration and how to update licensing for Citrix Presentation Server 4.0.
When planning a major migration, consider any changes or enhancements to the environment you may also be planning. No single set of procedures can cover every environment’s need. Review the issues discussed in this guide and formulate the plan best tailored for your environment. At a minimum, consider the following topics before you update any components:
Server operating systems. Presentation Server 4.0 for Windows requires Microsoft Windows 2000 Server or Windows Server 2003. If you upgrade the platform release of the server’s operating system; for example, if you upgrade the server from Windows 2000 Server to Windows Server 2003, Citrix recommends that you use a fresh installation of Presentation Server.
Server farm design. Now is a good time to consider whether or not your present use of farms and zones best fits your organization, network, and user access needs. For example, adding network segments may require that you redesign the environment. If users’ remote access needs have grown, your organization has added sites, or your staff now has expanded database expertise—all of these factors can support a new farm design. For more information about designing farms, see the Presentation Server Administrator’s Guide.
User access during migration. The easiest and recommended way to provide published applications and resources to users during and after a migration is through the Web Interface or Version 9.0 of the Program Neighborhood Agent. If you are not currently using these interfaces, consider incorporating one of them.
License use during migration. If you run Presentation Server with MetaFrame XP or MetaFrame 1.8 during a migration phase, you must provide both types of licensing during that migration phase. Connection licenses are not shared between Presentation Server and previous versions. For example, users can consume one Presentation Server license if they launch an application on a server running Presentation Server and also consume a MetaFrame XP license if they launch an application on a server running MetaFrame XP.
Note: The reason for this is that the licensing mechanisms of MetaFrame XP and MetaFrame 1.8 are completely different and do not integrate with the licensing system of Presentation Server 3.0 and 4.0.
Manageable phases. For large server farms or multi-farm environments, consider migrating in phases. Deciding how to group users, applications, and servers into manageable chunks for your staff is unique to any organization and greatly influences your migration plan.
When planning a migration, engaging the services of Citrix Consulting or a Citrix Partner may be advantageous as part of large or complex upgrades. External consultants with experience with large migration projects can typically save an organization time and money based on their experiences with similar implementations.
Supported Migrations and Restrictions
When migrating or upgrading to Presentation Sever 4.0 please be aware of the following:
General
• Citrix recommends that you deploy the latest version of Presentation Server of all servers in the server farm.
• Citrix does not support upgrading a server’s operating system. For example, if you are upgrading your server from Windows NT 4.0 to Windows 2000 Server or Windows 2000 Server to Windows Server 2003, after upgrading, you must install Presentation Server as a new installation.
• You can only directly upgrade to Presentation Server 4.0 from MetaFrame XP FR3 and Presentation Server 3.0. You cannot upgrade servers running MetaFrame 1.0, MetaFrame 1.8, or versions of MetaFrame XP prior to Feature Release 3 directly to Presentation Server 4.0. These versions can be upgraded to Presentation Server 3.0 and then upgraded to 4.0. Refer to the Presentation Server 4.0 Administrator’s Guide for more details.
• If you are upgrading Conferencing Manager, please note that a direct upgrade from Conferencing Manager 2.0 to version 4.0 is not supported. Refer to the Administrator’s Guide for Citrix MetaFrame Conferencing Manager Version 4.0 for more details.
Service Pack 2005.04 and Mixed Farm Considerations
• Installing Service Pack 2005.04 on Presentation Server 3.0 effectively upgrades its binaries to the Presentation Server 4.0 level. If you wish to install Service Pack 2005.04 into your Presentation Server 3.0 farm, please be aware of the potential interoperability issues that could arise with printing as well as the recommendations for upgrading farm data collectors, farm metric servers and data connection servers that are mentioned below.
• During the migration to Presentation Server 4.0 or installation of Service Pack 2005.04 some farm servers may remain at their existing version level while others should be upgraded to Presentation Server 4.0. Special consideration should be given to data collectors, farm metric servers and database connection servers. These servers should be updated to the Presentation Server 4.0 level prior to other farm servers. Keeping them at their existing level could cause issues with your server farm and resource manager functionality. Refer to the Presentation Server 4.0 Administrator’s Guide for complete order of operation details.
• The installation of Presentation Server 4.0 or Service Pack 2005.04 introduces a new policy, the session printers policy, which replaces previous methods of managing network printer settings. This new policy cannot be used to manage the network printer settings of previous versions of Presentation Server. Citrix only recommends maintaining a farm containing mixed versions of Presentation Server for minimal periods of transition. If you have a farm with multiple versions of Presentation Server, use the previous version of the Presentation Server Console to manage network printer settings for previous versions of Presentation Server in your farm.
• Presentation Server 4.0 and Service Pack 2005.04 cannot be installed on a domain controller. Please refer to Knowledgebase article CTX106529 for further information.
• For more information regarding Service Pack 2005.04 please refer to the Service Pack 2005.04 FAQ.

Migration Steps
The following sections explain the procedures for migrating to Presentation Server 4.0 from a licensing and installation\upgrade perspective.

• Migration of licenses for MetaFrame 1.8, MetaFrame XP and Presentation Server 3.0
• Migration of MetaFrame XP FR3 and Presentation Server 3.0 software
• Migration of MetaFrame XP FR2 or earlier software


Migrating Licensing
From a licensing perspective you can only migrate directly to Citrix Presentation Server 4.0 from MetaFrame XP. If you are running MetaFrame 1.8, you must first migrate to MetaFrame XP and then migrate from MetaFrame XP to Citrix Presentation Server 4.0. For more information, refer to the Migrating from MetaFrame 1.8 to Citrix Presentation Server 4.0 section below.
If you are a current Subscription Advantage customer, you are eligible to migrate, or fulfill, your existing MetaFrame XP connection licenses to Presentation Server 4.0 as a benefit of the Subscription Advantage program. This exchange allows you to maintain the same level of user connectivity as you move from MetaFrame XP to Presentation Server 4.0.
Presentation Server 3.0 farms may continue to use their existing licenses if the Subscription Advantage Expiration Date in their license file is after the Subscription Advantage Eligibility Date of April 27, 2005. If not, renew your subscription advantage membership and obtain a renewal license. After renewing, logon to http://www.mycitrix.com to download your license file and add it to your license server.
See the sections below for step-by-step procedures.


Migrating Licenses from MetaFrame XP to Citrix Presentation Server 4.0

To migrate to Presentation Server 4.0, complete the following tasks:
1. Exchange your existing product license for a MetaFrame Access Suite 4.0 license code. Before you begin, you must have the license code from your existing product (that is, MetaFrame XP, MetaFrame Secure Access Manager 2.0, or MetaFrame Password Manager 2.0/2.5) handy.
2. Install the Access Suite License Server and License Management Console from the Presentation Server 4.0 CD-ROM. For further information on installing the licensing components please refer to the Access Suite Licensing Guide.
3. Logon to MyCitrix.com.
4. Click on the Licensing menu and choose the Fulfillment -> Fulfill Eligible Products option.
5. On the Product Fulfillment Selection page choose your license program type and the product to which you want to migrate (i.e. Citrix Presentation Server).
6. Follow the rest of the migration process. A Product Fulfillment Certificate verifies license conversion and presents the resulting license codes. You will be given a new Access Suite license code. To active and download license files:
7. From the License Management Console Welcome page, click Configure License Server. On the License Files page, click Download license file from MyCitrix.com.
8. Choose Licensing > Citrix Activation System > Activate or Allocate Licenses. The Citrix Activation System prompts you through the activation process until you receive a notice that the licenses are successfully activated.
9. Choose Download License File from the left menu.
10. You can choose to allocate all or a portion of the licensed quantity. For the License Server Name, type the name of the license server where you will be storing this license file. The server name is cAsE sENsiTiVE.
11. Download the license file.
12. In the License Files page, click Copy license file to License Server.
Note: The Citrix Activation System saves files by default to the last location you used for the Save As control. License files have the extension .lic. You can search for license files with the text string *.lic.
13. In the License Management Console, navigate to the Licenses Files pages of the Configuration tab.
14. In the License Files page, click Copy license file to License Server.
15. In the License Files page, click Update License Data.
Caution: Do not edit license files without understanding their format. You can unintentionally corrupt them and render the licensing system unusable.
Migrating Licenses from MetaFrame 1.8 to Citrix Presentation Server 4.0
If you are using MetaFrame 1.8, you must follow a two-step process that involves first converting your licenses to MetaFrame XP and then converting these licenses to Presentation Server 4.0. You must install and activate the MetaFrame XP licenses before you convert them to Presentation Server 4.0.
To migrate licenses from MetaFrame 1.8:
1. Log on to MyCitrix.com (http://www.mycitrix.com).
2. Choose Licensing > Fulfillment > Fulfill Eligible Products. Follow the onscreen instructions to choose the licensing program type of your license and select MetaFrame XP Presentation Server as the product you want to receive. Note that your Subscription Advantage must be current in order for this to work.
Note: The Citrix Activation System saves files by default to the last location you used for the Save As control. License files have the extension .lic. You can search for license files with the text string *.lic.
3. Follow instructions on the MetaFrame XP Presentation Server Migration page to select licenses to migrate. A Product Fulfillment Certificate confirms license conversion and displays the resulting license codes.
4. Install and activate the MetaFrame XP license code in the Citrix Management Console of your MetaFrame XP farm.
5. After you activate the license codes for MetaFrame XP, you can use the procedures in the previous section to migrate the MetaFrame XP licenses to Presentation Server 4.0, allocate the licenses into license files, and download the license files to your license server.
6. For more information about planning your deployment, installing a license server, and obtaining license files, please refer the Citrix Access Suite Licensing Guide.
Because licensing is a crucial part of your product installation, Citrix recommends that you read the licensing manual before installing Access Suite licensing. Configure a license server before attempting to migrate licenses. You designate a license server when you download the license files that result from converting existing licenses.

Migration of MetaFrame XP FR3 and Presentation Server 3.0 Farm Software

Migration of MetaFrame XP FR2 or Earlier Software
Direct upgrades to Presentation Server 4.0 from versions of MetaFrame XP FR2 or earlier are not supported. You may upgrade to Presentation Server 3.0 first and then upgrade to Presentation Server 4.0. However, there would be less effort involved in uninstalling the earlier versions and installing a fresh copy of Presentation Server 4.0. For information regarding the migration of a MetaFrame XP FR2 or earlier farm, please refer to Presentation Server 4.0 Administrator’s Guide. It contains a step-by-step explanation of the sequence of actions and strategies required for a smooth migration.
MetaFrame Presentation Server no longer supports interoperability mode. Because
there is no longer support for interoperability with farm servers running MetaFrame
1.0 or 1.8, follow this general procedure for the migration of a server farm.
To migrate a farm from MetaFrame 1.0 or 1.8
1. Install the latest version of MetaFrame Presentation Server on a server that is independent of your MetaFrame 1.0 or 1.8 farm.
2. Use the Presentation Server Console to configure your newly installed farm to match the settings of your farm running MetaFrame 1.0 or 1.8. Ensure that you also match the settings for published applications. Alternatively, you can create a script to export and import published application information. See the Citrix Developer Network (http://apps.citrix.com/cdn/) for additional information about the Citrix Application Publishing SDK and MetaFrame Presentation Server SDK (MPSSDK).
3. Deploy Web Interface (or MetaFrame Secure Access Manager) as the primary entry point for your newly installed farm. Use DNS CNAME (alias) records for the Web Interface servers. Use a simple mnemonic for the DNS alias, such as myapps. For example, Citrix could have an internal Web Interface deployment with multiple servers that share the DNS alias myapps.citrix.com. Not only is this configuration easy for users to remember, it is also useful for load balancing multiple Web Interface servers.
4. Open the new deployment for testing by pilot users.
5. After refining the pilot deployment, switch users to it. Instruct users to access your Web Interface server URL. Here is an example based on the previous DNS alias example: https://myapps.citrix.com
6. If most clients in your organization are Win32 based, Citrix recommends that you deploy Web Interface with Program Neighborhood Agent. Use the Citrix client packager to repackage the Program Neighborhood Agent and include the URL of your Web Interface deployment.
7. Deploy the new package to client desktops using Active Directory group policy, Microsoft Systems Management Server (SMS), or other third party deployment product. This deployment method requires no user input.
8. Decommission the farm running MetaFrame 1.0 or 1.8. You can use the Web Interface for MetaFrame Presentation Server 4.0 to aggregate the published applications from the MetaFrame 1.8 farm alongside the MetaFrame Presentation Server 4.0. This is useful if the transition from MetaFrame 1.8 to MetaFrame Presentation Server 4.0 takes place over a period of weeks or months. When using Web Interface with MetaFrame 1.8, you must ensure that ICA authentication tickets are disabled for the MetaFrame 1.8 farm configuration. If ICA authentication tickets are not disabled, the following message is displayed in the browser of the Web Interface client:
Error: An error has occurred while connecting to the requested
resource.
You also see the following event in the application log of the Web Interface
server:
Event Type: Error
Event Source: Web Interface at
Event Category: None
Event ID: 0
Description:
The farm has been configured to use MetaFrame Presentation
Server ticketing, but no ticket tag was received.
Check that the farm supports ticketing. [Log ID: a561610e]For more information regarding the migration a MetaFrame XP FR3 or Presentation Server 3.0 farm please refer to Migration to Presentation Server section of the Presentation Server 4.0 Administrator’s Guide.
Citrix recommends that you maintain all servers in a farm at the most recent release level of MetaFrame Presentation Server. If you find that you need to run different release levels of MetaFrame Presentation Server in your server farm on a temporary basis, configure a server running the latest release as the zone’s data collector.
To migrate a server farm to MetaFrame Presentation Server
1. Verify installation prerequisites - To verify that your computer satisfies installation prerequisites for each component you are installing, review the installation checklist. To access the installation checklist, select View installation checklist from the initial Autorun screen.
2. Install the license server - Citrix licensing has changed from MetaFrame XP, Feature Release 3. If you are upgrading from MetaFrame XP, Feature Release 3, before you upgrade the first server in a farm, install a license server. Before upgrading, ensure you download current licenses. For information about installing the license server, see the MetaFrame Access Suite Licensing Guide.
3. Upgrade MetaFrame Conferencing Manager from Version 2.0 to Version 3.0 or 4.0. MetaFrame Conferencing Manager, Version 2.0 is not compatible with this version of MetaFrame Presentation Server.
4. Turn off interoperability mode in the farm you are migrating.
5. Upgrade farm metric servers and database connection servers. If you are upgrading from an earlier release of MetaFrame Presentation Server, Enterprise Edition, upgrade the farm metric servers (primary and backup) before upgrading other servers in the farm. Resource Manager, a component of Enterprise Edition, uses the farm metric servers to interpret information collected from other servers. Farm metric servers running earlier versions of Resource Manager than other servers in the farm may cause inconsistencies. MetaFrame Presentation Server 3.0 for Windows Server 2003 MetaFrame Presentation Server 4.0 for Windows Server 2003.
6. Upgrade Presentation Server Console, Access Suite Console, and Web Interface. To automatically upgrade the consoles and the Web Interface and preserve custom configuration settings, accept the default settings of the Install MetaFrame Presentation Server and its components option in Autorun. Accepting the default settings automatically upgrades the consoles and the Web Interface before upgrading the server and preserves custom configuration settings. Note When you upgrade the Access Suite Console, or if you are sharing My Views between systems running different versions of the Access Suite Console, there are certain restrictions on how the upgraded console recognizes previously saved My Views. Specifically, this restriction applies if you are using the consoles included with MetaFrame Presentation Server 3.0 and MetaFrame Presentation Server 4.0. If, after upgrading, you are asked whether or not you want to upgrade your .msc configuration file, choose one of the following options: • If you choose to Upgrade your file, you cannot use an older version of the console to access the My Views stored in the file, but you can save My Views in your new version of the console. • If you choose Don’t Upgrade, the file is not upgraded. You can continue to use either version of the console to access the My Views stored in the file, but you can save only My Views to this file using the older version of the console.
7. Upgrade zone data collectors.
8. Upgrade farm servers.
9. If you are using MetaFrame Conferencing Manager, install and configure the Guest Attendee Web Interface.

Roll Back / Lower Active Directory Functional Levels in Windows Server 2008 R2

In Windows Server 2008 R2, you can now roll back (lower) the domain functional level (DFL) and forest functional level (FFL). There are a couple of conditions and limitations to this new functionality, which I discuss below.

Background Information

Functional levels control the Active Directory Domain Services (AD DS) features that are enabled in a domain or forest and restrict the operating systems that can run on domain controllers. For more details on functional levels, see Understanding AD DS Functional Levels (http://technet.microsoft.com/en-us/library/cc754918.aspx).
In previous versions of Windows Server, changes to functional levels could not be rolled back. In other words, when you raise the DFL from Windows Server 2003 to Windows Server 2008, you cannot lower the DFL back to Windows Server 2003.
In Windows Server 2008 R2, you can roll back functional levels provided you meet the below mentioned conditions.

Domain Functional Level

In my test environment, I took a DC that has Windows Server 2008 R2 RC installed, and raised the DFL to Windows Server 2008 R2.
You will notice in the image below that the warning for changing the DFL has changed in WS08R2 to state that the change might not be reversible:

To roll back / lower the DFL, you need to meet certain conditions:

1. The current DFL must be set to Windows Server 2008 R2.
2. The forest functional level (FFL) must support domains of the DFL you are rolling back to. For example, if the DFL and FFL are set to Windows Server 2008 R2, you cannot roll back / lower the DFL to Windows Server 2008 because the Windows Server 2008 R2 FFL can only have domains with a DFL of Windows Server 2008 R2.

In addition, there is a limitation to rolling back / lowering the DFL. Specifically, you can only roll back to Windows Server 2008, no earlier. In other words, you cannot roll back from a DFL of Windows Server 2008 R2 to a DFL of Windows Server 2003, even if you had previously raised the DFL from Windows Server 2003 to Windows Server 2008 R2.

Roll Back / Lower the Domain Functional Level

In build 7100 (RC) of Windows Server 2008 R2, there is no way to roll back / lower the DFL by using the GUI. Instead, you must use the Set-ADDomainMode cmdlet, which is included with the Active Directory Module for Windows PowerShell in Windows Server 2008 R2. The process is as follows:

1. Open the Active Directory Module for Windows PowerShell (Start, Administrative Tools, Active Directory Module for Windows PowerShell)
2. At the PowerShell prompt, type the following command and then hit Enter:
   Set-ADDomainMode -Identity WS08R2RCDomain.local -DomainMode Windows2008Domain
   NOTE: Replace WS08R2RCDomain.local with the FQDN of the domain you want to roll back / lower the DFL on.
3. On the confirmation, shown in the image below, type Y, and then hit Enter to proceed.

At this point, you will not see any confirmation that the change was successful in PowerShell (let’s hope this is added to the RTM). You will simply be back at the PowerShell prompt if it was successful.
However, you can look for an event logged in the Directory Service log, with an event ID of 2039, that will tell you the DFL has been changed to 3, as shown below.

NOTE: A DFL shown as “3” represents Windows Server 2008. A DFL shown as “4” represents Windows Server 2008 R2.
You can also use the Get-ADDomain cmdlet, which is included with the Active Directory Module for Windows PowerShell in Windows Server 2008 R2. The image below shows the output of this cmdlet.

Forest Functional Level

When raising the FFL through Active Directory Domains and Trusts console, you will see a warning that the change might not be reversible.
To roll back / lower the FFL, you need to meet certain conditions:

1. The current FFL must be set to Windows Server 2008 R2.
2. Advanced Features (such as Recycling Bin) cannot be enabled. If you previously enabled the Recycling Bin feature, you are SOL because this feature cannot be disabled once it has been enabled. The fact that you cannot roll back / lower the FFL if Advanced Features are enabled is something you seriously need to consider and plan ahead for. If you have enabled other Advanced Features, but not the Recycling Bin, you can use the Disable-ADOptionalFeatures cmdlet, which is included with the Active Directory Module for Windows PowerShell in Windows Server 2008 R2.

There is a the same limitation to rolling back / lowering the FFL as there is with the DFL. You can only roll back to Windows Server 2008, no earlier. In other words, you cannot roll back from a FFL of Windows Server 2008 R2 to a FFL of Windows Server 2003, even if you had previously raised the FFL from Windows Server 2003 to Windows Server 2008 R2.

Roll Back / Lower the Forest Functional Level

In build 7100 (RC) of Windows Server 2008 R2, there is no way to roll back / lower the FFL by using the GUI. Instead, you must use the Set-ADForestMode cmdlet, which is included with the Active Directory Module for Windows PowerShell in Windows Server 2008 R2. The process is as follows:

1. Open the Active Directory Module for Windows PowerShell.
2. At the PowerShell prompt, type the following command and then hit Enter:
   Set-ADForestMode -Identity WS08R2RCDomain.local -ForestMode Windows2008Forest
   NOTE: Replace WS08R2RCDomain.local with the FQDN of the domain you want to roll back / lower the FFL on.
3. On the confirmation, shown in the image below, type Y, and then hit Enter to proceed.

Once again, you will not see any confirmation that the change was successful in PowerShell (let’s hope this is added to the RTM). You will simply be back at the PowerShell prompt if it was successful
However, you can look for an event logged in the Directory Service log, with an event ID of 2040, that will tell you the FFL has been changed to 3, as shown below.

You can also use the Get-ADForest cmdlet, which is included with the Active Directory Module for Windows PowerShell in Windows Server 2008 R2. The image below shows the output of this cmdlet.

Conclusion

The ability to roll back / lower functional levels is a valuable new feature in Windows Server 2008 R2. I don’t think this is something that will be used on a frequent basis. However, having this as an option is definitely an added benefit.
It would be great if Microsoft fixes some of the issues with the steps to roll back / lower functional levels. Specifically:

• Add a way to roll back / lower functional levels through the GUI.
• Fix the Set-ADDomainMode cmdlet so that it reports the success of changing the DFL.
• Fix the Set-ADForestMode cmdlet so that it reports the success of changing the FFL.

Lastly, the fact that the FFL cannot be rolled back / lowered if the Recycling Bin is enabled, coupled with the fact that the Recycling Bin cannot be disabled after it has been enabled, are potential pain points.
All in all, I’m glad to see this new functionality in Windows Server 2008 R2, and I can live with using PowerShell cmdlets to leverage this feature.

XenApp: Publishing Server desktop

XenApp: Publishing Server desktop

For some non-windows clients or for some legacy applications, sometimes we needs to publish server desktop running XenApp. After publishing servers desktop, users are given access to server running XenApp and all the underlying resources, so it is risky as users can change any configuration of the underlying XenApp that may end up in messing the environment. To minimize risk, server desktop should not be published to less experienced users or if published, proper policies through GPO should be implemented.
Access Management console is required to publish XenApp desktop.
Below are the steps required to publish a Server desktop.
Prerequisite:

1. Citrix Access Management console should be installed on the XenApp farm.
2. Person who is publishing server desktop should have full administrative rights on Access management console.

Steps:

2. Right Click on “Applications” folder and Select New –> Create Folder as  shown below:

3. Following screen will appear:

Enter the application name and click ok. It will create “Desktops” folder under the applications node.

4.  Right click on “Desktops” folder and select New –> Publish application. “Welcome” screen will appear: Click Next

5.  “Name” screen will appear, add the following details and Click Next:

 Display Name: desktop – SERVERNAME | Application description: desktop – SERVERNAME

6.  “Type” screen will appear, Select the radio button for “Server desktop” and Click Next.

7.  “Servers” screen will appear, Click on “Add” button to add all the servers whose desktop needs to be published. Servers added here will be having load balancing.

8.   “Users” screen will appear for adding users who will have access rights on the published desktop. Click Add button and it will open “second screen”. On that screen, click on “Add List of Names” button to add the users. “third Screen” will appear. Enter the users into the screen and click “Check Names” button to see the validity of the entered users. Once verified click Ok. Click Ok on second screen and click Next on First screen.                              Note: You can add any number of users from the below screens but the best practice is to have active directory group containing all the required users and that group can be added directly to the below screen. With active directory group it is very easy to manage users. By manage I mean, addition and deletion of users.

9.  “Shortcut Presentation” screen will appear. Enter “Desktops” folder in the textbox for “Client application folder”. If the user access is through web ICA, do not check the checkbox for “add to the client’s start menu” and “add shortcut to the client’s desktop”.                                                                                 Note: You should enter the folder name that you have created at step 2 above. Users will see the application icon under this folder in their web ICA session. 

10.  Check for the icon to be displayed to the users. If you want to change it, click on change icon button, following screen will appear, select the appropriate radio button and get the required icon and click Ok and then click Next to the parent screen.

11.   “Publish immediately” screen will appear, select the checkbox for “Configure advanced application settings now” and click next.

12.  Access control screen will appear: Keep the default options and click next.

13.  “Limits” screen will appear: Depending on the application architecture and the bandwidth, check the checkbox for “Limit instances allowed to run in server farm” and then add Maximum instances. Click Next.

14.  “Appearance” screen will appear: Select the appropriate session window size and required color depth. Click Finish.                 Note: For seamless mode, selecting any value under “session window size” will not make any difference.

After this step, server desktop will be published and available under “Desktops” folder. Users who are given access to this icon, will be able to see it in Web ICA session.  

1. Double click on the desktop icon “Access Management Console” or launch the exe “CmiLaunch.exe” from "C:\Program Files\Common Files\Citrix\Access Management Console – Framework\". Citrix Access Management console window will be launched. Left side of window will have tree structure as shown below. It has a node for Presentation server and under it, there is a node for XenApp farm. It has different folders under it to manage the farm. For this article, our interest is the “Applications” folder under it.