The Japan Page

Halloween 2006 Report (Better late than never!)

My goal this year was to buy 5 giant bags of candy and scare away enough of the bigger kids to make that last all night. Our neighborhood is a van drop off destination for trick-or-treaters and more than half of them are old enough to drive, so why not?

First up this year, I added a small networked IP video camera to the front corner of the garage out of sight and set it up to trigger a loud godzilla roar in the garage. Coming up the driveway would trigger the camera and play the mp3 in a loop, surprisingly it scared some of the older grade school kids away. The others would walk around and trigger it repeatedly and couldn't figure out where it came from.

Next up, just around the corner I placed the new concussive air canon hidden behind a tombstone. This is a 60 PSI air chamber hooked up to a standard 1" sprinkler head and powered by a small air compressor. When the older kids walked by a small pushbutton inside the house set off a very loud blast of harmless air. I didn't want to automate this one as we don't want to ruin Halloween for the little kids.

If that didn't scare them, then on final approach to the door was a small wooden pumpkin. This has a standard (yard security) motion sensor in test mode, hooked up to power a strobe and speakers of a MP3 screeching sound playing in a loop.

Finally, there's the Scary Pumpkin I put on the front of the house for Halloween. It's a leftover piece of 5/8 " ACX from the bathroom remodel with some spray paint. I put some foam 3/4" pipe insulation on the bottom edge to prevent head injuries, and while not easily visible in the picture it's hinged and opens out.

We then sat back in the living room and watched the video coming off the IP camera on the TV and waiting for trick-or-treaters to arrive. We can a great time, the trick-or-treaters had a good time and no little children were scared. We ended up with 2 giant bags left over, aww shucks. My co-workers thanked me though. :-)

Can't wait for October, this year will have to include something new...

Posted by John Seaman at 11:14 PM | Permalink | Comments (0)

This is a backup script for Microsoft MSCS Exchange Clusters running Network Appliance SnapManager for Exchange. If you don't use this environment, hit the back button because we're about to turn up the geek speak.

We deployed 5 two node MSCS clusters running Exchange 2003 using iSCSI to a Network Appliance FAS 960c cluster. Using SnapManager for Exchange, the active node runs a backup which creates a snapshot of the DB state on the front end filer. Our backup strategy is to push this snapshot to a back end NearStore device (an R200) running less expensive SATA drives. This allows for a recovery from (or on) the R200 in the unlikely event the roof fell on the front end filer cluster. The snapshot on the R200 is further dumped to a NDMP tape silo and those tapes are stored in an underground ICBM bunker somewhere.

This also serves to offload the backup processing load from the front end filers and provides a high level of redundancy.

The only gotcha in the whole backup process was a method to schedule the backups on the Exchange servers. SME is a great tool, but doesn't include cluster state awareness or a built in scheduling engine. That's where this script comes in.

This script also contains logic from my MSCS cluster health status script and will alert if cluster resources are not online.

Requirements:

• MSCS Exchange clusters. You can schedule SME backups easily under Scheduled Tasks on non-clustered Exchange servers, so this script doesn't do much for non-clustered installs.
• NetApp storage. This script doesn't distinguish between iSCSI and fiber.
• SnapManager for Exchange. This script was written against a running SME 3.1P1 environment and may require minor changes for other versions.
• Bmail or another smtp command line mailer utility.
• Environmental variables for %clustername% (the MSCS cluster name) and %exchangeVirtualName% (the Exchange virtual server name). Without these variables the script won't run as they're too hard to extract from the cluster tools available in DOS. Set them in Control Panel, System, Advanced, Environmental Variables on every node.
• Assumes your quorum drive is drive letter "Q".
• Requires the MS Resource Kit utility SC.exe (more info here).
• Requires uptime.exe from the MS Resource Kit.
• Assumes your SnapManager (SnapBackup.exe) is installed under C:\Program Files\SnapManager. Change your backup requirements settings around line 260.
  

Deployment:

Schedule the script to run on each physical node of your cluster with a Scheduled Task. I run Node A at 2100 hours and Node B at 2105 hours. One of the two nodes will hold the Exchange resource and run the backup, the other will find no Exchange resources and bail out. Both scripts write a log file for debug and tracking purposes, and generate SMTP alerts to major cluster issues. Have fun !

To do:

• Add further logic to view the post backup log file and detect a backup failure.
• Convert to a VBS script or executable. Batch is so oldskool.

Download the script here.

Note: This script is a sample and would require extensive customization to your specific environment and naming standards. It works like a charm and I've had it in production for nearly 2 years without issues. It catches the occasional cluster issue and alerts when there are problems. Like all script samples provided on this site, this is for your information only and the author assumes absolutely no liability for it's use. Be very careful !

Trademarks are property of original trademark owners.

Posted by John Seaman at 8:58 PM | Permalink | Comments (0)

We recently identified a bug in a widely deployed application and needed to get a count of how many installs mights be subject to issues. Normally I would just walk over to the SMS console and run a report, but sadly our SMS remains less-than-completely-deployed at the moment, and I need a (reasonably) quick answer.

So, here's a batch file to do the job....

Step 1 - Query AD and find all Windows XP workstations

@echo off
::REM ------------------- Begin sample batch script ------------------------
::REM Sample batch programming script
::REM (C)2006 John D. Seaman, Copylefted under terms of the GNU/GPL
::REM by John D. Seaman, www.japan-page.net/batch

::REM Change the LDAP
::REM operatingSystem: Windows XP Professional;

::REM Set the base DN
set _baseDN="DC=mydomain,DC=com"

::REM Run a LDAP Query against AD for the OS version you need to find
adfind -b %_baseDN% -f "(operatingSystem=Windows XP Professional)" >out.txt

::REM Extract the machine names
type out.txt | find "cn:" >out2.txt

::REM Optional batch script step - strip the leading "cn: " from the output file with texttools32
::REM Use your favorite batch text editor or do this in notepad later

::REM Strip the "cn: " from the front
type out2.txt | t repl '^>cn: ' '' >out3.txt

:EOF

Once again we use the excellent utility adfind.exe from joeware.net.

Step 2 - Check the target workstations and get the version info

Run a batch script in a loop and query the file in question on the target system. To save time the script will ping the workstation once and if it's offline mark it and skip it.

Gotcha's:

• You have to have sufficient rights on the client workstations.
• You need to know what file and where to find it. This script assumes everything exists in a single location.
• You can do further logic on the versions as needed, this example just divides machines into unreachable, no application found and output if found.
• Output if found is into a file _hostname.out.txt .
• You will have to customize the paths and application names in this example.
• As always, use this and any sample script with the utmost caution. This is provided for educational purposes only.

Take the output of Step 1 above, make sure the "cn: " has been removed and rename the file to machines.txt

@echo off
::REM ------------------- Begin sample batch script ------------------------
::REM Sample batch programming script
::REM (C)2006 John D. Seaman, Copylefted under terms of the GNU/GPL
::REM by John D. Seaman, www.japan-page.net/batch
echo.
echo.

::REM Cleanup old files
if exist _offline-hosts.txt del /q _offline-hosts.txt
if exist _eas-not-found-hosts.txt del /q _eas-not-found-hosts.txt

::REM Set up a loop, process each entry (workstation)
for /f %%i in (machines.txt) do call :queryPC %%i

echo.
echo Done.
pause
goto :EOF

::REM ------------------- F U N C T I O N S -----------------------

::REM Query individual PC and get the info we need...
:queryPC

echo.
echo Now checking PC %1...

::REM Ping the sucker once and make sure it's up...
ping %1 -n 1 >_pingout.txt
type _pingout.txt | find "Request timed out.">nul
goto :result%errorlevel%

:result0
echo Host %1 not pingable, skipping...
echo Host %1 offline >>_offline-hosts.txt
goto :EOF

:result1
echo Host %1 reachable, verifying EAS client install...
if exist \\%1\c$\progra~1\MyApplication\myClient.exe (
echo myClient.exe found...
echo Performing Version check...
filever \\%1\c$\progra~1\MyApplication\myClient.exe >_%1.out.txt
goto :EOF
)

echo MyClient not found in default location on host %1
echo %1 MyClient not found in default location on host %1 >>_application-not-found-hosts.txt

goto :EOF

:EOF

Filever.exe is available in the Windows XP Service Pack 2 Support Tools kit.

Posted by John Seaman at 11:16 AM | Permalink | Comments (0)

If you don't use Zantaz EAS, hit the back button now... this is going to get boring quickly !

When using Zantaz EAS (Exchange Archive System) you have to create an index and eventually split it off when the index fills up. I split the Index membership from a DL maintained automagically by Imanami SmartDL to contain all active Exchange users. Since DL membership is dynamic over time (even without SmartDL), when you split the Index by DL you will invariably leave active users on that index.

This isn't a major problem, but you will need to continue updating your split indexes, you will see a nightly indexed count and the index will continue to grow a little. One way to reduce this problem is to find any users left on a split (retired) index and remove them manually. The following SQL query will help you find active users. Change the usi.search_index_id = x field to the index ID you've split and this will spit out the remaining active users.

select usi.userid, usrs.username
from user_search_index usi, users usrs
where
usi.search_index_id = 2
and usi.copynum = 1
AND usi.userid = usrs.userid

Shoutout to my buddy Ray Mays and EAS Support for this one.

Posted by John Seaman at 10:03 AM | Permalink | Comments (0)

Here's a couple of quick and dirty tests for Zantaz EAS to verify the back end servers are up and running... cut and paste the following into Internet Exploder (IE).

Verify the IIS server can reach the SQL database server.
http:// eas-server/EAS_App/easweb.dll?dbtest

Verify the IIS server can reach the SQL database server.
http:// eas-server/EAS_App/easweb.dll?fstest

Verify current authentication... (this is really kind of cool, it will give you your current credentials, SID, and the group name and SID of every group you're in.
http:// eas-server/EAS_App/easwebsearch.dll?authenticate

Confirm search DLL version
http:// eas-server/EAS_App/easwebsearch.dll?status

Posted by John Seaman at 3:33 PM | Permalink | Comments (0)

Boredom with wood and tools can be dangerous...

Here's a custom hardwood case I built for my MultiPlex MiniMag RC Airplane.

Posted by John Seaman at 8:28 PM | Permalink | Comments (0)

If you're not an Exchange administrator, skip this one.

I finished up a 1200 user Exchange 2003 to 2003 migration on Jan 31. After catching up on sleep for a few days it was time to turn off the source Exchange servers. Post shutdown, I ran through the eventlog looking for problems and found the MSExchangeTransport Event ID 3005. This is indicative of a mail loop, which can have many root causes. In this case, the loop was for a secondary SMTP domain, brought from the source Exchange server. Once the source servers were offline, checking the "This Exchange Organization is responsible for all mail delivery to this address" button on the e.mail address under the Recipient Policy fixed the problem.

It's a no-brainer of course, but there was a window of an hour between turning off and retiring the old source Exchange system and when I updated RUS. The messages looping caused the SMTP Q's to build up on a few servers which triggered the Q alarms. Below are the pre-fix and post-fix NDR's when sending a test message to a non-existent user, and the eventlog capture of the NDR. Messages to valid users continued routing normally, so only e.mail to invalid users resulted in the loop.

The following recipient(s) could not be reached:

nul.user@myotherdomain.com on 2/3/2007 9:52 PM

A configuration error in the e-mail system caused the message to bounce between two servers or to be forwarded between two recipients. Contact your administrator.

<exchange.server.mydomain.com #4.4.6>

The NDR you do want (undeliverable):

The following recipient(s) could not be reached:

'null.user@myotherdomain.com' on 2/7/2007 10:05 PM

The e-mail account does not exist at the organization this message was sent to. Check the e-mail address, or contact the recipient directly to find out the correct address.

<exchange.server.mydomain.com #5.1.1>

Full Text of the Error message:

Event Type: Error
Event Source: MSExchangeTransport
Event Category: NDR
Event ID: 3005
Date: 2/3/2007
Time: 9:52:04 PM
User: N/A
Computer: MyExchangeServer
Description:
A non-delivery report with a status code of 4.4.6 was generated for recipient rfc822;null.user@myotherdomain.com (Message-ID ).
Cause: The maximum hop count was exceeded for this message. This non-delivery report can also be caused if a looping condition exists between sending and receiving servers that are not in the same Exchange organization. In this situation, the message bounces back and forth until the hop count is exceeded. A configuration error in the e-mail system can also cause the message to bounce between two servers or to be forwarded between two recipients.
Solution: The maximum hop count is a property set on each virtual server and you can manually override it. The default maximum hop count is 15. Also, check for any situations that might cause loops between servers.

Posted by John Seaman at 10:06 AM | Permalink | Comments (0)