So What's This All About

The purpose of this site

I started off my career in IT 25 years ago as a COBOL Programmer in South Africa and have progressed (or some may say regressed) to consulting on virtualization technologies. I created this site to share my experiences with virtualization and cloud computing, as well as the latest virtualization news, tips, tricks and tools from other experts in the field.

Online Training

XenDesktop 7 Course

Citrix Education is offering a self-paced introductory course on XenDesktop 7. If you’re new to XenDesktop 7 and want to learn more about it, this is a great opportunity to get some training for free.

Click here for the course details

Keep Tabs on Me

Social media links

RSS Feed 2.0


The XenDesktop Blueprint

An article by Daniel Feller from Citrix Blogs

The users are first.

This is why we have a blueprint for XenDesktop 7 because we want to avoid starting wrong. We want to make sure that the first thing we focus on are the users.

Think about it this way, when building a house, one of the first things you have to figure out is what type of a house do you want/need (bungalow, cottage, mansion, split level, etc). Sometimes, you might determine that you don’t need a house and end up with a condo or apartment. To make this decision, you have to look at yourself and understand your needs (how much space, size of yard, number of bedrooms, etc). When defining your needs, you must not only look at today, but also look at what you anticipate the future to hold, because most of us don’t want to move houses every year.

The exact same thing takes place with a virtual desktop solution… Figuring out what type of resources you need (notice that I didn’t say “what type of desktop you need” because not everyone requires a desktop just like not everyone needs a house).

With so many housing options, many times people get stuck in simply trying to figure out what kind of house they need, or they come up with 3-4 options and can’t make that final decision. Again, the same thing happens with desktop virtualization, do I need a non-persistent, persistent or applications.

The thing we tried to accomplish with the blueprint is to provide a starting place based on numerous successful implementations. For example, what if an organization was trying to better protect information through centralization for 3 user groups with the following characteristics:

Call center users focused on getting through a large call volume as quickly as possible with as few distractions as possible.

Engineers who need to do a lot of trial and error and are often looking for alternatives to their current tools that aren’t optimal

Road warriors who are always on the go and sporadically need to enter or review a piece of information contained within a small number of applications.

Based on this scenario, we can start to create our conceptual architecture based on the framework we defined in the earlier blog.

Read More


NetScaler Cluster

An article by Abhilash Verma from Citrix Blogs

NetScaler has come through a long way of being a Kernel based Packet Engine to user mode Multi Core (nCore) platform and today you can Cluster these nCore devices together. All flavors of NetScaler (VPX, MPX and VPX over SDX) support Cluster mode of deployment. With release 10.1 we support most of the important features in Cluster mode and thus we see more and more customers deploying Cluster. We also recommend to deploy an HA pair as 2-node Cluster as it provides better compute power, throughput and overall system resources. Your investment is fully utilized in 2-node Cluster setup while you get performance and scalability advantages.


As we get more Cluster deployments coming up, it is important to understand what’s new and how you should approach it for optimal usage of resources. There are multiple topics of interest here and we will try and cover the key topics in next couple of blogs.


Quick facts about NetScaler Cluster:

  1. Cluster of NetScaler nodes
  2. Built on NetScaler nCore architecture
  3. All form of appliances can be Clustered
  4. Cluster can be formed with 2 to 32 nodes
  5. Remains single system image for end user
  6. No Chassis or new hardware required
  7. Nodes can be placed in different racks over L2
  8. Dynamic changes permitted in run time


Some of the key benefits:

  1. Provides linear scalability
  2. Higher Throughput
  3. Configuration Scalability
  4. In-built Fault Tolerance
  5. Active-active Support
  6. Active-standby Support
  7. Unified Configuration
  8. Unified Monitoring
  9. Unified NITRO APIs
  10. Allows HA to be moved to Cluster


Here is how the logical topology looks like:


Read More


The Blueprint for XenDesktop 7

An article by Daniel Feller from Citrix Blogs

Here is a little secret… Most XenDesktop environments are extremely similar. In fact, if you ignore the numerous hardware combinations out there, the similarities increase significantly.

You have user groups (some internal and some external) that need access to some type of resource, whether it be a desktop or an application, which is managed by a set of controllers all running on hardware.

So why is desktop virtualization so complex? Because we made it that way by believing that every deployment must start from scratch.

Think about if you were going to have a house built. You would start with a high-level blueprint. The first thing you do is figure out what type of house you want built: a rambler, split level, 2-story, etc., but it will have the same fundamental components (HVAC, electrical, plumbing, framing, roofing, etc). However, the first things you think about shouldn’t be the electrical wiring. It would be insane to start here because you don’t even know where the walls are going to be located that will contain the wires. So tell me why when doing desktop virtualization do people start with storage or servers?

This is why we have a XenDesktop 7 blueprint. To guide you on your way towards creating a desktop virtualization solution, every XenDesktop 7 solution has 5 parts:

Read More


Provisioning XenDesktop 7 Apps and Desktops with CloudPortal Services Manager 11

An article by Ryan Morey from Citrix Blogs

CloudPortal Services Manager (CPSM) 11 has the ability to provision Applications and Desktops from XenDesktop 7 using the existing Citrix service. The configuration process is much like process for setting up the Citrix service with XenApp, just with some manual tweaks.

XenDesktop will need to be deployed in either the same domain as the primary CPSM location, or the domain of a secondary CPSM location. Once XenDesktop is successfully deployed you’ll need to install the Citrix Service, from the CPSM media, onto the server. When installing the Citrix Service, it is important to run the installer CortexCitrixWS.msi directly, do not use the Autorun. After the installation you’ll need to navigate to “C:\Program Files (x86)\Citrix\Cortex\Services\CitrixWS\Configuration” and run the configuration for the Citrix Service. It is expected that the last task “Add XenApp Administrator” will fail. If all other tasks completed successfully you can click Finish. For additional guidance on installing and configuring the Citrix Service, you can visit the edocs page for this here.

Now that you have XenDesktop with the Citrix Service setup, you’ll need to configure the Citrix Service within the CPSM Web portal. For guidance on configuring the Citrix Service within CPSM, you can visit the edocs page for this here . At this point you’ll be able to successfully test the connection to the XenDesktop 7 server.

As the top Reseller, or CSP Reseller, you will need to manually create the XenDesktop Apps and Desktops in CPSM; this is due to the limitation of the Citrix Service. To create the App or Desktop navigate to Services -> Citrix -> Configuration -> Applications. On this page you will create a new application for each XenDesktop App or Desktop that you want to use. When creating the application, the Directory Name is important to remember, as we will use this name again in the XenDesktop Delivery group later.

In the example below I’ve created an application for a Windows 8 Desktop, which has a Directory Name of CitrixApp4.



You can create the application in CPSM before or after you’ve created the Apps or Desktops in XenDesktop. The important thing is that you use the same Directory Name for the application in CPSM that maps to the XenDesktop App or Desktop.

Read More


Citrix Virtual Desktop Handbook Hyper-V Update

An article by Ed Duncan from Citrix Blogs

XenDesktop relies on the hypervisor for many core functions, including VM creation, power operations, performance and redundancy. Therefore, it is important that you take the time to design an appropriate hypervisor infrastructure (XenServer, Hyper-V or vSphere). Otherwise, you may experience performance, functionality or even reliability issues.

Most information required to design a XenDesktop deployment on your chosen hypervisor platform is available publicly, but it can be hard to find since it’s spread across a multitude of knowledge base articles or white papers. In order to simplify and speed-up the design process, we’re in the process of consolidating the information that you need into a single document and augmenting it with recommendations and best practices. We’ve just finished incorporating the Hyper-V 2008 R2 and SCVMM 2012 planning section into the latest release of the Citrix Virtual Desktop Handbook, which includes important design decisions relating to this hypervisor, for example:

Read More


Limiting a user to 2 instances of an application

An article by James Denne from Citrix Blogs

Recently a UK TRM customer posed a question to their TRM:

“I need to limit our users to running two instances of a particular application. How can I do this?”

There was quite a bit of head-scratching in the team about how to do this…

  • load evaluator?
  • some sort of policy?
  • Could the option to limit users to 1 instance of the application be adjusted to limit a user to 2 instances?

So the obvious candidate is the published application setting to limit a user a single instance of the application; here is a screenshot of this option taken from XenApp 6.5:

Wouldn’t it be great if there was a UI option to set a flexible per-user limit for a published application? Sadly there doesn’t seem to be such an option, even “under the covers”.


The customer’s desire to limit the application to two instances per user was due to the resource consumption of the application, which needed to be kept in check for the benefit of the wider user community. However, this needed to balanced against the flexibility the user community needed to run multiple instances of the application. To simplify administration the customer did not want to stand up a separate silo of XenApp servers just for this application.


Based on these requirements we had several suggestions for the customer:

Read More


Delivering the PVS Bootstrap via HTTP

An article by Thomas Berger from Citrix Blogs

Since Provisioning Services became part of the Citrix product portfolio we have talked a lot about the various options to pass the PVS target devices the information required to download the bootstrap and connect to the PVS infrastructure. I’m not going to reiterate all options in this blog, so if you need to get up to speed check out eDocs – Getting the Bootstrap File.

One of the most popular options is to use DHCP option 66 (Boot Server Name) and option 67 (Boot File Name). The downside of this approach is that both DHCP options allow a single entry only. So for example if you specify PVS1 as the boot server and PVS1 goes down the target devices are not able to boot. Especially if you’re running a pooled desktop environment and you’re rebooting the virtual desktops automatically after user logoff, this can become a serious issue.

Now you may say, why not just use a load balancer to load balance the requests for the bootstraps among multiple servers? The problem is that the bootstrap is transferred by means of TFTP, which is quite hard to load balance. See “Load Balancing TFTP – Anything But Trivial” for more details.

When Dan Feller talked about PVS bootstrap delivery in one of last blogs “XenDesktop Fact: Provisioning Services does not require PXE” he got a very interesting comment form Justin Garrison. In short Justin mentioned that it is possible to deliver the bootstrap by means of HTTP and that he’s running that configuration without any problem for a while now.

Unbelievable! How can we have missed that for so long? Load balancing HTTP is a lot simpler than TFTP, so this would be a nice option to simplify a PVS infrastructure without relying on broadcasts (PXE) or using ISO files (BDM).


So what’s the story here?

After I saw that comment I reached out to the PVS development team immediately. Soon it became clear that transferring the bootstrap by means of HTTP is not defined in the formal PXE specification (, so we did not miss anything incredibly obvious. But we also realized that there are other PXE implementations, such as gPXE (, which add a lot more functionality (incl. HTTP transfer). “By coincidence” XenServer-based virtual machines use gPXE, so a HTTP-based bootstrap transfer actually is a viable option.

Read More


Licensing Costs: XenDesktop vs Horizon View

An article by Vishal Ganeriwala from Citrix Blogs

In my previous blog, I talked about how recent VMware sponsored reports are spreading misconceptions about XenApp. VMware has sponsored another report from Principled Technology that offers misleading information about the cost of XenDesktop versus Horizon View. The document comes to this number by inappropriately comparing the Horizon View pricing, which provides mostly VDI functionality, to the XenDesktop Enterprise Edition, which addresses a much wider range of use cases by offering multiple application and desktop delivery models (session based desktops (RDS), virtual Windows applications, VDI, local VDI via XenClient and secure remote access to desktops via Remote PC functionality). This is the equivalent of comparing a single hammer to a complete tool box consisting of a drill, hammer, pliers, screw drivers and much more. Of course, if you only have a hammer, every problem would look like a nail. A single hammer would be cheaper but look what you are getting and what you can build with all the tools.

For this report to be a fair comparison, VMware and Principled should have compared Horizon View VDI to XenDesktop VDI.

XenDesktop VDI offers more value at lower cost to View VDI license including 3 years subscription advantage with support:

This table calculates the cost of XenDesktop VDI for both concurrent and user/device SKU including, 3 years SA with support, Microsoft MDOP and vSphere for a desktop license

In the report VMware Horizon View is priced at $415 CCU including 3 years of SA and support.

For the concurrent license type, XenDesktop VDI with Microsoft MDOP is cheaper compared to VMware View VDI and offers higher density for additional infrastructure cost savings with better response time (check out LoginVSI response time XenDesktop response time stays below 4000 ms threshold)!

I have included Microsoft MDOP licenses with XenDeskop VDI because MDOP offers greater value to customers by adding App-V, UE-V and Med-V functionality for easier Windows XP to Windows 7 application migration. MDOP also offers advanced group policy management, bit locker administration and diagnostics and a recovery toolkit for managing desktops and other, simple IT operations.

If we take assumptions made by the VMware sponsored report (Number of users = number of connections, see page 40 of the report) then XenDesktop VDI (licensed per user/device) comes out to be 42% less expensive as compared to VMware Horizon View VDI! Horizon View doesn’t offer a user/device SKU, limiting customer choice and use cases. All my calculations are, so far, based on the assumptions that customers are deploying the VDI environment on vSphere and paying the vSphere $65 per-desktop fee but you can lower the license cost further by choosing to go with Hyper-V or XenServer, which are available for free, especially for VDI workloads

Even at a lower price, XenDesktop VDI plus MDOP offer more value; just take a look at table below.

Read More


Introduction to Networking for VMware Admins: Part 1, The Basics

An article by slowe from

This is the kick-off to a series of posts introducing networking concepts to VMware administrators. Based on the feedback I’ve gotten in speaking to VMware admins, networking is an area in which a lot of VMware-focused folks aren’t particularly comfortable. So, I thought it might be helpful to put up a few blog posts on networking concepts for VMware administrators. (If you’re already familiar with networking concepts, you probably don’t need to read this—unless you just have some free time on your hands.)

In this first article, I’ll cover some important networking basics. This will set the stage for discussions that will take place in future articles. Here are some of the topics that I’m going to cover in this first article:

  • Layer 2 versus Layer 3: the OSI and DoD models
  • Theory into reality: TCP/IP and Ethernet
  • Bridging, switching, and routing
  • Spanning Tree Protocol (STP)
  • ARP and Flooding

Ready? Let’s get started.

Layer 2 Versus Layer 3: The OSI and DoD Models

In networking, two “models” of how networked systems should communicate drive almost everything. In the beginning, there was the OSI (Open Systems Interconnection) model, a seven layer model that described and defined how two systems might communicate with each other in a standardized fashion across a network. This model is largely theoretical, but it is still important to understand because it shapes much of what is done today in networking. Each of these layers was written with the idea of being as generic and interoperable as possible; the idea was that you could have standards (or protocols) at each layer so that the layers could evolve somewhat independently of one another.

Two of these layers—layer 2, the Data Link layer, and layer 3, the Network layer—are the basis for the “layer 2″ and “layer 3″ discussions that you so frequently hear thrown about when someone is discussing networking. A “sub-layer” of the Data Link layer (layer 2) is also the basis for another term that you’ll hear frequently thrown about in networking: the MAC address. This sublayer is the Media Access Control, or MAC, sublayer, and it’s where MAC addresses are used.

<aside>Note that “MAC” and “Mac” are very different! The first pertains to the Media Access Control sublayer of the OSI model; the second pertains to a line of computers made by Apple, Inc. You shouldn’t call an Apple computer a MAC, and you shouldn’t refer to a Media Access Control address as a Mac address. OK, stepping off the soap box now…</aside>

The third layer of the OSI model, the Network layer, is the “layer 3″ that so often referenced in network discussions. Protocols like Internet Protocol (IP) and IPX operate at this layer.

After the creation of the OSI model, the US Department of Defense started work on what would eventually become the Internet. (No, it wasn’t invented by Al Gore. Sorry, Al.) As part of that work—I won’t cover that here as there have been plenty of other write-ups of that history—they created a four-layer model that became known as the DoD model or the TCP/IP model. The four layers of the DoD model—Link, Internet, Transport, and Application—have a rough correlation to the seven layers of the OSI model, as shown here. Despite this fact, discussions of “layer 2″ and “layer 3″ still refer to the Data Link and Network layers of the OSI model, and not to the DoD-TCP/IP model.

And that leads us to our next section…

Theory Into Reality: Ethernet and TCP/IP

The OSI model, in particular, is highly theoretical. As far as I know, there are no implementations that actually implement all seven layers. (They might implement the functions of all seven layers, but not the actual layers themselves.) However, the abstract nature of the OSI model was beneficial in the early days, when there were a number of different physical media types (Ethernet, Token Ring, ATM, etc.) and different network protocols (NetBEUI/NetBIOS, IPX/SPX, TCP/IP, SNA, etc.). Over time, though, the networking industry has—in the data center, at least, where this discussion is primarily focused—whittled itself down to just two standards that are almost universally deployed: Ethernet and TCP/IP.

Therefore, as I move through this series, I’m going to assume the use of Ethernet and TCP/IP. Yes, other protocols will almost certainly be present, but in the data center I think it is reasonably safe to assume the use of Ethernet and TCP/IP.

So, when I talk about “layer 2,” then, I am talking about Ethernet (and all of its variations: Ethernet, Fast Ethernet, Gigabit Ethernet, 10 Gigabit Ethernet). When I talk about a MAC address, I’m talking about an Ethernet address.

Similarly, when I talk about “layer 3,” I’m talking about Internet Protocol (the IP in TCP/IP).

This is not to say that other standards and other protocols don’t exist, but simply to narrow down the discussion so that I can productively move ahead with what I need to discuss.

Bridging, Switching, and Routing

A bridge is a device that operates at the Data Link layer (layer 2 of the OSI model) and is therefore referred to as a “layer 2 device” or a “Data Link device.” According to most definitions, a bridge has only two ports, and serves to connect two separate networks. A bridge can’t and doesn’t understand anything more than layer 2 stuff—it doesn’t know anything about upper layer protocols. Although there are different types of bridges, for the purposes of our discussion I’m going to assume the use of transparent bridges, meaning that the bridges are transparent to the hosts communicating across them. Cisco has more information on transparent bridging, which is the most common form of bridging in Ethernet-based networks.

A switch is, essentially, a multi-port bridge. It also operates at OSI layer 2 and doesn’t know about or understand anything with regards to upper layer protocols. Like a transparent bridge, a switch is invisible to the hosts communicating across it.

Neither bridges nor switches modify the frames that move across them.

A router is a device that operates at OSI layer 3. Because network protocols exist at layer 3, routers are generally protocol specific. I’ve limited the discussion here to TCP/IP, but routers exist for other network protocols as well. A key difference between bridges/switches and routers is that routers actually modify the packets moving across them, typically by changing the layer 2 addresses in the packet and by decrementing the Time To Live (TTL) counter. The TTL counter is a field that keeps a packet from endlessly circling the network; when the TTL expires (reaches 0), the packet is discarded. Ethernet frames do not have a TTL. (Routers also change the source and destination layer 2 addresses, but I’ll discuss that in more detail in a future post.)

Although you will see references to layer 3 switching, for the purposes of this series I will use switching to refer strictly to layer 2 functions and routing to refer strictly to layer 3 functions.

Now might also be a good time to discuss the idea of a broadcast domain (more information here). A broadcast domain encompasses all the devices and hosts that can reach each other by broadcast at the Data Link layer (layer 2). In other words, a broadcast domain will include all the devices and hosts that are connected by bridges or switches, but it will not include devices or hosts connected by a router. Broadcast domains are separated by layer 3 devices like routers.

Spanning Tree Protocol

Pop quiz time! Here’s your question: what happens if an Ethernet frame enters a switch, is forwarded out a port connected to another switch, which forwards the frame out a port back to the original switch?

This, boys and girls, is what is called a bridging (or switching) loop, and it is a Very Bad Thing. As I stated earlier, Ethernet frames don’t have a TTL, so there’s no notion of ensuring that a frame doesn’t circle the network endlessly.

Contrast that with what’s called a routing loop, where packets are sent to a router, which in turns sends them to another router, where they are then sent back to the first router, etc., etc. In this case, though, the TTL will be decremented each time the packet passes through the router, and eventually the TTL will expire. When the TTL expires, the packet is removed from the network.

To protect networks against bridging loops, the network experts created something called Spanning Tree Protocol (STP). The purpose of STP is to ensure that loops aren’t created as switches are connected to one another in larger networks. (In a single switch network, there’s obviously no need for STP.) This is clearly an admirable goal, but a side effect of STP is that it prevents multiple layer 2 paths between switches. I’ll have more to say about STP in future posts, but for now understand that STP is a necessary component in larger environments in order to prevent bridging loops.

ARP and Flooding

Recall from earlier in this post that addresses are employed at OSI layer 2 (these are called MAC addresses and, in the context of this discussion, are Ethernet addresses that look something like aa:bb:cc:11:22:33). You probably also already know that addresses are also employed at OSI layer 3, where IP resides. IP addresses—specifically IPv4 addresses, no need to discuss IPv6 just yet—are typically expressed in what’s called dotted decimal notation and look something like

There’s a reason I’m mentioning all of this. In order for two systems (I’ll call them Host A and Host B) to communicate with each other, they must know how to get from A to B (and back again). This means they need to know the correct addresses in order to be able to communicate. Generally, the hosts will know the IP address (or hostname, which will resolve to IP address via the Domain Name System [DNS]), such as in the example of your laptop connecting to a web server via a URL like “″ or “”.

Stepping back to our layer 2 vs. layer 3 discussion for a second, recall that IP addresses operate a layer 3. However, in order to communicate across an Ethernet network, the hosts need to know more than just the IP addresses—the hosts also need to know the Ethernet (MAC) addresses that operate at layer 2.

That’s where ARP (Address Resolution Protocol) comes into play. ARP performs the necessary function of associating an IP address with a MAC address. When Host A needs to communicate with Host B and knows the IP address of Host B but not its MAC address, it will send out an ARP query. This ARP query is sent to the Ethernet broadcast address of ff:ff:ff:ff:ff:ff. Because this is a layer 2 broadcast address, it will reach all other hosts in the same broadcast domain (I defined what a broadcast domain is earlier). Assuming Host B is on the same broadcast domain as Host A, then Host B will receive the ARP query and will respond directly to Host A (not via broadcast, but via unicast to Host A’s MAC address). If Host B is not on the the same broadcast domain, then it won’t see the ARP query, won’t respond to Host A, and Host A will fail to connect to Host B.

Flooding is a term used to describe the behavior of a switch under certain conditions. Layer 2 broadcasts, such as ARP queries, have to be sent to all the ports on the switch; after all, a broadcast frame is supposed to be sent to all hosts. A broadcast frame has to be flooded to all ports. However, there are other instances in which flooding occurs. Recall that a switch is a multi-port bridge, operating at layer 2, that directs frames from a source MAC address to a destination MAC address. What happens if the switch doesn’t know which destination MAC address corresponds to which switch port? In this case, the switch must flood the frame out all ports, because it doesn’t have the necessary MAC address-to-port mapping, even though it’s not a broadcast frame. The switch then listens for the response to that frame in order to learn what port should be used next time it needs to direct traffic to that particular MAC address. When it does learn the mapping between port and MAC address, it stores that in an internal data structure so that it can use it for future traffic flows.

I’ll wrap up this first post here. I’ll build on and expand upon these basics in the next post. In the meantime, feel free to post any questions you might have in the comments below. Networking experts, if I have misrepresented something—keeping in mind that I’ve simplified certain concepts to keep things digestible for newcomers—you are welcome to post corrections or clarifications in the comments. Courteous comments are always welcome.

This article was originally posted on Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Introduction to Networking: Part 1, The Basics


Default Domain Group Policy – What Should Be Configured?

An article by Carl Webster from Carl Webster

Ever since I started working with Microsoft Active Directory (AD) in July 2001, I have always wondered what should be configured in the Default Domain Group Policy Object (GPO).  I have had a couple of my AD mentors tell me what should be in the Default Domain GPO and I have parroted their recommendation for years now because I agree with them.  I am sure I also read somewhere in the past 12 years the Best Practices for this GPO but just have never been able to find it.  This morning I finally came across an article from Microsoft that clearly states what the Best Practices are for the Default Domain GPO.

Excuse me why I explain the journey that took me to the article.

I am currently rebuilding my lab to learn all the Microsoft System Center 2012 SP1 stuff.  I am using only Server 2012 for all my Virtual Machines (VMs).  With all the work I am doing with Server 2012 and since I am also planning on taking the Microsoft Private Cloud certification exams, I decided I needed to take the 70-417 exam (Upgrading your Skills to MCSA Windows Server 2012).  Since I have taken well over 200 certification exams since 1998, I consider myself a professional certification exam taker.  The first thing I do when I decide to take an exam is to look at what the vendor says will be on the exam.  Citrix and Microsoft calls that the Exam Preparation Guide.

The 70-417 exam is an upgrade exam for someone who already holds an earlier MCSA.  70-417 covers the same material as three other exams: 70-410, 70-411 and 70-412.  Microsoft offers a 70-417 study guide.

One of the items to be covered is recovering from a deleted GPO.  How do you recover a deleted (or from a really screwed up) Default Domain and or Default Domain Controllers GPO?  I haven’t had to do that since 2005.  Well you use the DCGpoFix command line utility.

Since I am a reader, I read the entire article.  Lo and behold, after all these years, I actually saw in writing from Microsoft the Best Practice I had been telling people about all these years.  Right there in the first paragraph under Examples:

As a best practice, you should configure the Default Domain Policy GPO only to manage the default Account Policies settings, Password Policy, Account Lockout Policy, and Kerberos Policy.

I cannot count the number of arguments I have had with Windows Admins over this.  And wouldn’t you know, my AD mentors have been correct all these years! :)

I once did a troubleshooting project for a Citrix XenApp 5 on Server 2003 environment for slow logons.  It seems ever since XenApp 5 had been installed and put into production, EVERY user on the network was experiencing slow logons and many other issues.  Naturally, of course, XenApp 5 received the blame.  The actual problem?  They had put over 800 lockdown configuration settings in the Default Domain GPO!!!!  And they wondered why every user on the network was affected!!!  Instead of having a separate Organizational Unit (OU) for the XenApp servers, they put them in the Computers Container (where you cannot directly apply any GPO).  They then put all their lockdown settings in the Default Domain GPO which instantly affected everyone.

The fix?

  1. Record the Account, Password, Account Lockout and Kerberos policy settings,
  2. Create an OU for the XenApp servers,
  3. Create a lockdown GPO and link it to the new XenApp server’s OU,
  4. Run DCGpoFix /domain to recreate the Default Domain policy,
  5. Edit the new Default Domain GPO and enter the recorded settings from Step 1 above,
  6. Move the XenApp servers to their new OU,
  7. Reboot the XenApp servers (necessary to affect the move to the new OU), and then
  8. Troubleshoot and fix remaining issues.

Projects like this are where I get the material for my “10 Things in AD…” presentations.  This is also why studying for certification exams can be beneficial.  Now I have proof I am correct in what I tell people should go in the Default Domain GPO.



You just finished reading Default Domain Group Policy – What Should Be Configured? on Carl Webster. Please consider leaving a comment!