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:

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...

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.

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.

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.

Happily, Dell has a set of the drivers available.

Sadly, they're part of a floppy image.

Grrr!

Enter Virtual Floppy Drive 2.1, a cool piece of shareware that can be glommed from http://chitchat.at.infoseek.co.jp/vmware/vfd.html

This operates along the same line as Microsoft's Virtual CD-ROM Control Panel for Windows XP, which mounts an ISO image and has it appear as a drive letter.

VFD does the same thing, it mounts an image file (or just creates a small chunk of RAM and treats it like a blank floppy) and you assign it a drive letter.

I loaded the application up -- it's pretty self-explanatory -- assigned to Drive B: and then launched Dell's Floppy making utility, told it to write to Drive B and bingo! I had my extracted files.

From there, it was trivial to copy them to the appropriate install media and we were off to the races.

(I finally searched for a virtual solution, when the one floppy disk I could find was throwing errors. How happy are we that those things have (mostly) gone the way of the dinosaur?)

Oh, a KB article sheds some light:

The option to enable theFont smoothing feature is not available in the version of RDC that was released with Windows Server 2003. By default, Windows Server 2003 disables theFont smoothing feature in all remote connections. These connections include the connections that are established through RDC 6.0.

Happily, MS's dictatorship is matched only by its benevolence, because there's a "hotfix" available for this problem:

KB946633:The "Font smoothing" feature has no effect in Windows Server 2003 terminal sessions

It kinda cracks me up...

"We'll put the feature in."

"But it doesn't work. We should disable the checkboxes"

"Why would we do that?"

I bring this up because we just migrated a client over to a terminal server environment, and the number one complaint was "My fonts aren't fuzzy!"

Since I actually prefer the crispness of an LCD display, I didn't really notice, or care, but since I wasn't signing the check, I did my best to comply. I used bing to google the issue, and found the hotfix.

Of course, since it's a hotfix, it requires a reboot... so here I am at 5:30 AM, having just rebooted the server.

This hotfix is available via draconian download -- you fill out a form, they send an email with the link - however, they put the link in parentheses, so Outlook botches the conversion and breaks the link, resulting in the need for you to copy and paste the URL into your browser. From there, it's a Start > Next > Finish install and a reboot seals the deal.

As a side note: ClearType increases the bandwidth requirements, and is only available if you're running in "High Bandwidth" mode in the RDP 6.0 (or better) client. It also needs to be turned on in the desktop session.

In the RDP client:

Click Options > Experience tab

The check off the "font smoothing" box.

On the Windows 2003 Desktop:

Right click on the desktop > Properties >Appearance tab > Effects button

That should do it!

So, offline files had his documents stored locally, but his lack of network credentials was keeping us from them.

While massively inconvenient, this is how it should be. No credentials, no files. Downside, of course, was I couldn't get the documents copied to the local drive.

Windows 2003 Resource Kit to the rescue!

There's a utility, csccmd.exe which, as the name imples, allows you to work with the "client side cache" (the pre-release name for Offline Files). The most recent version of the csccmd.exe has an option to EXTRACT files from the client side cache and put them on the local drive somewhere.

So, I grabbed the Windows 2003 Resource Kit, downloaded it, installed it,and ran csccmd.exe and it didn't work.

Wha?

Seems there is a NEWER version of csccmd.exe that is only available (officially) from MS Product Support Services (PSS). (Unofficially, use bing to google csccmd.exe 1.1) which does the job. I downloaded it and copied it into c:\windows (just to avoid path issues).

(I assume it's only available from PSS because it totally bypasses the security issue.)

So, logged in as an administrator, I created a temporary folderand opened a command prompt (do I show my age by insisting on calling it a DOS window?) and typed:

csccmd.exe /extract:\\server\share /target:c:\temp\user /recurse

Ta-da!

The files copied, rights of the folder they were copied into prevails (which is to say that the ACL information was not extracted as well) and he's happy because he has his documents back.

A client had a problem with their Great Plains installation -- the fonts went all screwy and while they could still make out the display (barely) they couldn't print checks since the Mekorma font they were using wasn't playing nice.

Clicking on the start menu revealed the username to be in the Marlett font, a font Windows uses for drawing parts of its UI (the X in the close box, the minimize and maximize symbols, etc.). we've seen this problem before, and it's usually fixed by running TweakUI and reparing the font folder. Reboot and voila.

So we do that and the checks can print, but the display font is still not right in Great Plains. Everywhere else in Windows it's fine, but Great Plains is still hinky.

We try all sorts of things -- we delete all the fonts and reinstall them from the c:\windows\fonts folder of a sister Windows 2003 server; no dice.

We troll Great Plains newsgroups, we repair the font folder, we do a repair installation of Great Plains, nothing does the trick.

It has to be a font issue, but which fonts?

We have the Great Plains consultant send over his theory -- a Helvetica font set. Does nothing.

Over at Experts-Exchange (a site well worth the subscription), one of the Great Plains MVPs who was helping us out posted a screen shot of her splash screen, and when compared to ours, I thought to myself "that looks like MS Sans Serif" -- a system font from way back when.

Windows XP brought along a new set of fonts it used in its shell, and MS Sans Serif was deprecated in favor of Verdana, Tahoma and the "modern" UI fonts Microsoft was putting forth.

I opened up a share on a Windows 2000 box, and there was a whole bunch of .fon fonts that weren't on our system. So I copied them over to a temp folder and tried to install them onto our server. Only 3 showed up in the list, and there were a dozen or more in the folder.

Ah! They were hidden. I uncheck the hidden attribute and reinstall the fonts. All of them show up in the list.

I select all, click OK, I get a few "a version of this font is already installed" errors, and then they're done importing.

Now, MS Sans Serif is in the list of available fonts, and lo and behold, our screen is back to normal.

Many thanks to Victoria Yudin who helped us with this issue.

In the original code, we open a query directly as a recordset. This fails if the query requires some parameters.

(I'm not going to demonstrate a way to get user input and use that as the parameter. You should be able to copy and paste the code from the original user input sections of the code and modify as needed.)

To start, let's discuss the query and it's parameter.

In our original code, the query was just pulling a list of email addresses. For this, let's filter that list of addresses by domain.

(For our purposes, I'll assume you know how to write a query with parameters. Here's a screeenshot of how yours should look.)

You can see that we added a parameter called "domain" and the told Access that we want the query to return any record that has "domain" at the end.

So, when we run the query from the design window, we're prompted to enter the parameter:

and when we click RUN we'll get all email addresses from the jephens.com domain.

That's all well and good, but if we run the code as it exists, we get an error:

This occurs because the code doesn't know what to do with the parameter, so it punts and throws an error.

We'll need to handle this. And for that, we have to use a QueryDef object and assign a parameter.

So, instead of:

... we need to do a few things:

1. Create a QueryDef object

2 Assign our query to the object

3. Tell the object what our parameter is

4. Put the output of our query into our recordset.

Happily, this is pretty simple.

And that will filter the recordset and only send mails to people in the .com namespace.

Of course, that's not the most user-friendly code, so you'd probably want to copy and paste some of the user input language and use that to fill in the parameter:

The nice thing about the way we wrote the query is we can leave the domain part blank, and the query will return all the records.