Cisco Firewall::FILTERing URL's::Westlaw

Updated
Using either N2H2 or Websense content filtering server with the Cisco firewall (v6.3.3) url-server and filter url commands is a great way to employ URL filtering to objectionable sites. However we experienced a strange issue with Westlaw's research site. At www.westlaw.com users logon and do legal research and choose to print. Interestingly, the printing happens on WestLaw provided printers that are "attached" to the Westlaw service network via modems. Even though this printing is "internal" to Westlaw some print jobs fail for some reason when using url filtering on the firewall. It must create some really odd url to launch the print job and some of these url's must be crapping out at the firewall and/or the content filtering server.
A while back in an attempt to implement this filtering a problem arose with long url's. According to the vendors the solution to this issue was to upgrade to latest firewal code. That has been done and those url's that brought this previous issue to light now are working fine. (logon to hotmail.com and transactions at airline reservation sites resulted in some wild-and long-urls.) But now we have this Westlaw thing.
The workaround to the immediate issue is to make an exception to the filter url statement for the following networks at Westlaw:

163.231.237.0/24
167.68.6.0/23
AND167.231.253.0/24

But I fear a deeper issue is learking in there waiting to arise in some situation that doesn't have a clear and simple workaround.

Exchange 2000::Windows 2000::Account Expiration

Had an odd problem recently with getting into an Exchange mailbox. A user's AD account was setup to expire at a certain date and time. When that time came she was logged on and working in her mailbox. Kaboom-she's kicked out at the appointed time. She tries to log back on and can't. All working as designed. If only the admin had setup the proper account to expire instead of this person who is now locked. No biggy: just re-enable the account in ADUC. Okay fine, now she can log on, but--holy crap!--can't get into Exchange.

Nor can anyone with full rights assigned to her mailbox get into it. Attempting to send an e-mail to that mailbox -> bounced message.

To get this to work I had to delete the exchange account (we have it setup so the mailbox is not really deleted for 30 days) and then relink the exchange account to the AD user.

Conclusion: Expiring accounts is a baaaaaad thing.

DocsOpen UN-Integration::MSWord::Windows Registry

For MSWord and other applications using ODMA integration to DocsOpen (or other ODMA compliant DMS, if any...) ODMA is "activated" in the registry under:

[HKEY_CLASSES_ROOT\ODMA32]

If you remove that key and all it's subkeys then DMS is unintegrated.
This can be done by manually merging a registry file that looks like:

Windows Registry Editor Version 5.00

[-HKEY_CLASSES_ROOT\ODMA32]

Merging that file can be done in a BAT file with the line:

regedit /s [filename].REG

Webview::Windows XP::AD Logon

Continuing saga from previous posting....
When you use Webview interface to Elite time entry and passthrough authentication -
"Pre-Windows 2000" account must exactly match the Elite userid - also case sensitive
and
The case with which the user logs on does not matter (like it does for Elite.)

Elite::Windows XP::AD Logon

When security passes through XP/AD logon to Elite it is case sensitive and will fail if the user doesn't capitalize properly.
If the elite userid is all in lower case, then the user's "Pre-Windows 2000" account must be in all lower case AND the user must key in all lower case when they logon.
Of course if you have multiple "pass through" security applications that have this issue then you will have to change either the elite userid or the userid in the other application to match and then match that to the "Pre-Windows 2000" account.

Aint ya glad you use directory services.... Don't ya wish everybody did?

MSWord::DocsOpen

DOCS Open - Word - "Microsoft Visual Basic: Ambiguous name detected: TMPDDE"
In DOCS Open, when you start Microsoft Word, the following error message may appear:

"Microsoft Visual Basic: Ambiguous name detected: TMPDDE."

This issue also occurs when you attempt to open documents from the Quick Retrieve window or when you save Word documents.

OtherKeywords: temp dde, MS, launching, launch, 97, 2000, 2002, XP



--------------------------------------------------------------------------------
Resolution:
A temporary macro file is created upon opening Word and is then automatically deleted. Occasionally when Word is opened, this file is not deleted. The error message appears when Word attempts to write a new temporary macro file, and one already exists.

Steps to eliminate the error:

1. Open Word.
2. Select Tools>Macro>Macros.
3. Browse through the list of macros and delete any .TMPDDE macros.
4. Close and then reopen Word.

The error message should not appear. (If you are still receiving the error message, check for viruses on all Microsoft Word files being used. An infected file could corrupt the NORMAL.DOT template file and the TMPDDE file.)

NOTE: If you do not locate any TMPDDE macros, (the TMPDDE macro may not be visible through Tools>Macro on the Word toolbar), one of the following options will resolve this issue:

Delete the TMPDDE macro from the MS Word Global Template (NORMAL.DOT) file; this will require you to open the NORMAL.DOT macro template file in Visual Basic within Word and modify it to remove the TMPDDE macro section.

OR

Rename the MS Word Global Template (NORMAL.DOT) file; note that Word must be closed before you can perform this action.

For more information about this issue, please consult the following article on Microsoft's Web site: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q174966