Ever sat in a train station, cafe, or airport, and seen “Free Public Wifi”? It’s a well known fact that my personal motto is “there’s nothing better than free things”, sadly in this case your not going to get what you were expecting 🙁
Solution
There’s nothing particularly sinister about it, it’s caused by a bug that was in Windows XP. This particular bug was fixed with service pack 3, but not everyone has installed service pack 3.
The more technically astute of you will see on some of the screen shots above, that this network is NOT an access point it’s an “Ad Hoc” network, this basically means you’re going to connect to to another computer. The whole thing started because when Windows XP could not connect to its favourite/stored wireless sites/connections, it sets up an “Ad Hoc” network with the name of the last network it connected to. The “Free Public Wifi” network spread like wildfire as machines were all connecting to each other on wireless connections that were not what they was purporting to be. It seems that (like me) everybody likes free stuff.
The same problem can occur with machines advertising popular access point names like linksys, netgear, default, tmobile, hpsetup etc as well.
Learn the difference between “Infrastructure Networks” and “Ad Hoc Networks”
Related Articles, References, Credits, or External Links
I’ve briefly mentioned this before when I wrote about Group Policy Preferences so when I had to do this on-site this week, I jumped straight into the group policy management console, and found that because my ODBC connection was using SQL authentication (with the SQL sa account), this would NOT WORK, (it only works with Windows authentication and even then it needs a tweak). If you are using SQL authentication jump down to the bottom of the article.
Solution
NOTE: Below I’m dealing with user DSNODBC connections, so I’m looking at User Policies, if you want to send out Machine DSNODBC connections then you need to be looking at Computer Policies.
Deploy ODBC Settings via Group Policy Preferences (Windows Authentication)
The GPP is pretty easy to locate you will find it in;
[box]
User Configuration > Preferences > Control Panel Settings > Data Sources
OR
Computer Configuration > Preferences > Control Panel Settings > Data Sources
[/box]
However you will find there is a bug in the system which means it does not deploy.
ODBC Settings fail to Deploy via GPO
1. Locate the ODBC connection that you are trying to deploy > right click > Copy.
2. Right click your desktop and ‘paste’ > You will get an XML file > Open it with notepad > Delete the username and the cpassword information > Save the file.
3. Then delete the original ODBC file from your group policy.
4. Drag the XML file into the policy, in its place > Select ‘Yes’ to import it.
WARNING: Do not open its settings/properties from this point forward, or it will break again.
Getting ODBC Settings from a Clients Registry
1. You may wish to locate and extract the ODBC settings from a working client, you can locate the settings in a working client machines registry and simply export them so you can import them on a target machine, or deploy them via GPP or logon script.
[box]
User DSN's
Computer>HKEY_CURRENT_USER>Software>ODBC>ODBC.INI
Machine DSN's
Computer>HKEY_LOCAL_MACHINE>Software>ODBC>ODBC.INI
[/box]
2. Simply right click the key that corresponds to the ‘name’ of the ODBC connector that you wish to export, > right click > Export > Save.
Deploy ODBC Settings via Group Policy Preferences (SQL Authentication)
In this example I’ve merged the ODBC connection details into the registry, you could just as easily set them up manually, as long as they exist, either on the machine you are creating the policy on, or another machine you have ‘remote registry’ rights to.
I was creating some “Bookmarks” on a client’s AnyConnect web portal last week. They were simply CIFS links to shared folders on his servers so he could access them remotely from his Android tablet PC’s.
However every time I clicked a link I got this error;
Solution
A bit of searching later and I found that in the release notes for version 8.0(4) this was a known problem that had been fixed (Bug CSCsl94183).
A quick check on the ASA in question, revealed it was still on 8.0(3). Note: From command line issue a “show version” command to check the version level.
I upgraded to version 8.2(2) to be on the safe side (This firewall was a 5505 Security Plus, and did not have enough memory to go beyond version 8.2 see here for details). Post upgrade everything worked as it should.
Related Articles, References, Credits, or External Links
