Script to perform update and synchronisation of DHCP Mac Filter List for Microsoft DHCP Server releases prior to 2008 R2

System Requirements:

  • Windows Server 2008 (R1)
  • Microsoft DHCP Server
  • Microsoft Mac Level Filter extension

The Problem:

If you are using a Microsoft DHCP Server release prior to Windows Server 2008 R2, Mac Address filtering (either allow or deny based) is not included as part of the main console. Microsoft made the feature available as an extension DLL for Microsoft DHCP during Windows Server 2008 (R1)’s early production run.

If you have installed this extension, filtering is restricted to a single server, with no replication options available to peer servers through clustering. This article offers a simple script that can be used to suspend and update a peer server’s Mac Filter list in a master/slave relationship.

The Fix

The script assumes that you have enabled file sharing through your firewall between the servers and that the MAC address filter configuration file is located at c:\windows\system32\dhcp\MACList.txt.

The format of MACList.txt is

#MACList.txt
MAC_ACTION={DENY}
#List of MAC Addresses to deny
001BB04EB711 - # -mypc6 - 192.168.1.28
002BBB831711 - # -mypc7 - 192.168.1.96

Batch script:

@echo off
set TARGET=<hostname/IP of slave server/peer>
cls echo.echo Opening Notepad
echo.
echo Make changes to the file, save and exit. The changes will be
echo replicated to %TARGET% automatically.
echo.
echo Note: This will interrupt DHCP Services for a few seconds on both servers.echo. c:\Windows\system32\notepad.exe "C:\Windows\System32\dhcp\MACList.txt"

:: Stopping DHCP Server Service on Local System
echo.
echo Applying Changes to Local DHCP Service
net.exe stop DHCPServer
echo.

echo Stopping DHCP Server Service on %TARGET%
:: Restart DHCP Server on Target
sc.exe \\%TARGET% stop "DHCPServer"

ping 127.0.0.1 > null echo.

echo Copying MAC List to %TARGET%
copy /y "C:\Windows\System32\dhcp\MACList.txt" "\\%TARGET%\C$\Windows\System32\dhcp\MACList.txt"

:: Starting DHCP Server Service on Local System
net.exe start DHCPServer

:: Starting DHCP Server Service on %TARGET%
sc.exe \\%TARGET% start "DHCPServer"

echo Operation completed. Please periodically check to ensure sync is stable.

In short, the script:

  1. Offers you a notepad session to make any needed changes
  2. When notepad closes it will restart the local servers DHCP service (thus applying the changes locally)
  3. Shutdown the peer servers DHCP service
  4. Copy the updated MAC filter list
  5. Restart the peer servers DHCP service
  6. Terminate

To add a level of safety, the following script can be run periodically to ensure that the DHCP service is in fact running

@echo off
sc interrogate DHCPServer 2>NUL | find /I /N "4 RUNNING">NUL
if "%ERRORLEVEL%"=="0" (
  echo DHCP Service is running
) else (
  echo DHCP Service is not running!!!!!
  net start DHCPServer
)

Performing WUSU 3.0 database maintenance (database re-indexing) via WsusDBMaintenance under Windows Server 2008

System Requirements:

  • Windows Software Update Services 3.0
  • Windows Server 2008, 2008 R2

The Problem:

Microsoft recommend that you perform monthly maintenance on your WSUS database to keep it in good order. The following pages represent the instruction for undertaking this activity

This document simply seeks to clarify the process when using Windows Internal Database (instead of SQL Server) under Windows Server 2008/R2.

The Fix

The following summarises the steps involved in the process.

  1. Install the SQL Server Native Client for your processor on the WSUS server
  2. Install the SQLCmd utility for your processor on the WSUS server
  3. Copy & Paste the T-SQL code from Re-index the WSUS 3.0 Database into a notepad file and save it on c:\ as WsusDBMaintenance.sql (or download here)

If you wish to automate or schedule the task:

  1. Create a .cmd file on your desktop
  2. Enter the following into it
"c:\Program Files\Microsoft SQL Server\90\Tools\Binn\sqlcmd.exe" -I -i"c:\WsusDbMaintenance.sql" -S "np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query"
  1. Note that the version of the SQL Server SQLCmd that you install will need to be reflected in the version number (90 above). 90 = SQL Server 2005, 100 = SQL Server 2008 and so on.
  2. Right click the .cmd file and select “Run as Administrator” to launch it through an elevated command prompt
  3. If you setup a scheduled task for this, remember to set the always run with full permissions option.

If you just want to run it once:

  1. Open an elevated command prompt
  2. Enter the command:
"c:\Program Files\Microsoft SQL Server\90\Tools\Binn\sqlcmd.exe" -I -i"c:\WsusDbMaintenance.sql" -S "np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query"
  1. Note that the version of the SQL Server SQLCmd that you install will need to be reflected in the version number (90 above). 90 = SQL Server 2005, 100 = SQL Server 2008 and so on.

PEAR for PHP Error “No releases available for package “xxx” install failed” after running ‘pear install xxx’ on Windows Server 2008

System Requirements:

  • Windows Vista
  • Windows 7
  • Windows Server 2008, 2008 R2

The Problem:

You know that something a bit odd is going on when one of a batch of servers starts throwing errors that the others sailed past. In this case trying to configure PEAR for a new PHP install with Mail, Mail_Mime and Net_SMTP (pear.php.net/mail, pear.php.net/mail_mime and pear.php.net/net_smtp) should be fairly standard. The other servers took the install and even this server too Mail and Mail_Mime but would not accept Net_SMTP returning:

C:\Program Files (x86)\PHP>pear install net_smtp
No releases available for package “pear.php.net/net_smtp”
install failed

Leaving it overnight before rolling up my sleeves (in case it was just downtime at the package repository) the fix was fairly simple.

The Fix

If you are experiencing the same problem this server was having, running the following

pear remote-list

Will result in

SECURITY ERROR: Will not write to C:\Users\<user[8.3]>\AppData\Local\Temp\pear\cache\e9b88593398eb79a9aa91024351d646arest.cacheid as it is symlinked to C:\Users\<user>\AppData\Local\Temp\pear\cache\e9b88593398eb79a9aa91024351d646arest.cacheid – Possible symlink attack

If you get something akin to the above simply browse to:

C:\Users\<user>\AppData\Local\Temp\

and delete the pear folder

Error 0x80070005 when using SWbemLocator.ConnectServer to initiate a WMI session despite using the correct username and password

System Requirements:

  • WMI 1.5 or higher
  • Windows 95, 98, 98SE, Millennium
  • Windows NT 4.0, 2000, XP, 2003, Vista, 2008, 7

The Problem:

When using WMI’s SWbemLocator.ConnectServer class to log onto a remote system, you receive an 0x80070005 access denied error (Decimal -2147024891).

This error occurs even though the username and password are correct and the account credentials are synchronised properly between the local and remote machine – either by domain or manually in a workgroup.

More Info

The classfull connection line for using SWbemLocator is:

Set objWMIService = objSWbemLocator.ConnectServer(<computerName>, <wmiDefaultClassPath>, <username>, <password>)

for example:

Set objWMIService = objSWbemLocator.ConnectServer("192.168.0.100", "root\cimv2", "Administrator", "12345abcde")

The Fix

There is a very good chance that the problem you are having is to do with the username you are entering. You need to ensure that you are prefixing the username with the logon domain.

For example if your domain is camie.local your username should be camie\Administrator

Set objWMIService = objSWbemLocator.ConnectServer("192.168.0.100", "root\cimv2", "camie\Administrator", "12345abcde")

But I’m using a workgroup!

Don’t worry, you can do one of three things.

  1. Prefix the remote machine name (the local logon domain)
  2. Prefix the workgroup
  3. Send a null logon domain
Set objWMIService = objSWbemLocator.ConnectServer("192.168.0.100", "root\cimv2", "myHostName\Administrator", "12345abcde")

Set objWMIService = objSWbemLocator.ConnectServer("192.168.0.100", "root\cimv2", "workgroup\Administrator", "12345abcde")

Set objWMIService = objSWbemLocator.ConnectServer("192.168.0.100", "root\cimv2", "\Administrator", "12345abcde")

Using one of the above, you should be able to connect to the remote workstation. If you are dealing with a mix of workgroups or cannot know the hostname in advance I suggest using \<username> with I have tested to work on Windows 95 right through to Windows 7.