This article first appeared at the now-closed Win32Scripting site. Since I find it useful, and my bookmark no longer works, I have been unable to reach its author, Jeff Trumbull, so I hope he doesn't mind that I've archived it.

Author: Jeff Trumbull

Description:
Backup files that make a Microsoft virtual server with only about 1 minute of down time. Suspends the virtual server, takes a shadow copy , starts the virtual server then copies virtual server files. This could be used to copy any open files. Requires vshadow.exe from vss sdk.

Script:

Long story short, you can't... at least not thru the interface. Instead, you need to totally blow out your configuration and reconfigure the server.

However, it's not as bad as it seems - there's not so much to configure that it should be too big of a hassle.

If you have console access, close your databases, and make note of your settings.

• Stop the Filemaker Service.
• Assuming a default installation, go to c:\program files\filemaker\filemaker server\admin\conf and delete the 4 XML files in there.
• Restart the Filemaker Service
• Reconnect to the Filemaker Console

It'll re-walk you thru the wizard to set up the server, and the first thing you do is set up a username and password. Your databases (again, assuming a default installation) will already be there, ready to go...

Got a call from a client today who was unable to get his laptop to connect to his wireless network.

The client has a standard Linksys WRT54G which is sitting behind a WatchGuard SOHO router.  (The WatchGuard predated my involvement with the client, and we determined it was easier to use the WRT54G as an access point rather than ripping out the WatchGuard...)

Upon inspection, the laptop WAS connecting to the wireless network, it just didn't have internet access.  Vista would show it had Internet connectivity, but it would then just go away.

Upgraded the WRT54g's firmware, same result.  Changed from WEP to WPA-2. Same result.

Reviewed the logs on the WatchGuard and saw "User count exceeded. Packet dropped."

A-HA!

The WatchGuard, unlike most consumer routers, has a user limit to it.  It keeps track of 10 IPs and when IP number 11 hits the routing table, it gets whacked with a big ole' DENY rule.

When I plugged the laptop into the WRT54g via ethernet cable, the IP address was one of the 10 in the routing table and packets were allowed to flow.  The IP address assigned to the wireless interface was not in the table and therefore blocked.

We couldn't figure out why the laptop stopped working.  The client mentioned the laptop stopped working when we put a new computer on the floor.  We did a quick count of all devices on the network and only came up with 7...

Just as I was leaving, one of the warehouse guys came in holding his iPhone asking "Did something happen to the wireless network?"

Of course, something had -- I hadn't changed the Linksys back to WEP after the WPA-2 experiment, and he lost his connection... and the mystery of the additional devices was solved.

So, the moral is two-fold -- look for user licensing restrictions where you least expect them, and someone else's handheld device from home sitting on your network might have a negative impact on your ability to get work done.

Just a quick heads up, but Spam Assassin (which we use for filtering here at Jephens) has a mis-formed filtering rule which considers 2010 to be a "grossly in the future" and therefore can't be a valid date.

This might have been true in Y2K, but in 2010, we're not so gross.

If you use ESVA like we do, there's a simple enough fix which is outlined in the ESVA Forums.

Otherwise, you'll need to fix your local.cf rules or edit the 72_active.cf file.

Further details can be found at Mike Cardwell's blog: SpamAssassin 2010 bug.

I keep coming up against this, and I keep forgetting it, so I figured I'd write it down here for all of our benefit.

Exchange 2003 allowed us to easily mail enable public folders, so something sent to info@domain.invalid would go to a public folder where any number of staff could monitor the mailbox.

However, by default, the mail is stored in the Public Folder as a NOTE and not an E-MAIL (for the geeks in the audience IPM.POST vs. IPM.NOTE)

To make the public folder store incoming mail as emails, we need to make a quick registry change. This is all outlined in MS KB 817809.

Go to

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Public-<GUID>

And create (or edit) the key:

Value name: Incoming defaults to IPM.Note
Value type: DWORD
Value data: 1

Setting the value to 1 (true) stores things as IPM.NOTE (which is what we want). Setting the value to 0 sets it back to saving things as a post.