Since I maintain and administer lot of Windows and Exchange Servers, running basic disk checks and defrag on the servers manually is simply impossible. To achieve the goal, I had a small batch file written which automates this task for me.

To start with, create a folder on the machine that you want to automate this on. I named my folder as “MaintenanceScripts”. The next step was to write the batch file with the content given below and save it as “ChecknDefrag.bat”.

@Echo Off
REM ***************************************************************************
REM *                                                                         *
REM *      AUTOMATED DISK CHECK AND DEFRAGMENTATION SCRIPT                    *
REM *                                                                         *
REM ***************************************************************************

REM chkdsk and defrag automation
REM Read the Drive Letter from the file
for /F "eol= tokens=1 delims=( " %%i in (DriveLetter.txt) do set DrvLtr=%%i& call :dsKchk

:dsKchk
If %DrvLtr% == end goto :eof
echo. >> diskcheck.rtf
echo. >> diskcheck.rtf
echo ******************************************************** >> diskcheck.rtf
echo CHECK DATE and TIME for %DrvLtr% >> diskcheck.rtf
date /t >> diskcheck.rtf
time /t >> diskcheck.rtf
echo ******************************************************** >> diskcheck.rtf
echo. >> diskcheck.rtf
echo. >> diskcheck.rtf
echo RUNNING DISK CHECK ON %DrvLtr% ....
chkdsk %DrvLtr% >> diskcheck.rtf
goto :defrag

:defrag
echo. >> defrag.rtf
echo. >> defrag.rtf
echo ******************************************************** >> defrag.rtf
echo CHECK DATE and TIME for %DrvLtr% >> defrag.rtf
date /t >> defrag.rtf
time /t >> defrag.rtf
echo ******************************************************** >> defrag.rtf
echo. >> defrag.rtf
echo. >> defrag.rtf
echo RUNNING DISK DEFRAGMENTATION ON %DrvLtr% ....
defrag %DrvLtr% -b >> defrag.rtf
defrag %DrvLtr% -f >> defrag.rtf

:EOF

The above batch file checks for a file called “DriveLetter.txt” in the same folder from where the script it going to run from. You can change it to your liking. It also saves the report of the disk check to a file called “diskcheck.rtf” and for defrag to a file called “defrag.rtf”. I choose RTF so that I can open it in MS Word or any other application to see a nice formatted output.

Next, we create a file called “DriveLetter.txt” in the same folder where we saved the Batch File and add all the drive letters that we want the script to check:

C:
end

You can add more disks to the above file by writing the drive letters to the text file – one drive per line.

Run the batch file once and wait for it to finish. Once it finishes its run, you can open the RTF files and see the results. If you are satisfied that everything is working fine with the batch files, you can now move towards scheduling the batch file to run at off-peak hours.

I’ve come across many postings on forums where admins are talking about being hit by DDOS attacks and the servers going down. I’ve been replying to those threads, but I think its time for me to discuss it at length here.

Basically, DDOS means a Distributed Denial of Service attack which are targeted towards a computer, server or a device to make it unavailable on the network. Lot of malicious traffic is directed towards a server or a service which blocks the bandwidth/network. Here are some steps Windows administrators can go through to prevent or fight against it:

- Keep your servers/computers updated with the latest patches, service packs and updates.
- Harden the TCP/IP stack. Here is an article from Microsoft which talk about it: http://support.microsoft.com/default.aspx/kb/324270
- Check with your Data Center to find out what infrastructure security is in place. They may be having a system in place where the DDoS traffic can be routed through a DDoS Mitigation Service. This filters out the attack traffic and allows the legitimate traffic to continue to its original destination.
- If the budget permits, get a good hardware firewall installed in your infrastructure network. If not, then you can also go in for some software based firewall which can filter packets. In the worst case, at least have your Windows Basic Firewall configured.

Start by creating a directory into which you will extract the downloaded PHP files. In this example I’m going to use C:\PHP as my installation directory. Then extract the files from the zip into C:\PHP. Please check the PHP website for latest PHP release.

If you need to use the additional PECL modules then extract the files from the PECL Zip into the C:\PHP\ext directory.

Next locate the file ‘php.ini-recommended’ in C:\PHP and rename it to ‘php.ini’ (without the quotes of course)
 
Open the ‘php.ini’ file and find the line which reads extension_dir = “./” and change it to extension_dir = “C:\PHP\ext”. This tells PHP where the various extensions are located. If you open the default PHP.INI file which ships with the ZIP file you can see that the default path in the ‘php.ini-recommended’ file points to the wrong location, so you need to change it.

You also need to add the location of your PHP directory to the server’s PATH environment variable so that Windows knows where to look for any PHP related executables (such as the PHP extension DLL‘s). To do this Right-click on My Computer, click Properties and on the Advanced tab click Environment Variables. In the Environment Variables dialog box, under System Variables highlight the Path variable and click Edit.

Add ‘;C:\PHP’ (be sure to include the semi-colon separator) as shown here and click OK. You will need to re-boot the server for this change to take effect as system variables are loaded when the server starts up.

If you browse through the ‘php.ini’ file you will see an entry describing the ‘cgi.force_redirect’ property. You will also see a statement telling you that if you are using IIS you ‘MUST’ turn this off. However, this only applies if you are using the CGI version of PHP (i.e. php-cgi.exe) Since we are using the ISAPI version of PHP we can safely ignore this.

Configuring IIS (Only if required)

There are a few simple steps you need to take in order to get PHP working under IIS 6.0

First we need to create and then enable an appropriate Web Service Extension so that IIS will both recognize and allow PHP files to be processed by the appropriate script engine.

You can use the Internet Information Services (IIS) Manager GUI method to perform this task but there is a much quicker way of doing this; namely using the ‘iisext.vbs’ Command-Line Administration Script, which you will find in C:\Windows\system32 by default.

Assuming you are using the same directory structure as I am in this walkthrough you can simply copy and paste the following line of text and execute it at a command prompt from C:\Windows\system32 :

cscript iisext.vbs /AddFile c:\PHP\php5isapi.dll 1 PHPISAPI 1 “PHP ISAPI”

As you can see, this script creates a new Web Service Extension named “PHP ISAPI” with a status of Allowed.
 

The IIS 6.0 Command-Line Administration Scripts are very powerful and flexible tools and I would recommend using them wherever possible.

OK, now we are ready to test our PHP installation. Start by creating a simple PHP test file. Open Notepad on the server and copy the following line into a new text file: <?php phpinfo(); ?>

Save the file as index.php in the root of the test web site. Next create a new default document type of index.php on the test web site (this step is optional but it just makes browsing a bit easier)

Browse the site and you should see the standard PHP configuration details page

However, if you look carefully at the above page you will notice it is indicating that my ‘php.ini’ file is actually located in ‘C:\WINDOWS’ even though there is no such file in my C:\WINDOWS directory. This is because the ‘php5isapi.dll’ file is actually compiled with this location as its default value. A number of existing PHP and IIS tutorials suggest that you should copy the ‘php.ini’ file to the C:\WINDOWS directory – but what if you don’t want to do that?

Well, you don’t have to because PHP allows you to actually configure a custom value for the ‘php.ini’ file location. There are a number of ways to do this but perhaps the simplest is to configure the PHPRC environment variable.

To demonstrate how this works I am going to create a new folder called ‘C:\inifile’ and instruct PHP to read its configuration data from the ‘php.ini’ file in this location (in practice you may prefer to leave your ‘php.ini’ file in the C:\PHP directory)

In order to do this I need to create a new System environment variable named ‘PHPRC’ and provide the appropriate values. Right-click on My Computer, click Properties and on the Advanced tab click Environment Variables.

In the Environment Variables dialog box, under System Variables click New. In the New System Variable dialog box type PHPRC for the variable name and then enter the desired path to your ‘php.ini’ file’s location.

Then click OK and you will see that a new System environment variable has been created. In order for this to take effect you need to re-boot the server at this stage.

#Note
As an alternative, you can edit the registry and specify the location of your configuration file. The main benefit of the registry edit method is that it doesn’t require a re-boot – in testing this method I found that any changes made would take effect once the application pool serving the web site was recycled. However, choose whichever method you feel most comfortable with and which fits your requirements.

Now if we browse the site we can see that PHP is indeed looking for its ‘php.ini’ file in the ‘C:\inifile’ location which I specified previously.

And that’s it. You should now have a working installation of PHP running on IIS 6.0.

I’m not much of a Linux guy but still love Nagios. Few days back I came across a script on Nagios Exchange (http://www.nagiosexchange.org/cgi-bin/page.cgi?g=Detailed%2F2639.html;d=1 ) which does a check for Windows updates and reports the results back to the Nagios server. The moment I saw it, I was very happy and I wanted to set this up. But the happiness did not last for long. Few hours later I found that it was not going to be easy to set this up and get it running. The problem is not the script – the problem is me. Always had been away from the Red Devil and Penguin since Windows always was my passion.define service{
use generic-service
host_name Name Of Host – replace this with your Host Name
service_description Updates
check_command check_nrpe!check_updates!-l
}

Searched a lot on the Internet and forums but I could not find a single site which would show how to implement the script in NsClient ++ and how to define the command and service in Nagios. Finally, I managed to crack it and now I would like to share this with everyone who may need some help on this.

Follow these steps to get this working:

[1] Download the script from Nagios Exchange and store it on your hard disk of your server which you need to check for updates. Note down the path to the wsf script for further reference.

[2] Edit your NSC.INI file (NsClient ++) and add this line to it:
check_updates=c:windowssystem32cscript.exe //NoLogo //T:40 C:Scriptscheckupdates.wsf $arg1$
The line above will check for the checkupdates.wsf script under the Scripts folder and run it using cscript. The $arg1$ will return the value back to Nagios.

[3] Next step is to add a command to your Nagios command.cfg file:
#’check_nrpe’ command definition
define command {
command_name check_nrpe
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -p 5666 -c $ARG1$ -a $ARG2$
}

[4] Now it’s time to define the service. Depending on the way you use templates, I’ll leave it up to you to decide where to place it. Add the following lines:
# Monitor updates in windows machine

Do a pre-flight check of Nagios. If no configuration errors are reported then you are good to go. Restart nagios for the new checks to work.