Along with the Active Directory Recycle Bin, a tremendous benefit to upgrading your Active Directory functional levels to 2008 R2 is the ability to use DFSR replication between domain controllers. With 2003 and earlier, domain controllers used File Replication Services to replicate directories like SYSVOL. FRS has several drawbacks such as having to retransmit entire files and minimal self-healing capabilities.
With 2008 and later versions, you can migrate from FRS to DFSR (Distributed File System Replication). DFSR can replicate only changed bits (useful for large logon scripts, company wallpaper, install files, and other items commonly found in the SYSVOL directory) and has more robust self-healing capabilities for conflict resolution.
Domains that are installed with 2008 or later functionality will have DFSR enabled by default. This procedure is only necessary for domains and forests that have been upgraded from 2003.
Read more >>
Upgrading your Active Directory domains and forests to the Windows Server 2008 R2 functional level can streamline some administrative functions. The biggest benefit of the 2008 R2 forest functional level is the Active Directory Recycle Bin. If you’ve ever had to use Directory Services Restore Mode to resurrect AD tombstones and retrieve deleted objects, you’ll love this feature.
How do I enable it?
- With a single line of Powershell (replace contoso.com and DC=contoso,DC=com with your domain name):
-
Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=contoso,DC=com’ –Scope ForestOrConfigurationSet –Target ‘contoso.com’
What are some benefits?
- Object SIDs are maintained after the restore
- Group membership is maintained after the restore
- Objects can be restored from 60-180 days after their deletion (varies per domain)
- Entire OUs and child objects can be restored with a single action
- Complex structures such as DNS zones can be restored with all records intact
Read more >>
While building out a new XenApp 6.5 farm and handling the profiles through Citrix’s User Profile Management utility, I noticed some issues where the local profiles were not being deleted on logoff as I had configured them to be.
After doing some checking and verifying what I had set in the GPO was being “applied” configuration-wise to the server, I stumbled across Ctrix article which outlined our scenario, with the solution.
It turns out that when you install VMware tools, it includes a “Shared Folder” option, which remains locked on user logout and does not allow for the profile to be properly deleted. When this happens, the next time the user logs in to that server, it creates a new profile for them along the lines of “user.domain”, and increments that each time after, as in user.domain.001, user.domain.002, and so on.
Read more >>
In previous releases of Citrix’s XenApp solution, every server in the Farm was required to download all of the Farm’s data to its Local Host Cache when joining. This process consumes large amounts of bandwidth, which on a WAN connection can be especially problematic. Not to mention, the XenApp servers were forced to devote resources to the overhead processes involved with maintaining numerous read/write operations with the IMA datastore.
To resolve this issue Citrix has created a separate “Worker” role for servers joining a XenApp 6.5 Farm. With this role installed, the servers operate in a “Session-only” or “Session-host” mode. These servers operate with the one task of hosting user sessions, and as a result only need to sync a subset of data to their LHCs. Meaning that these servers operate with much less overhead than a traditional “Controller” mode server allowing them to join the Farm much faster, consume less bandwidth, and consume less resources overall. On the flip side, these hosts are unable to serve as Zone Data Collectors, perform XML brokering tasks, and/or participate in IMA elections.
The server mode is selected when first joining the machine to the XenApp Farm. To switch modes, the server must leave then re-join the Farm. A well planned XenApp 6.5 deployment with the right quantity of Controller and Worker servers allow for a significant performance improvement over environments with a previous version of XenApp installed.
For some time now system administrators have struggled with presenting users in a terminal server environment with a Windows 7 type workstation without deploying a full VDI (Virtual Desktop Infrastructure) solution. Now with Citrix XenApp 6.5, employees using a shared server desktop can instead be given a desktop that mimics the look and feel of a full Windows 7 machine.
The technology is titled “Windows Desktop Experience Integration”, and it can be installed via the Server Role Manager. The process for enabling and deploying this solution is very simple. When Windows Desktop Experience Integration is installed, a PowerShell script called “New-CtxManagedDesktopGPO.ps1″ is placed in the “Program Files (x86)\Citrix\App Delivery Setup Tools” directory. Launch this script and four new Group Policy objects will be added to your Microsoft Group Policy Manager application. The policy titled “CtxStartMenuTaskbarUser” will enable the Windows 7 user experience. Link this policy to the OU containing your XenApp servers with published desktops, and you are good to go. The other three policies allow for more granular user/computer management in the XenApp session.
