Internet Explorer End of Life Nag

I was at a customer that recently complained that many of their Internet Explorer applications hosted on Citrix XenApp were opening additional tabs for users asking for Internet Explorer to be upgraded. This as it turns out is by design from Microsoft. As of January 2016 IE 8-9-10 are no longer receiving updates from the software giant. They want everyone to move to Internet Explorer 11. This nag screen is actually part of the last update to each to of the legacy browsers - so it is 100% by design.

Of course many enterprise applications were written to work with older versions of IE and development or testing cycles may not be available to simply upgrade. So how to get around this nag window? Fortunately Microsoft has enabled a new feature control registry value that can override this default option. Full details can be found here. I have included the snippet regarding x64 configuration below. Throw this in a group policy preference and apply where needed - no more nag screens!

For x64-based systems

1. Click Start, type regedit in the Start Search box, and then click OK.
2. Locate the following registry subkey:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl
3. Right-click FeatureControl, point to New, and then click Key.
4. Enter FEATURE_DISABLE_IE11_SECURITY_EOL_NOTIFICATION, and then press Enter to name the new key.
5. Right-click FEATURE_DISABLE_IE11_SECURITY_EOL_NOTIFICATION, point to New, and then click DWORD (32-bit) Value.
6. Enter iexplore.exe, and then press Enter to name the new value.
7. Right-click iexplore.exe, and then click Modify.
8. In the Value data box, enter 00000001, and then click OK.
9. Locate the following subkey:
   HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Main\FeatureControl
10. Right-click FeatureControl, point to New, and then click Key.
11. Enter FEATURE_DISABLE_IE11_SECURITY_EOL_NOTIFICATION, and then press Enter to name the new key.
12. Right-click FEATURE_DISABLE_IE11_SECURITY_EOL_NOTIFICATION, point to New, and then click DWORD (32-bit) Value.
13. Enter iexplore.exe, and then press Enter to name the new value.
14. Right-click iexplore.exe, and then click Modify.
15. In the Value data box, enter 00000001, and then click OK.
16. Exit Registry Editor, and then restart the browser to enable the new key.

XenDesktop 7.x Database Maintenance & Considerations

I recently spent time with a client having SQL issues related to XenDesktop. As it turns out they were exhausting transaction log space. I figured I would throw together a post about some of the considerations and best practices I have seen around this topic.

Considerations N'at

1. Monitoring: 
• First and foremost, whatever you design, something-will-fail-eventually. I cannot stress monitoring enough. From simple OS-level monitors such as disk space and event log scraping to more-in-depth (and expensive) end-to-end monitoring solutions. My personal favorites over the years have been ControlUp and Solarwinds. You can write your own via PowerShell with a little research if you can't spring for a third-party product. I just can't harp on this item enough.
2. One-or-many? 
• It is recommended to separate the 3 primary DB data sources into separate actual databases. A Site, Logging, and Monitoring DB. In the latest versions this is the option up front. Original releases this had to be done after the site was deployed. 
3. The Databases:
1. Site: 
• Size corresponds to user activity (since session information is tracked). Peak usage = peak size.
• Two-days worth of connection data is kept in the site DB, thus the largest size will be achieved two days after peak user connectivity.
• Activity is greatest during high login periods as information is frequently requested.
• An outage to this DB can cause the inability to launch sessions (session leasing not withstanding)
2. Logging: 
• Historical logging of site changes
• Sizing is not predictable as it depends on the number of changes in the site (including administrative actions in Director)
• Low I/O needs
• There is no retention policy so old data must be purged manually.
• If site policy does not allow changes to be made without the logging DB present, no site reconfiguration will be allowed. 
3. Monitoring:
• Used by Director to display data. 
• Max size is determined by retention period (7 days for non-platinum; platinum defaults to 90 and is configurable). Peak size will be when this period is reached.
• Data is collected in a manner that limits transactions, thus lowering I/O needs
• Data flushing occurs overnight. 
• An outage prevents collection of historical data
4. The TempDB:
• The SQL Temporary DB impacts the performance of SQL and the performance of XenDesktop. Usually I will configure SQL with specific drives for Data, Logs, Backups (depending on solution), and the TempDB. This allows for flexibility in regards to sizing and performance. The purpose of the TempDB is to eliminate locks on the Site DB (and others) which in a large scale environment could lead to slow performance. This DB is usually small, and a sizing guide is in the references section. 
5. Use Read-Committed Snapshot Isolation:
   • Say what? In short, this isolation improves performance, particularly during intense login periods. If you have a larger environment, users of Studio and Director will thank you.
6. Sizing:
• As much as I would love to write a novel about DB sizing - the below table from the Citrix document linked under references sums up a ballpark for your site-DB sizing needs. The other DBs are tougher to predict and should be monitored and are more variable. The Monitoring DB will likely grow the largest of all three. There are some estimates in the sizing guide on pages 6 & 7 if review is desired.
  
7. CPU Usage:
• Summary of Citrix's intensive testing of SQL performances recommends a single quad-core SQL server for XenDesktop deployments. 
8. DB Maintenance:
• Usage of DB Mirroring or Always-On features results in full transaction logging mode. This results in the transaction logs of all three DBs to continue to grow until a log backup is taken. This will cause issues without monitoring (disk space utilization, performance).
• It is recommended to back up transaction logs regularly if utilizing one of the mentioned high availability methods. This could be done with scheduled backups or with SQL Server Agent. 
• Citrix recommends Index rebuilds occur over night or on weekends. Page 13 of the Sizing Guide provides more details on scripts for this. (They actually recommend using the Windows Server Update Services script modified for XenDesktop.)

References (just so you know I didn't make all of this up).

• XenDesktop 7 Database Sizing Guide
• MS SQL TempDB Optimization
• XenDesktop & Read-Committed Snapshot Isolation
• Configuring MS SQL Jobs
• Configuring MS SQL Alerts

vCenter Appliance: LDAP Integration

Who wants to give out their root password whenever they need to have IT staff manage their VMware environment? No one. Fortunately this one is fairly straightforward. Our goal in the end will be to land on the vSphere vCenter Web Portal and be able to check the box to pass through our Windows credentials. For this sample I am going to utilize a group call VMware-FullAdmins as my security group and the domain administrator account for validation. Avoid using the AD administrator account in any production environment. Set up a delegated VMware administrators group and assign those users needing permissions.

1. Log into the vSphere console at <IP>:9443 with the administrator@vsphere.local account. You will need to use the web console. The fat client has had this option removed in latest versions. 
2. Find the Administration node. You should have Single Sign-On > Configuration available to select.
3. You will have Policies / Identity Sources / Certificates tabs. Select Identity Sources.
   
4. Click the Plus to add a source.
5. Entered the information for your domain. Keep in mind that the Alias field cannot have punctuation - is should be the shortname for your domain. Sample information below.
   Name: MyDomain.Local
   Server URL: ldap://lserver.mydomain.local:389
   Type: ActiveDirectory
   Domain: MyDomain.Local
   Alias: MyDomain
6. Now that your source is available for authentication we will want to add our VMWare-FullAdmins group for access.
7. Select vCenter Servers in the left menu column
8. On your vCenter server right-click and select All vCenter Actions>Add Permission.
9. You can now select to search MyDomain.Local for VMware-FullAdmins and add it at this level to have full administration capabilities for the environment.
10. Now just populate VMware-FullAdmins with those you need to manage your environment and you can stop handing out your built-in privileged accounts!