I just today I tried to connect to my work network from home using the Cisco AnyConnect client, for reference I’m using AnyConnect 3.1.05182 on Windows 8.1, and was unable to. I was immediately presented with an error before even being asked for a username and password, which said something was wrong with the client, as it hadn’t really had time to start any proper negotiations with the ASA.
A little bit of Googling revealed that the problem might have come from a recent Microsoft update, dated just a few days ago. I had noticed my machine downloading a few updates of late, and I’m nowhere near as diligent with testing updates on my personal machine as I should be, or as I am on any work related systems.
It turns out that this is indeed a bug with the latest set of Microsoft patches, and Cisco confirmed this here.
While Cisco have said ultimately the fix has to come from Microsoft, there is a workaround until a permanent fix is produced;
Close the AnyConnect client from the system tray
Navigate to the AnyConnect client install location, for example “C:\Program Files (x86)\Cisco\Cisco AnyConnect Secure Mobility Client\”
Right click on the vpnui.exe and click troubleshoot compatability
Pick “Try recommended settings”
Click “Test Program” and this will reopen the AnyConnect client
Repeat the same process again, but for vpnagent.exe
On the final test when the AnyConnect client opens again, you then find that you’re able to connect normally again. If you have Cisco support it would probably be valuable opening a TAC case and mentioning case number #115021112390273. This bug does also affect Windows 7 when IE11 is installed, and the same fix should work there too.
When you’re creating a set of Group Policy preferences, you can set all kinds of settings in a very similar way to how you would if you were sat in front of the machine. For example, IE settings are very intuitively laid out and it really is just like doing it within the internet control panel screen;
The key thing to remember though, is that in a lot of cases, just setting the preference isn’t enough, you have to enable it too. So for example, entering a homepage into the preferences panel will not make it actually apply, as you can see the lines underneath it stay broken red, which means that the setting will not get applied;
Although it’s not mentioned within the policy at all, there are keys you can press to enable or disable individual settings, or the entire page, and these are documented on Technet.
Basically, to enable the homepage setting we saw above, after you’ve finished entering it, press F6 and this will turn the line under the settings to green and this means that then this will get applied;
So from this you can enable or disable any setting from within the policy, and hopefully take a little more control over your Internet Explorer settings going forwards.
I came across a server today that had some horrible problem with the .NET frameworks on it, and none of the updates or service packs from Windows update would install. I couldn’t remove any of the .NET applications using either the App/Remove Programs GUI, or via the correct msiexec install strings. I’m not sure how the server came to be like this, but it was a problem I had to sort out and basically I was a little stumped, until I came across Aaron Stebner’s MSDN blog. He had a post about completely removing the .NET applications in their entirety.
The application works on all versions of .NET and you can find it on his blog here
Once you’ve run the cleanup tool, reboot and then you can just install the applications from Windows Update again. The application worked very well and once it was finished, all was well in the .NET world.
Previously the common and accepted way to add a policy template into a new group policy was to do it from within the policy itself, that would be done by right clicking on Administrative Templates and then adding it from there, picking the correct template you were wanting to add, as below;
Though in a domain environment, you really should be looking at doing this centrally by creating a central policy store. Doing this has a few advantages, such as all the policy template files being replicated round all servers either via FRS or DFSR, and only having one place to go to update or add templates, making future management simpler. Microsoft have all the details, but it’s a fairly simple process;
Create the root folder for the central store %systemroot%\sysvol\domain\policies\PolicyDefinitions on your domain controller.
Create a subfolder of %systemroot%\sysvol\domain\policies\PolicyDefinitions for each language your Group Policy administrators will use.
Note: Each subfolder is named after the appropriate ISO-style Language name, for example, to create a subfolder for U.S. English, create the subfolder: %systemroot%\sysvol\domain\policies\PolicyDefinitions\EN-US
This should make your life a little easier when it comes to managing policy templates.
So, you’re managing a Windows estate and you’re in the process of updating Internet Explorer versions that you’ve managed via Group Policy. At some point you’re going to have multiple versions of Internet Explorer out in the wild and need to manage the settings for them both. As you should know by now, Internet Explorer maintenance settings have been deprecated in favour of Group Policy preferences.
The first thing to note is that even if you download the Group Policy templates for IE11 and install them correctly, you wont see an option for IE11, just IE10 and earlier.
Not to worry though, IE10 settings will apply just fine to IE11 and that is the desired behaviour. So, now you know how to configure settings for IE11, you might wonder how preferences for different versions of IE in the same policy would interact on the client machine. Well in the setup I looked at this had previously been done using item level targeting, which is in the common tab of the policy;
The targeting was looking into the registry and checking for specific version strings which would only have the policy apply where the registry strings matched what was being checked;
Now, while the above method would work it’s unnecessary. When you create a new setting within the policy, you’ll see some Item-level targeting is already put in place by Microsoft to ensure the settings only get applied to the right version IE on the client. The version of the IExplore.exe process running on the client machine is checked and then that is used to determine which IE settings to deploy from the GPO. So in my environment, as you can see below the settings would only apply to specific IE versions;
The XML file already contains all it needs to look for specific versions of IE, and as a result the various policies can co-exist with each other.
In short, the item level targeting is done for you, no need to add any more targeting unless you need to filter things down further.
I came across a problem today with a rather aged Server 2003 R2 server. I rebooted it as part of some troubleshooting, and after the reboot found I was unable to connect to the server via RDP. So, I jumped on the VM console to check various things, the Terminal Services service was started, but I did force a stop of this and start it again. Checked over the registry to ensure the listening port hadn’t been changed for any reason. Checked the terminal services configuration to ensure the connection wasn’t disabled and there were no strange limits imposed on the connection, but all looked normal. I did try disabling and re-enabling the connection, but still no luck. When I did a netstat -ao and looked for anything listening on 3389, there was nothing at all listening, no Terminal Services or any conflicting service was listening on port 3389.
In the end, after a bit of a search on Google and a bit of checking, one suggestion mentioned was to re-register the Terminal Services DLL. So using the following command regsvr32 remotepg.dll I tried this and the registration failed. Tried to un-register it first with regsvr32 /u remotepg.dll but again this failed. So, I came to the conclusion there might be a problem with the DLL. So, I copied the DLL from another working machine, un-registered and re-registered the DLL again, which succeeded this time round. Then after a reboot, I was hopeful, but still no joy. Final, checking the Terminal Services configuration again I noticed that now the connection was disabled, right clicking and going to All Tasks and enabling the connection, I was then able to connect via RDP. Success
After switching to lighttpd away from Apache I was pretty pleased with the whole process, everything seemed to be working fine, with the exception of my permalink structure. Bad news, until I came across this posting on Tenable Tech Tips.
Basically, once mod_rewrite is enabled on the lighttpd server, which is done by adding the following line to the lighttpd.conf file;
server.modules += ("mod_rewrite")
Use the following re-write rule, which covers off permalinks and exclusions for other static files. the final code to insert should look like the below, with the obvious changes for your host;
I found today I needed to check my SMS message centre settings on my OnePlus One, but wasn’t able to find the option anywhere in the standard settings.
The solution was to use the dialer, enter *#*#4636#*#* and then this takes you through to a testing information screen with various information menus. Under the “Phone Info” menu, down the bottom of the page, you should see the SMS Message Centre options, labeled “SMSC”. From here you can update the settings and refresh them if you ever have any issues sending SMS messages. Obviously the specific number to enter will depend on your mobile operator.
I didn’t even know this setting existed as an option within Group Policy, but then again, Group Policy is a bit of a beast at the best of times.
So, the PDC emulator is responsible in the domain for handling password replication to other domain controllers, a password change occurs on the PDC and this is then replicated out to all other domian controllers. But what if you have a large infrastructure and the password change hasn’t replicated out yet to the domain controller being used by a client to authenticate? Well there’s a policy setting you can apply to your domain controllers, that forces them to check with the PDC in the event they deny a logon request due to a bad password. The setting is called “Contact PDC on logon failure” and it is briefly detailed on TechNet, and within the Group Policy editor, lives at the below location;
I had never noticed this problem when using Windows 7, but since upgrading to Windows 8 I’d seen frequent caching problems from a Windows Server 2008 R2 share. Both mapped drives and UNC paths showed the same out of date cached information, which seemed different to a lot of reports I’d read online that seemed to centre around mapped drives having the problem but not UNC paths. On my server offline files were disabled and the share was set to never be available offline on the server. A reboot provided a temporary workaround, but I needed a more permanent solution.
So after some investigation I started to get the idea that this might be related to caching when SMBv2 was negotiated and used between the client and server. After some further investigation I came across an article on TechNet which pointed to disabling the cache settings within SMBv2 on the client machine.
So adding three DWords to the registry and setting them to 0;