Blog: Networking

The order of shutdown on a multi-shelf SAN is important. This is especially so for situations where there are Vdisks that span the shelves in the SAN. There is apparently a timestamp (specifically on the MSA 2000 series) that the controller keeps current on each of the drives in the Vdisk set and these must match for the controller to bring the Vdisk online after a power cycle.

You should power off the main controller shelf first, then any secondary shelves so that the timestamps written by the controller will be consistent.

When powering on, power on the secondary shelves first and then the main controller shelf.

I came across a problem with OWA where it kept redirecting the external server address to the internal server address (Ex.  Mail.public.com -> servername.domain.dom).
 
After doing some thorough research, I discovered that there is a property in the IIS Metabase file that controls whether or not the server name is always used.  Microsoft KB article 834141 says that “The UseHostName property will instruct IIS to always replace the SERVER_NAME variable with the fully qualified machine name.”  This property is a Boolean value.  Setting this property to false stopped the automatic redirects and kept the external server name in the web browser. [more]
 
In order to edit the metabase, you must use commands with adsutil.vbs.  You must have the site ID of the website you want to edit the value for.  I show in the screen shot below how you can view the log file name in order to determine the site ID number.  I then show the commands used to get and set the UseHostName property for the website.

We had an issue come up with a group of Citrix Presentation Servers that were recently introduced as a pilot for one of our customers. All the Citrix servers are newly built using mostly application defaults. Our first application silo contained routine applications like Office, IE, and file share resources. Setup and testing went very smooth. However, the second silo we built published a core application that was launched using a batch file. Testing of the application by our network engineers and by the customer’s head of IT raised no concerns. Everything worked as expected. The application was published to a small set of regular users chosen as a pilot group and we were quickly alerted that none of the users could launch the application. Here is the error that was displayed: [more]

“The desktop you are trying to open is currently available only to administrators”

We were aware of some ongoing Terminal Server licensing issues that this customer was experiencing so we automatically assumed that was the problem. We scrambled to put another Windows 2003 server on the network to run TS licensing thinking it was only a matter of time before the other Citrix servers started having issues. By the end of the day, we had the new TS licensing server online and all the settings deployed via group policy to the problematic servers. A reboot of the servers would fix it…not so much. After the reboot, the issue persisted. Back to square one. After digging through all the settings a few times, I finally found the following setting:

On the surface this setting doesn’t look like it would cause any issues. After all, we were using a published application and it looks like this setting would only prevent users from opening a published desktop on the server. However, after doing some testing, we found that the ICA protocol doesn’t consider launching a batch file to be a published application. Only files with .exe extensions count. Our testing failed to uncover this issue because we had unintentionally done all of our testing with administrator accounts and all the applications published on the first silo were standard .exe apps. Unchecking this box fixed the problem.

While working with a client, I recently promoted a new Windows 2008 R2 virtual server to a domain controller.  Prior to running dcpromo.exe everything looked and performed great, but I noticed a large amount of system resource issues following the promotion.  I also ran into several cases of not being able to open various management console snap-ins or other applications.  After troubleshooting various issues I finally decided that they all must have had a singular root cause. 

After digging around in the event viewer and scratching my head a bit, I asked another network engineer what I was missing. He looked around for a few minutes and asked me if disk quotas had been enabled via group policy.  I opened up the Group Policy Management console on another server and discovered a disk quota group policy object for terminal servers that had been applied to the Domain Controllers OU.  After excluding the new domain controller from receiving the policy, and then manually removing the existing disk quota entries the server was running at full speed with full functionality.

After installing Windows updates a customer’s HP 6000 Desktop, running Windows 7, would not POST (Power On Self Test). After powering on it would display a HP logo and go no further. I had access to another identical system so I switched the memory, then hard drive and got the same problem both times. I decided to just put the other system in place of that original one. I connected all the cable and got the same problem on the second desktop. At that point I unplugged all but the display and power, since I have seen keyboards cause this type of problem, this time it booted without hanging. I reconnected the mouse and keyboard and it booted fine. I then reconnected the USB printer and it would not POST. I put the original system back in place, without the USB printer connected and it worked fine.

The HP 3005 printer that was connected was bought refurbished and apparently had started affecting the boot process. The decision was made to replace the defective printer so it was retired.

Cisco's IOS documentation says that pre-shared keys used for VPNs can be 128 characters long.  If you try to specify a 128 character key this message appears "Pre-shared key length exceeds 127 characters.   Key not added."  So, I have been using 127 character pre-shared keys for a long time.  Then IOS 15 came out and we are still doing VPNs just fine with that version, but not using 127 character pre-shared keys.  It still allows them but the VPN will not come up and "%CRYPTO-4-IKMP_BAD_MESSAGE" is logged, which means the keys do not match.  It now looks like the pre-shared keys cannot be longer than 125 characters.

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.

I needed a utility to export the members of a distribution group to a CSV or Excel file. After some searching I found several utilities from CTXadmtools including one that did exactly what I needed. [more]

http://ctxadmtools.musumeci.com.ar/ADGroupMembers/ADGroupMembers11.html

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.