Proxy Settings pushed by GPO not applying to Windows 7 and Internet Explorer 9

I support a Windows 2003 Active Directory Domain, until today only Windows XP clients and Internet Explorer 8.

We use a proxy server to filter and monitor the internet and we push the configuration for that proxy server via Group Policy. Our current GPO works perfectly with Windows XP and Internet Explorer 8.

Today we got our first Windows 7 client and I noticed the proxy settings from our Windows 2003 Active Directory Domain were not applying top the Windows 7 machine running Internet Explorer 9.

It turned out there were two reasons the settings were not applying. The first is a no brainer. I hadn’t updated my Internet Explorer Group Policy Administrative Template to support Internet Explorer 9. That was easy enough to fix by going here and updating my Administrative Template.

After updating the Administrative Template I figured I’d be done. Turns out I was wrong. I ran ‘rsop.msc’ and ‘gpresult /r’ and both showed the proxy settings were being applied but Internet Explorer wasn’t using our proxy server.

Turns out there was a second problem and it was FAR more difficult to figure out. I did some research and found others complaining about this problem. Removing proxy settings for ‘GOPHER’ from their Internet Explorer GPO resolved the problem for the majority of these users. To remove GOPHER settings open up your group policy and make the following tweak:

This didn’t solve the problem for me but it may have had a hand in it.

The second thing I had to do in my case was to disable caching of auto-proxy scripts and disable changing automatic configuration settings. My understanding from the post I read was that the cache can become corrupt and cause a bunch of problems. To make this change open up your Internet Explorer GPO again and make the following changes:

Once I’d made both of those tweaks I ran a quick ‘gpupdate /force’ and that was it! Things started working properly.

There seems to be a bug in Internet Explorer 9, or at least the version I’m running, where if you go into the proxy settings under ‘Internet Options’ you won’t actually see your proxy servers name in the ‘Address:’ box. I’ll see if that clears up once I get Windows Updates working on these Windows 7 machines or when we get to Internet Explorer 10.

References

How to upgrade Gitlab 5.1 to 5.2 on CentOS 6 or RHEL6

Last modified: [last-modified]

This document assumes you’ve followed my previous post for deploying Gitlab on CentOS 6/RHEL6 and have already upgraded that deployment from 5.0 to 5.1.

If you haven’t already switched from the default version (1.7.1) of git that comes with CentOS 6 / RHEL6 to git 1.8.2.3 please follow this post first before continuing with these instructions. Even if you don’t care about that error message follow the instructions so you’re using git 1.8.2.3 instead of 1.7.1.

Now then. Lets get to it.

1. Stop gitlab and switch to sa_gitlab

 

2. Get the latest code for Gitlab and Gitlab-shell

 

3. Install libs, migrations, etc? (I stole this from the Gitlab guys)

 

4. Switch back to root and update the init script

 

5. Start up Gitlab

 

You should be good to go at this point. The first load took a while for me after the update.

 

References

Commit comments not appearing in Gitlab on CentOS

Last modified: [last-modified]

If you followed my earlier documentation, or simply installed Gitlab yourself on CentOS 6 you might run into this problem:

When you go to the ‘Files’ view of one of your repositories it won’t load any of the commit comments. It just appears to perpetually load.

If you look in your ‘production.log’ you’ll see an error like this:

It looks like this is a bug with git itself and not Gitlab.

There is a patch you can manually apply to your Gitlab deployment OR you could just upgrade git to the latest and greatest version. I chose to upgrade git. The below guide assumes you followed my original “How to install Gitlab 5.0 on CentOS 6 or RHEL6” guide. I’ve updated that guide to reflect these new steps.

1. Get logged in to your server and become ‘sa_gitlab’

 

2. Create a temp directory if you don’t have one and move into it

 

3. Download the latest source for git from https://code.google.com/p/git-core/downloads/list. As of this writing 1.8.2.3 is the latest version

 

4. Configure, compile and install git 1.8.2.3

 

5. Configure your environment so the new version of git overrides the default CentOS version

 

6. Re-export your path and verify which git is being used and it’s version

 

7. Update your gitlab.yml configuration file

 

8. Restart Gitlab

 

That’s it!

Update May 22nd, 2013 – Added step 7. Didn’t realise you had to edit the gitlab.yml file to point to the new git binary location. I assumed Gitlab used the git binary it found via PATH.

How to configure Mediawiki to authenticate against Active Directory on CentOS

Last modified: [last-modified]

This assumes you’ve got a working install of MediaWiki already and just need to tie it into Active Directory.

1. Make sure php-ldap is installed

2. Configure OpenLDAP on CentOS to ignore your domain controllers certificate validity. We all trust our own domain controllers don’t we?

3. Download and extract the latest LDAPAuthentication extension into your ‘mediawiki/extensions’ directory. I’m going to assume you’ve named the extension directory ‘ldapauthentication’ for the remainder of this documentation.

4. Edit your ‘LocalSettings.php’ found in the root of your MediaWiki directory and add the following substituting the values for your own domains information. Make sure you consistently use the same value for “<YOURDOMAINNAME>” at the start of each “array (” line.

That should be it! If it’s not working check your log files.

 

References