Category Archives: Windows Networking

Items related to Windows based networking.

DFSR Cleanup Script

I am a big fan of using DFSR to replicate various types of data.

One example is to use it to replicate my Windows Deployment Service (WDS) Images to other sites. (There are some caveats to it but that is another post.)

Now and then my replication seems to be broken. Most often it is due to lack of space as indicated when you run a health report or check eventvwr.

Often, this is due to large files in the DFSRprivate folder. DFS uses various stages in it’s replication. Files now and then seem to get stuck or orphaned for whatever reason.

I have had to do a forced copy of my main imaging site to correct the issue. Usually a copy fails until I can free up some space.

Going through the folders is a lengthy process.  I created a script that will do it for me. My sample script is designed for WDS on D: but it easy to modify.

As with any of my scripts, please be sure you understand what you are using it for.

<start of dfsrclean.bat>

net stop dfs
net stop dfsr


cd “\RemoteInstall\DFSRPrivate”

REM create list of folders

dir /b /ad > dfslist.txt
for /F %%A IN (D:\RemoteInstall\DFSRPrivate\dfslist.txt) DO (

echo %%A
net share dfstemp=”D:\RemoteInstall\DFSRPrivate\%%A” /grant:Everyone,Full

rmdir \\localhost\dfstemp /s /q

Rem mkdir PreExisting in case removed
mkdir “D:\RemoteInstall\DFSRPrivate\%%A\PreExisting”

net share dfstemp /delete /y


REM cleanup dfslist.txt
del /q “D:\RemoteInstall\DFSRPrivate\dfslist.txt”
net start dfs
net start dfsr


<end of dfsrclean.bat>

You can download it here: dfsrclean (rename to .bat)

Printer installation hanging

(Correction as of October 3, 2014, real source of the problem)

I ran into an issue installing a printer queue from a domain server.  Installation  was hanging and nothing I did would help.   I even tried a Microsoft fixit and that stayed hung up overnight.  I have seen a few different solutions posted but not the one I came up with.

To paint the picture in my case, it was a laptop trying to connect to a printer queue on what used to be a standalone server. The person in question was getting prompted for credentials when we connected to the server unc path.

The credentials displayed were based on his old account he used to have locally on that server. Everyone else connecting to the server now that it was on the domain weren’t prompted.

I looked around to see how to get rid of the cached credentials. No luck in any of the places that were supposed to store the information.

In the end I opted to try to replace his credentials.

I opened a command prompt and did


(This is did not work in my case, below you will see whyyou must include /PERSISTENT:YES at the end or you will be re-prompted after a logoff or reboot)

net use \\servername /user:domain\probuser <had him type his password and enter> /PERSISTENT:YES

at that point, browsing to the server worked flawlessly and connecting to the printer queue was done in seconds.

Other cases like this may not be as odd bit I would curious to see someone try to enforce the credentials in this way. It all makes sense now that I understand security was hanging up even the ms fix.

Last correction to this and maybe I should just remove the post.. :/

My problem ended up being an entry in credential manager, though I still think the above command may have some value. Just not as much as I originally thought.



How to block Ultrasurf at the workstation level in Windows

Some time ago, I discovered students were using a program called Ultrasurf to get around our internet filter.  The app is portable and so can run off a USB key or from a cloud drive. (As of writing this, the latest file name is u1403.exe. You can recognize it is running by a yellow gold lock icon on the screen and usually in the lower right corner)

Apparently it was designed for citizens of China to get around “The great firewall of China.”  The app sets itself up as a proxy.  Ultrasurf then changes Internet Explorer to use this new proxy to surf. Behind the scenes the app works by connecting to an IP overseas from a wide-range of choices. From what I saw, it connects using https and the port can be varied by users. Blocking it is a daunting task.

Blocking the app itself via group policy is tough as well. The checksum is a moving target.   Ultrasurf often has a new version out plus old versions can be found everywhere.

You might think that blocking proxy access in IE via GPO would help. It really doesn’t. All the GPO does it block being able to put in the settings via Internet Options.  Policies still allow changing the actual proxy value in the registry.

What I discovered is that to block Ultrasurf, you need to prevent the users from being able to edit HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings.

This is where IE stores it’s proxy information. As long as the user has write access, Ultrasurf can work.

Introducing UltraFin!

I have created a script that works at the user level. I deploy it via a policy that will run as the user for anyone who is a member of our student user group.  I called it UltraFin as a play on UltraSurf. A surfers day is ruined if they see a Fin in the water 🙂

What the script does is use a tool called regini.exe to set the part of the registry I mentioned above as read-only. This essentially locks them out from making any changes to their proxy settings. To undo the permissions settings, an admin would have to mount their profile hive (ntuser.dat) and correct the permissions.

Once this is done, launching Ultrasurf says it is connected but will go nowhere. Ultrasurf normally launches IE once it connects but this won’t happen anymore.

I keep both my script and regini.exe in the netlogon folder of our DC’s.

You get regini.exe as part of the  Windows Server 2003 Resource Kit Tools.

Here is my script and please note, you will need to rename it from ultrafin.txt to ultrafin.vbs

In the GPO I create, here is where I place it:

User Configuration->Policies->Windows Settings->Scripts->Logon


I use the logonserver variable to reduce network traffic and to prevent a workstation from hanging up on logon if X server is down.

One important note, I still keep a policy in place for this group that prevents them from changing their proxy settings in IE.  The main reason for this is so my users in question can’t manually set a different browser to use the Ultrasurf proxy address. Ultrasurf thrives on IE but there is the potential to workaround it.

To ensure this, I also have imported policy templates for the other popular browsers such as Chrome and Firefox. I enable settings to force these browsers to use IE proxy settings.

I hope this helps someone as I haven’t found many good ways so far on how to block Ultrasurf.

WDS – Adding nic drivers to a boot.wim (in the right index!)

I have spent way too much time on this and wanted to save others the trouble.

I needed to add drivers for a new system into my boot.wim file for PXE booting a system so it could get a WDS image deployed to it.

To add drivers to the file, you can do a more manual process by using the DISM command in a command prompt.

I am normally a command prompt guy but in this case I’m happy to use a GUI tool for it called DISM GUI.

For starters I made a backup copy of my boot.wim  just in case.  Mine was stored here: D:\RemoteInstall\Boot\x86\Images\boot.wim.

Don’t keep your backups in that folder as they will show up as a boot option. I put it in the root of RemoteInstall.

Calling it something like boot_backup.wim will suffice. Never touch this until you are sure!  From there I made a copy of that one and called it boot.wim but kept it in that location. I did that for later when I replaced my previous boot.wim.

Back to inserting the drivers… I did the usual process of mounting boot.wim under my selected mount point.  When you do this, the default index is 1 (keep this in mind!). The 2nd tab allows you to specify your nic driver folder. I always leave recurse checked and also force unsigned. You just click Add drivers and let it work. When done, on the first tab, click dismount and give it time. You can then exit.

At that point you have to right click your boot image in WDS and select Replace. Pick your new image. When done, click finish and restart your WDS service. (If you don’t do this, when you PXE boot you will see duplicate options.)

In showing you all this, there is a step I haved learned you need to check before you make your changes.

WIM files can actually contain more than one image and each has an index number.  You need to confirm you are adding drivers to the right index number.

You can find out with a command prompt with this command:

dism /get-wiminfo /wimfile:”d:\remoteinstall\boot_backup.wim”
The output will look like this:

Deployment Image Servicing and Management tool

Version: 6.1.7600.16385

Details for image : d:\remoteinstall\boot_backup.wim
Index : 1
Name : Microsoft Windows PE (x86)
Description : Microsoft Windows PE (x86)
Size : 807,716,855 bytes

Index : 2
Name : Install an Image
Description : Install an Image
Size : 6,634,542,951 bytes

The operation completed successfully.

In my case, the one I want to work with is actually #2. I spent a lot of time adding drivers to #1 and not understanding why my PXE boot kept complaining it couldn’t access the network. This is the error I kept getting:

“WdsClient: An error occured while starting networking: a matching network…..”

It simply means the image doesn’t have a valid driver for the nic. I find the standard one for the OS from the manufacture (in this case Dell), works fine.

In case anyone noticed, I am doing this with a 32-bit boot image (x86). The reason is grandfathered in as I started using WDS for imaging when some systems only supported 32-bit. I used to keep a 64-bit Install(boot).wim in my PXE list but noticed that I could stil install 64-bit images by booting with the 32-bit boot image. At that point, I removed the 64-bit option from my list to clean it up and avoid confusion.

Remove network printer queue by batch script

For some reason, group policy preferences isn’t removing some old printer queues from user machines for me. (I converted over to using simple queue names compared to the previous method where the queue name contained the printer model. It makes them shorter for staff and really eases management. Now when  a printer is replaced, I change the driver. That’s it. No queue name to change. No policy to update.)

I searched around and didn’t find much on how to force remove a queue so I made my own.

This method is for removing queues stored in the user profile. You can find the ones you have listed in HKEY_CURRENT_USER\Printers\Connections

Click on the queue key in this location and export to quickly be able to copy the long name
ie HKEY_CURRENT_USER\Printers\Connections\,,SERVERNAME,Basement_Copier

Please note that the  HKEY_CURRENT_USER converts to HKCU in the script

The script will look for the queue name and remove from the registry. To make it disappear in Devices and Printers, the spooler needs to restart. I test the output of the reg delete to make sure we don’t restart the spooler for nothing.

@Echo off

reg delete HKCU\Printers\Connections\,,SERVERNAME,QUEUENAME /f > Nul

REM if entry NOT found in regedit, skip over spooler restart

REM restart spooler to remove device from Devices and Printers
net stop spooler && net start spooler