I needed to adjust the scope of a built-in firewall rule in a couple of servers, restricting the remote IPs to a list of UVM subnets in CIDR notation. The netsh documentation describes the syntax for a list as comma-separated values (no spaces). But I kept getting errors with the command:
netsh advfirewall firewall set rule name="Windows Internet Naming Service (WINS) (NB-Name-UDP-In)" remoteip="10.10.0.0/16,10.11.0.0/16,10.12.0.0/16"
Finally, I actually read the error message:
For ‘set’ commands, the ‘new’ keyword must be present and must not be the last argument provided.
And the related part of the usage text:
Values after the new keyword are updated in the rule.Â If there areÂ no values, or keyword new is missing, no changes are made.
One little three-letter keyword was all I needed:
netsh advfirewall firewall set rule name="Windows Internet Naming Service (WINS) (NB-Name-UDP-In)" newÂ remoteip="10.100.0.0/16,10.101.0.0/16,10.102.0.0/16"
We use EMC NetWorker for our enterprise backup solution. Since we migrated our primary file server from a NetApp filer to a native Windows server, weâ€™ve been having a recurring problem with all the Shadow Copies for a volume getting deleted. There are strong indications that the problem is related to the NetWorker backups.
As we have been working on this issue with EMC (since the first week in January!), I wrote a script to tell me two things each morning; how many snapshots exist for each volume, and what VSS errors were logged, if any.
I thought someone might find it useful, so Iâ€™ve posted it as a separate page (the script doesnâ€™t fit nicely in the column on the blog).
PowerShell Script: chksnap.ps1
I spent a some time configuring the Eventlog-to-Syslog service on my domain controllers, yesterday. A bunch of that time was spent trying to figure out why the service wasnâ€™t able to read the config file I had created.
The upshot is that I had installed a 32-bit version of my text editor of choice. When I created the config file in c:\windows\System32 using 32-bit Vim, the WoW64 file system redirector on Server 2008 R2 was transparently relocating that file to c:\windows\SysWOW64. Then, when I tried to start the service, it failed to find or load the config file because it didnâ€™t exist in the correct location.
So, I have replaced the standard gvim install with the native 64-bit version.
After seven years of providing robust file service hosted on a NetApp filer, weâ€™ve decided to migrate our services to native Windows File Services. We have encountered several issues with the interaction of newer Windows client operating systems and NetAppâ€™s third-party implementation of CIFS and SMB2.
We did meet with some staff from various units on campus to discuss the current state of file services, especially the current pain points, and outlined our current plans. The main themes that emerged from our discussion were as follows:
- Make the service simpler
- H: drive is just confusing; merge it with My Documents
- The duplicated folders within user profile directory (e.g. c:\users\netid) create lots of confusion. Any way to address this?
- Provide more options (increments) for home directory quotas
- Provide notification to departments regarding storage usage and quotas
We are currently prototyping a new design for our Campus File Services â€” dare I call it CFSv2 â€” hosted in a Windows Server 2008 R2 Failover Cluster. Itâ€™s still early in the process, but the design look promising.
We use BIND for our DNS, and allow certain systems to perform dynamic DNS registration. This arrangement has worked well for years. When I started deploying Server 2008 R2, I noticed that they werenâ€™t registering PTR records.
At the same time, I noticed a bunch of errors that seemed to indicate that Dynamic DNS wasnâ€™t working at all. It turns out this is a false error, due to the differently formatted, but still correct, success message returned by the BIND DNS. (see KB977158 for details)
After spending lots of time doing packet captures (thanks for your help, Sam!), I opened an issue with Microsoft. After collecting a few traces to analyze, they determined that the same differently formatted success message was responsible.
I installed the KB977158 hotfix, and now my Server 2008 R2 hosts are successfully registering their PTR records.