Blog

As part of a Citrix environment overhaul, another network engineer and I discovered a very frustrating limitation of using group policy with Citrix published applications. The problem centers around the inability to apply IE group policy settings using loopback mode processing. I'll warn you ahead of time, there are lots of details so hang with me....and remember this is all going to converge at the application of group policy. Here is what we found...

When a user with an empty roaming profile (new user) has their profile created as the result of running a published application, the user portion of the registry hive (ntuser.dat) is not created in its entirety. The users' hive can be loaded and a number of noticeable differences exist between it and the default user registry hive. If the user profile is created by logging on locally (console), via RDP to the same machine, or via Citrix published desktop on the same machine, the profile that is created is complete. I was unable to find any noticeable differences between the default user registry hive and that of the newly created roaming user profile when the profile was created in this way. Additionally, once an incomplete profile had been created via published application session, the profile could NOT be "fixed" by logging on via RDP or published desktop. Once the registry hive was created in an incomplete fashion, it seemed to be affected from then on. So why are we talking profiles...I thought this was about group policy? Well, it is...I'm getting there. [more]

We found that users running published applications did not have group policy correctly applied. We were trying to set policies on Internet Explorer using Internet Control Panel settings in the user portion of the GPO. Specifically, IE security zone settings such as trusted and intranet sites would not apply. We also noticed that each security zone seemed to be locked. In the Security tab of the Internet Options dialog box, all the icons were the same....blue IE symbol with a lock next to it. The "Sites" button and the "Custom Level" button were also grayed out. So, here is the where the profile problem merges with the group policy problem. I found that by manually exporting certain keys from the default user profile registry hive under \Software\Microsoft\Windows\CurrentVersion\Internet Settings\ and importing them into in a incomplete user registry hive, I could fix the problem. That is, once the keys existed in the user registry hive that pertained to the settings I was trying to set via group policy, the policy was applied correctly...no issues. Makes sense right....if the group policy is setting registry keys in order to apply certain policies, it’s not going to work if the keys don't exist in the first place.

So things have come full circle. Group policy isn't working because the user profile is messed up. So why is the user profile not getting created correctly? Well, this is actually a Microsoft problem --> http://support.microsoft.com/kb/899270. And the script they provide doesn’t work…we tried it. Actually, there is more to the problem than that, but here is a summary of the information that we gathered. By design, Citrix published applications, remote applications in Windows 2008, and the "start this application on connection" functionality of RDP (mstsc.exe) running against Windows 2003 servers implement limited logon functionality so that the session footprint is smaller than a normal desktop session. Part of the "limited functionality" is that the user session does not start explorer.exe. So, any application that depends wholly or in part on explorer.exe could have issues. Some of the important pieces of functionality that explorer.exe implements are the following:

  1. The run registry entry
  2. The RunOne registry entry
  3. Startup applications 

If you have ever noticed the small gray box that is displayed the first time you log on as a new user, you have seen the effects of explorer.exe running at session logon. It goes by fast, but it says something like "applying internet explorer customizations", "setting up windows media player..."...stuff like that. That little box is normally initiated by explorer.exe. It is called runonce.exe. What we found was that if we initiated runonce.exe in a logon script, the user was created correctly when running published application; thus, group policy was applied correctly as well. Testing also showed that this process could also fix a previously created broken user registry hive (ntuser.dat). All we had to do is add the following to our logon.bat file

start /MIN %windir%\system32\runonce.exe /AlternateShellStartup

Citrix has documented this problem in a support article (http://support.citrix.com/article/CTX104374) and they refer back to the previous MS KB listed above. Numerous forums threads exist on this issue and we were unable to find a resolution elsewhere that did not include scripting registry imports to the user profile at logon. This workaround seems to be a more flexible and reliable.


 

If you’d like to delete a “block” of text such as spacing at the beginning of several rows of text, use the Ctrl+Shift+F8 key combination.

Place your cursor at the beginning of the first line, press Ctrl+Shift+F8 [more]

Use the right arrow key to highlight the area you wish to delete on the first row, then the down arrow to highlight the same area on the additional lines.

Presto, change-o…the unwanted text (or spaces) are gone!

Line 1
Line 2
Line 3
Line 4
Line 5

This is admittedly not as cool, but I accomplish the same thing in Notepad (assuming the block of “text” I want to delete on each line is identical) by using Ctrl+H (Replace), entering the “text” (or spaces) I wish to delete, leaving the “Replace with” field blank and clicking Replace All.


 

When installing or making changes to the Symantec Endpoint Protection client, be aware that the SEP firewall policy can cause Windows Firewall to 'reset' or change its configuration.  I've seen several versions of Windows OS change to an active firewall config with no exceptions under the following 2 conditions: [more]

  • SEP client with an enabled, default firewall policy is installed for the first time
  • Existing SEP client has its applied firewall policy withdrawn

This has been seen with several 11.0.6x builds of SEP, although it may be applicable to other builds as well.  This occurs even though the SEP firewall module (Network Threat Protection) is not installed.  When a Windows desktop has its firewall enabled with no exceptions and there is no group-policy in place to re-apply a previous config, it may become unreachable remotely via any protocol, while at the same time the user may notice no change and continue working normally.  If the Windows client happens to be a server, all connectivity to that server may be lost, except via console.

I suggest rolling out new SEP clients after the firewall policy in that group has already been withdrawn.  For existing clients where the firewall policy needs to be withdrawn or disabled (ie overriding Win7 firewall config), test a small subset of clients in a separate group before making the change to normal production groups.


 

I recently ran into a problem with Windows 7 UAC where we had a VBS file that was calling the application SETACL.  In order for SETACL to run properly, it must be “Run as Administrator”.  I could set the option in SETACL to “Run as Administrator” in the applications properties, but when the script called the application, UAC would not prompt the user to elevate privileges.

I wanted to see about right clicking the VBS file to select the “Run as Administrator” option, but Windows does not include that option in the context menu by default.

In order to add the option, you can add it to the registry.  Copy the following into a .reg file and then merge the file into the registry: [more]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\VBSFile\Shell\runas\Command]
@=hex(2):22,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
  00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,57,00,\
  53,00,63,00,72,00,69,00,70,00,74,00,2e,00,65,00,78,00,65,00,22,00,20,00,22,\
  00,25,00,31,00,22,00,20,00,25,00,2a,00,00,00

After merging the key, I was able to select “Run as Administrator” when right clicking the VBS file and the call to SETACL also ran correctly. It's a good idea bo backup your registry before making manual changes.


 
 

A couple months ago, I had a user who was having problems with the RSA SecurID App on the iphone.  For some reason, his PIN was not hidden after he typed it in.  I found out there is a small “i” in the bottom right hand corner of the app, and if you open it up, there is a little slide-bar that you can move to hide/unhide the PIN.


 

I was tasked with upgrading a 2003 Windows Server to 2008 over the weekend recently and ran into a few minor issues trying to get the upgrade started. The main one was that the Server 2008 installer would not continue past the compatibility check as long as Windows PowerShell 1.0 was installed. PowerShell 1.0 was released as a hotfix prior to server 2003 SP2 and was included in the SP2 package. When I went into Add/Remove Programs, I didn’t see the PowerShell update in the list. Even after removing SP2, PowerShell was still present on the server and would not allow the Server 2008 upgrade to even start. [more]

I wanted to try manually uninstalling the hotfix from the $NtUninstallKBXXXXXX$ folders located in C:\Windows, but the folder that housed the PowerShell 1.0 hotfix info was nowhere to be found. Most likely, someone had removed those folders to clean up disk space or they were removed with the installation of SP2. In either case, I was stuck.

Fortunately, we had another Server 2003 32bit machine running out on the network that still had the $NtUninstallKBXXXXXX$ folder that I needed. I copied it over to this original box and tried the uninstaller. It successfully uninstalled PowerShell without any extra registration on my part! After this was removed, the upgrade to Server 2008 ran smoothly.


 

This approach is certainly not for everyone, but here is what I have done to mitigate the problem with so many certificate authorities out there.  The Comodo breach of March 2011, for example, allowed some bad guys to use a registration authority to generate valid certificates for Google, Yahoo, Skype, etc.  There are companies that sell boxes with software that will generate a valid certificates on the fly for every secure web site you visit in order to be able to observe your traffic.  With so many CAs, the risk of misuse has increased.  These comments mainly apply to Windows.

I think it was during May 2010, I edited the trust level on the root CA certificates in Firefox to only trust about 10 of them.  I think I have had to trust maybe two more since then.  I started with the list at http://netsekure.org/2010/05/results-after-30-days-of-almost-no-trusted-cas.  There are several links on this page that explain a lot about how Windows handles certificates.  This is one of the major reasons I use Firefox instead of IE.

To change the trust level of certificates in Firefox, go to Options, select the Encryption tab, and then the View Certificates button.  This brings up the Certificate Manger window.  The Authorities tab in the Certificate Manage window is where all the CAs are listed. Select each certificate and then select the Edit Trust button at the bottom.  This is where you can disable trusting each CA’s certificate. [more]

I also run the Firefox Addon Certificate Patrol which saves every certificate and warns me if a certificate has changed.  The primary blogger with the Tor Project, phobos (I don’t know the real name), suggests being your own certificate authority in a manual sort of way and not trusting any external certificate authorities (https://blog.torproject.org/blog/life-without-ca). I decided not to go that far.

If you prefer another browser such as Google Chrome or Internet Explorer, the procedure will be different.   Chrome and IE use the Windows certificate store, so you will have to delete the certificates that you do not want to trust.  Opera has it’s own store, but operates like Windows, downloading additional root certificates behind your back.  You may be able to preload these and remove the trust, but I have not taken the time to look into this.  I know nothing about how Safari handles certificates.

As I mentioned at the begining of the article, this approach is not for everyone.  However, for technical users with a little patience you can greatly reduce the likelihood you'll fall susceptible to a spoofed SSL certificate.


 

I had applied Windows updates to a customer’s Windows 2008 R2 server that had Microsoft Threat Management Gateway installed, and I could not RDP to the server after rebooting.  I connected to the server locally and could tell from netstat that the server was not listening at all on port 3389.

It turns out that there was a problem with the RDP-tcp protocol not working because it was configured to listen on all available network adapters.  This being a proxy server, it had internal and dmz network adapters.  To fix this issue, set the RDP-tcp protocol to only bind to the internal network adapter. [more]

  • Open Remote Desktop Session Host Configuration.
  • Open th/e properties of the RDP-Tcp protocol underneath Connections.
  • In the Network Adapter tab, change the setting from “All network adapters configured with this protocol” to the specified internal network adapter and hit apply.
  • On the Actions bar to the right, click Disable Connection and then Enable Connection to reset it.
  • Run netstat to confirm that the server is listening on port 3389 again.

 

While configuring a new Windows 7 laptop I attempted to setup a new VPN connection.  It kept defaulting to a dial-up connection. I verified the steps I was taking on my own Windows 7 laptop and then repeated it again, but it had the same results. I tried copying the VPN connection to the system and it still would try to use dial up. I tried setting up the VPN using the local administrator account, domain administrator account, and domain user account only to find the same results each time.  I even disabled and uninstalled the modem and it still default to dial up.

After some research, I opened the device manager, enabled the “Show hidden devices” option, and under “Non-Plug and Play Drivers” I found NDProxy with a yellow exclamation mark. [more]

NDProxy, according to Microsoft is "a system-provided driver that interfaces NDISWAN and CoNDIS WAN drivers (WAN miniport drivers, call managers, and miniport call managers) to the TAPI services" - see http://msdn.microsoft.com/en-us/library/ff568322.aspx for more details.  NDProxy has been linked to slow boot, BSOD and other issues in Vista.

To fix the problem right click on NDProxy and select properties, go to the second tab (Driver) and look at the “Current Status” section, it says it is “Stopped”. Choose the option to start it then reboot. (Do not change the startup type) After the reboot NDProxy will no longer have an exclamation icon (i.e. it started OK) and it shows “Started” in the “Current Status”.