While rebuilding WSUS (once again) I discovered another snag. When first configuring WSUS I put in “D:” for the drive to store the updates because the wizard didn’t like “D:\”. Unfortunately, both are wrong. From what I read in various posts, the wizard used to default to the largest drive with free space and append \WSUS for a directory. If you just specify “D:”, the updates try to download to D:WsusContent and not D:\WsusContent. (The eventlog shows this.)
A comment on this blog post helped fix it without a reinstall:
wsusutil movecontent D:\WsusContent D:\WsusContent\movelog2.log -skipcopy
After a reboot (and waiting, as WSUS isn’t very speedy) , the updates started downloading.
For future installs: don’t specify the just the root of a drive, specify a subdirectory like “D:\WSUS”.
PS: here’s what the log file says:
2017-04-07T21:04:23 Successfully stopped WsusService.
2017-04-07T21:04:23 Beginning content file location change to D:\WsusContent
2017-04-07T21:04:23 Did not copy files due to -skipcopy flag.
2017-04-07T21:04:23 Successfully changed WUS configuration.
2017-04-07T21:04:24 Successfully changed IIS virtual directory path.
2017-04-07T21:04:24 Successfully removed existing local content network shares.
2017-04-07T21:04:24 Successfully created local content network shares.
2017-04-07T21:04:24 Successfully changed registry value for content store directory.
2017-04-07T21:04:24 Successfully changed content file location.
2017-04-07T21:04:25 Successfully started WsusService.
2017-04-07T21:04:25 Content integrity check and repair...
2017-04-07T21:04:25 Initiated content integrity check and repair.
I had to rebuild my SUS server because the old one was still on Win2008 (x86) and I couldn’t get any of the Win10 Anniversary Edition updates.
After rebuilding the server, everything is going great. The service is installed, the updates are downloading, and I see that there are updates for the SUS server pending. So I apply them and reboot.
And the updates breaks SUS and the SUS Console giving me a constant “Reset Server Node” error.
I found this post with details to fix it. KB3159706 needs some post install steps done to unbreak SUS. (Why can’t these post install steps can’t be done automatically or with a warning?)
Summary of the fix:
- Open an elevated Command Prompt window and run: “C:\Program Files\Update Services\Tools\wsusutil.exe” postinstall /servicing
- Install HTTP Activation under .NET Framework 4.5 Features
- Restart the WSUS service.
Also, don’t forget to add the port (:8530) to the GPO:
(I haven’t configured SSL yet. It is recommended, and it does change the port to 8531.)
I had a screwy server that wouldn’t replicate a folder in DFSR because it had past the 60 day limit. I’m not sure why this server was out of date for so long.
The DFS Replication service stopped replication on the folder with the following local path: <folder>. This server has been disconnected from other partners for 152 days, which is longer than the time allowed by the MaxOfflineTimeInDays parameter (60). DFS Replication considers the data in this folder to be stale, and this server will not replicate the folder until this error is corrected.
To resume replication of this folder, use the DFS Management snap-in to remove this server from the replication group, and then add it back to the group. This causes the server to perform an initial synchronization task, which replaces the stale data with fresh data from other members of the replication group.
Error: 9061 (The replicated folder has been offline for too long.)
Replicated Folder Name: <folder>
Replicated Folder ID: A484AB0F-7DAE-4A43-BFC4-59303224FD23
Replication Group Name: domain\dfsroot\foldername
Replication Group ID: 201BA6C5-92C9-4FDF-BE2B-C9FDC6869FBD
Member ID: 9B24A868-4C07-4BBE-AE09-C0D9427C9A24
Following the suggestion in the EventID, I removed the folder completely from DFS Replication and Namespace and let everything sync back up. The event log even said that the Replication member was dropped. However, when I re-added the folder I received the same error message again.
So I changed the MaxOfflineTimeInDays option to 155 days with this command and restarted the DFSR service:
wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=155
net stop dfsr && net start dfsr
The event log showed that DFS-R started replicating the folder again and everything is back to normal again. Then I changed the MaxOfflineTimeInDays option back to it’s normal 60 days.
I think this server needs a reboot.
I’m pretty sure it hasn’t been online and traveling backwards in time since the 22nd century.
I had to migrate dhcp servers and the export/restore wasn’t working for me. I read that the export/restore method only works on the same server. I’m migrating from 2008 to 2012R2. However, there is a command-line method to add DHCP reservations in Windows and there is an easy way to get a list of existing reservations:
netsh dhcp server dump > output.txt
I could only get this command to run on the local server. Running it remotely didn’t seem to get all the output, but at least it gave me the reservations and I didn’t have to retype them. (Run these commands from an elevated command prompt.)
dhcp Server \\dhcpserver.domain.com Scope 192.168.1.0 Add reservedip 192.168.1.10 0123456789ab "host.domain.com" "" "DHCP"
Kudo to this blog post for the tips.
Bitvise has to have the best installer I have seen in a long time. Everything is on one screen: the EULA, upgrade vs. new instance, the open when finished option. Everything. None of the endless wizard crap of Next, Next, Next, Next, Next, Next, Next, Next, Next, Next, Next, Next, Accept, Install…Finish.
When writing some scripts I wanted to slip in a reboot in the middle but I didn’t know how to run stuff after the reboot. The RunOnce command seemed like a logical step and I finally was able to use it in a script that will reinstall our AV software, but I also learned a lot of caveats about it as well.
LANDESK Antivirus can be installed with two simple commands: vulscan.exe /installav and /removeav. Here is my simple script to uninstall, reboot, and reinstall LDAV:
REG ADD HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce /v InstallAV /d "\"C:\Program Files\LANDesk\LDClient\vulscan.exe\" /installav /showui" /f
"%LDMS_LOCAL_DIR%\..\vulscan.exe" /removeav /showui /noreboot
shutdown -r -t 0
Here are the things I learned:
- RunOnce doesn’t like environment variables in the key values, so this will not work:
- RunOnce doesn’t like the tricky stuff you can do in CMD. The vulscan.exe file is one directory above the LDMS_LOCAL_DIR env variable but you can’t use C:\Program Files\LANDesk\LDClient\Data\..\vulscan.exe in the registry key value.
- Using REG ADD will expand the environment variables before creating the registry key. That’s probably a CMD thing that I should have known about but I relearned it anyways.
Yeah, yeah, I know what you are going to say about upgrading Windows in place. I get it, I hate it too, but sometimes it needs to be done. I have many 2003 servers that will get an in place upgrade to 2008 and several use Netapp’s Snapdrive to connect to iSCSI LUNs. The iSCSI initiator had to be install separately in 2003 and it’s baked into 2008 out of the box, so it’s best to disconnect the iSCSI drives and uninstall the initiator from 2003 before doing the upgrade. After the upgrade, start the iSCSI service in 2008, fire up Snapdrive and connect to the LUNs. (After setting your IP to a static address. Sometimes I forget that part.)
I’ve been fighting an issue where explorer has been crashing on me when ever I’d right-click something in the Navigation pane (the left side tree view). I would right click on a folder and boom! the window would disappear. I tried to use ProcMon hoping something would stand out to me, but all I could see was a bunch of registry keys and folders with the word ‘shell’ in them before explorer.exe stopped showing up completely.
I knew it had to be an extension because this only happened on right-clicks and it didn’t happen when I first installed Windows. So I started uninstalling anything with a right-click menu option. I had uninstalled Dropbox, Virtual CloneDrive, and 7zip before I stumbled across Spybot (2.4.40). Luckily, Spybot has options to disable the shell integration without uninstalling the entire program. I turned the Windows Explorer integration options off and the problem was gone.
The other thing I found out was the 32bit shell extensions will work, but the 64bit extensions will cause the crash. Very odd as I’m running x64 Windows.
To fix the crashes:
- Check the Advanced User Mode checkbox on the main window of Spybot.
- Click Settings.
- Click the System Integration tab.
- Click the “Uninstall” button next to the 64bit shell integration option. (I have disabled all the options. I like a clean system tray.)