After sorting through the data that I obtained from the collection script, removing duplicates, etc. The result set was slightly messier than I expected, quite a few manually added entries and incorrect ones.
Anyway, to get the bulk of the changes implemented, I’m just targeting the large expected set – those with VPN settings labelled SITE1 PPTP and SITE1 VPN (anonymised…). Those with SITE2 PPTP have the settings, that were previously enforced by another script, have them enforced here too. This script will take the place of the existing one.
New machines, who do not have the settings already have them defined. Anyway here it is:
So, now we have gone full circle! There is now a need to remove the proxy settings from one of those VPN connections described in the last post.
For the machines that are supported within my group, the settings should be consistent, but there is the possibility that extra settings have been added by the user. So, I did a little discovery first:
The resultant file shows mostly what I’m expecting to see, with a few other things like Vodafone dongles, user defined connections etc.
Removal can be easily carried out by trimming the setting script (from the last post) to no longer publish the one to be removed, then use a GPP item to remove the key relating to the VPN proxy settings, to be removed.
For those other groups, within the organisation, who do not have such consistency; the results of the script can be analysed in Excel to see what is “out there”. Then another (not yet written script – because I don’t think I’ll need it) can be used to find those binary values which match those that are to be removed and then subsequently remove them.
A number of years ago, I rationalised the way that IE proxy settings were delivered to supported systems. Previously, this had been done via installation scripts, which were not enforced after application, so were prone to subsequent error.
To achieve consistency and ease of deployment Group Policy was used. Back then there were Internet Explorer Maintenance GPO settings, which allowed the LAN Proxy setting to be deployed easily. However, I also wanted to make consistent the delivery of VPN settings. This was also achieved by using Group Policy to deliver a VPN address book (rasphone.pbk) to the clients.
In order to get the correct proxy settings assigned to those VPN connections, I used a little scripting.
First, find out on my test machine what the text in the IE proxy GUI translated to, where I had already setup the VPN connections and set the correct proxy settings:
Then use the results of that to create a new vbs script to be pushed out as a User login script:
Here is the script used to migrate the clients from the old servers to the new domain based DFS namespace, note that from_srv and to_srv need to be amended and the case statement needs to be constructed based on the content of the Drive Mapping script output.
A long time before planning a file server migration, I thought that it would be interesting to see which drives were mapped by our users.
We do not use a login script or GPO Preferences to do this and there is a long history of “Stuff” on the old servers.
Initially, it was down to help the helpdesk staff to re-map drives on new machines; where the user didn’t know where the target was – it was just their J drive….
Coming back to the file server migration, the historical data in this file was invaluable.
By comparing the drive mapping data with the shares defined on the target server, a list of share names and their long path was produced. This list is then used to construct the case statement within the server migration/ re-mapping script.
I’ll publish the drive-mapping script here now, as it was easy to sanitise. I’ll provide the re-mapping and rollback scripts separately.
Note that this script must be run as a Logon script in the user part of a GPO. Additionally, the target folder is a very open hidden share.
Interactive logon: Message title for users attempting to log on
Interactive logon: Message text for users attempting to log on
However, these settings provide no layout options whatsoever. To try to force some semblance of a layout, you need to introduce a character (we used *) at the beginning of each line then add spaces to get an indent. Adding carriage returns in the GPO has no effect! You could just plop the text in as one long line…. Either way it looks crap!
We also have some display screens scattered about that auto-logon. These machines has to be excluded from getting the legal notice, otherwise they would not auto-logon. The initial solution was to just create another OU for these machines to exclude them from receiving the policy settings. This is simple but messy, you forget to put them (pre-staged) in the right place before they are added to the domain, so you then need to trawl through the registry removing the settings….
I was looking for an alternative and found this article on the scripting guys website:
I used this as the basis for the script below. My version is applied at the root of the domain as a computer start-up script in a “Base” GPO. This way every client gets the legal text (except DC’s – the script is also applied to the DC’s separately).
Those auto-logon machines are handled automatically. A security group in the domain contains the computer accounts for those machines that you don’t want to get the legal text. If the computer account is in that group, the script ensures that the legal text is not set, if the machine already has the legal text and is then added to the group, the legal text is removed automagically!