Managing remote computers (and even local computers only as far away as the office next door) via Remote Desktop Protocol (RDP) tools is both incredibly easy and a big time saver. The biggest limitation of using the Remote Desktop Client (RDC) to manage remote PCs is that it disables the ability to restart a remote PC both via the toolbar and the Windows task manager. Administrators all seem to have their own favorite methods to work around this limitation in the RDC. Common methods include using custom RDP clients instead of the built-in RDC, storing “reboot” executables on the network or internet, and all sorts of scripts that are stored on the ‘net or even typed up by hand.

Working with Microsoft systems I prefer to find the fastest method to work around a problem that doesn’t require ANY custom clients or moving data/files across the network. The first option, custom clients, I avoid because I dislike be slowed down when I’m working from an unfamiliar system or even when my own system(s) crash and are waiting for a rebuild (the client’s systems always come first). The second reason, moving data/files across the network, is best avoided because it’s inevitable that a private or heavily filtered network will restrict access to those files when they’re needed most. So, the best option would seem to be scripts that can be typed in from within the RDC or just finding ways to

I do know one administrator who types so fast that he claims he can manually type a reboot script for Windows XP onto the remote client faster than this method. Personally though, without that typing speed and having a memory that always seems to fail when I try to work too fast, forcing a reboot via the GUI on the remote Windows system is my option of choice. And, here it is, just one command and five clicks to remember long:

• Start > Run… > type “msconfig” and click OK
• Go to the “Startup” tab and uncheck the top box on the list, now check the same box again, so there are no effective changes
• Click OK — you’ll be presented with a “System Configuration” popup with a “Restart” option

• After the restart you’ll also get a popup window promtping you to make the changes permanent or go back into the “msconfig” utility - on a remotely supported system I can’t think of many reasons not to check the “Do not show this again” option

You can leave a response, or trackback from your own site.

A recent upgrade to Crystal Reports XI (CRXI) showed, yet again, why I’m never happy with the Crystal Reports system. We’re largely stuck with it though because of its inclusion in so many custom and commercial .NET apps.

Crystal Reports XI - “Failed to retrieve data from the database” when using :
Following the upgrade from Crystal Reports 10 (CR10) to CRXI existing reports ran correctly, but opening some of them to make minor updates yielded fun “Failed to retreive data from the database” errors. Thankfully we’ve waited as long as possible to upgrade from CR10 and there are already hotfixes for CRXI to solve this. The error occurs in the Crystal Reports designer when adding a JDBC table. This error affects both Crystal Reports XI and BusinessObjects Enterprise XI when attached to a MySQL database.

Crystal Reports XI and MyODBC 3.51 - LEFT JOIN Errors:
We’re still using the MyODBC 2.50 (aka: MySQL Connector/ODBC) driver on any machine that runs or designs reports from MySQL-stored data. Why use such an old driver?

Version 3.51 of MyODBC apparently handles LEFT JOIN differently from other ODBC drivers (I’m not saying it’s wrong either, it could be the one driver that handles things according to standards). To fix the problem it’s necessary to change a registry key that changes how Crystal Reports sequences the query in its Query Builder - here is the registry key change to fix LEFT JOIN for Crystal Reports versions 8 - XI. The problem with making this change in the registry is that it happens to break your ability to connect to other databases, including Access and SQL Server, which we also run. While it would be nice to only run one database our vendors have other ideas, so we’re running MyODBC 2.50 - LEFT JOINS work correctly, the registry key doesn’t need to be changed, and we can still see all those other databases.

Additional problems with older versions of Crystal Reports and MyODBC 3.51 driver:
LEFT JOINs aren’t the only errors resolved by MyODBC 2.50. …When Crystal Reports 9 was first released we were already using the MyODBC 3.51 driver to connect to MySQL, but there were a number of issues in CR9 where tables weren’t listed in the designer and positive numbers were returned as negatives. Crystal Reports support was even slower than normal with any results (no excuse, but his was around the time they were acquired by Business Objects). After mistakenly using an older image to rebuild a development box we noticed that the MyODBC 2.50 driver on didn’t have those errors - and have been using it ever since. Crystal finally got around to issuing hotfixes for those issues in CR9 some time after Crystal Reports 10 was released - only to find that CR10 had the same problem of returning negative numbers via MyODBC 3.51.

You can leave a response, or trackback from your own site.

Two new updates for Microsoft Outlook and one of them is a pretty important security patch.

The security patch fixes another “remote code execution” hole that allows a special form of file attachment to run itself from inside Outlook. Rather than rehash the technical details I’ll comment that this is a bigger problem than normal because it applies to all versions of Outlook 2000, XP, and 2003 plus it also occurs on Exchange server 5, 5.5, and 2000 SP3. Microsoft calls it MS06-003 - the link contains download details for each version of the security patch.

Of less importance but higher visibility, the Outlook Junk E-Mail filter has been updated again. No major reduction in junk mail or change in Outlook’s behaviors from this update (from Dec. 13th, 2005 - so I am a bit late in installing), but they’re worth installing. Even though I can think of more important things for my staff to work on, it always seems to calm users down a bit to see that IT is getting the “latest junk mail filters” installed.

Microsoft Outlook PM’s: I know that out of office responses are handled server-side, so the Outlook Junk mail filter will never help to keep responses from being sent to junk mail too. We can’t turn off sending out of office resonses off-site either - out clients are the only ones who matter when we’re sending those. Is there any chance you could update the Outlook Junk E-Mail filter so that undeliverable out-of-office responses can be matched to the original incoming message - and sent to Junk E-Mail? (…and to whomever runs the MSDN Blogs - there’s no good heirarchy or directory. Your own search function returns poor (and dated) results. Of course, even Google’s Blogsearch returns results almost entirely on keyword content and not on who is a member of what team or by topic.)

Article tagged: Microsoft, Outlook, security, patch, TNEF, MIME, decoding, vulnerability, junk, email, e-mail, filter, update

You can leave a response, or trackback from your own site.

Apparently Symantec was installing its own rootkit with installations of Norton SystemWorks. They created a folder, called NProtect, hidden from Windows Explorer and Micorosft’s APIs (in other words, it was in the regular filesystem but Windows and any software that ran correctly under it couldn’t see the folder existed). While Symantec’s NProtect software was only designed to keep people from deleting SystemWorks files “accidentally” and didn’t directly threaten Windows, the existence of the NProtect folder could have been used by virus writers to create their own programs - and once installed in the NProtect folder those viruses, trojans, and spyware would be a real rootkit that Windows and most anti-virus programs wouldn’t be able to detect and remove.

On the positive side, Symantec has recently, according to eWeek, released an update for SystemWorks that makes the hidden folder visible to Windows. It’s likely that Symantec felt the bad publicity Sony got because of their slow response after installing a similar folder wasn’t worth protecting their own software.

Article tagged: symantec, sony, rootkit, NProtect, virus, trojan, major, antivirus, vendor

You can leave a response, or trackback from your own site.

It is possible to create a situation where someone sending a meeting request will receive a “Message not delivered” response from a user who was not originally invited to the meeting. This is an uncommon message to receive because meeting requests and the use of delegates are relatively uncommon.

Specifically, this occurs when the user sending the meeting request receives a “5.1.1″ non-delivery report from the Exchange Server because a user was deleted from Active Directory and was an email delegate of an original meeting invitee. Exchange stores delegates in the message store instead of in Active Directory, so those references aren’t removed when the delegated user is deleted from Active Directory. Microsoft KB article #312433 describes how to remove an orphaned delegate directly from the Exchange information store - two resolutions are detailed, the second uses Microsoft’s MAPI message store viewer Mdbvu32.exe to edit the message store, Mdbvu32.exe can be downloaded here.

You can leave a response, or trackback from your own site.

Microsoft Office 2003 and XP have create the “local installation source” (LIS) folder during installation on individual PCs. The LIS is a hidden folder that holds ALL of the files necessary to setup, restore, and add features to the installed version of Office. During the last step of Office installation there is an option to remove “local installation files”, when chosen it deletes the LIS folder and its contents. Note that leaving the LIS in-place eliminates the need to insert the Office install CD when updates or repairs are run later, but it also uses a lot of disk space.

The path to the LIS can be modified by the free “Local Installation Source Tool” utility from the Microsoft Office Resource Kit: download LIStool.exe from MS. The LISTool instructions cover disabling, deleting, enabling and relocating the LIS folder. Actively managing the LIS location saves time when repairing and upgrading Office and it can save a great deal of disk space on older desktops.

In any environment where Office wasn’t installed with an application management suite (like Microsoft System Management Server) or via an MSI the following error often appears during repairs or updates:

Microsoft Office <version name> Edition 2003 Installation Error: File not Found A required installation file %s could not be found Original Installation Source Required: If you installed Microsoft Office <version name> Edition 2003 from a CD, please insert your CD. If you installed Microsoft Office <version name> Edition 2003 over your computer network, please browse to the installation source on your network. Once you have located your installation source, click OK.

The above error can be solved by creating a copy of the LIST folder for the correct version of Office (ie: Standard, Professional, Small Business, etc) and placing it on a network share.

You can leave a response, or trackback from your own site.

After setting up a new instance of IIS on a Windows 2003 test server I found that I could connect to it via the WAN and other machines on the LAN but the server itself would’t display the new website. Both IE and FireFox displayed “Bad Request (Invalid Hostname)”, with detailed errors displayed I saw HTTP Error code 400 in both browsers.

Searching found a number of discussions about this error message, but many of them either didn’t solve the issue or simply recommended to “start over” with a new instance of IIS and/or a new virtual website within IIS. The only suggestion I found with specific steps detailed (to set IIS headers to default settings and clear custom headers & MIME types) didn’t actually solve the issue, but it did get me to think about the fact that only the local machine saw the error message.

It turns out that in the Properties dialog for the new website I had assigned a specific IP address (i.e.: 10.10.x.x), instead of leaving the default “(All Unassigned)” setting (see image below with default setting). As a result of the server being multi-homed, using both “localhost” and 127.0.0.1 to access the website in a browser allowed the server to locate itself without using DNS, but those addresses came across a different NIC than the one IIS was assigned to and IIS wouldn’t respond with anything useful (like a web page) to those IPs.

The solutions are simple, but which one is correct depends on the LAN’s configuration or the server being multi-homed (more than one active NIC in the server):

• Use the default setting “(All Unassigned)” in the IIS website properties box for “IP Address:” - this works in single- and multi-NIC servers, but may cause issues on networks with multiple subnets if a site shouldn’t be available to all of them.
• Access the website via the computername (i.e.: http://TEST_SERVER/) while a specific IP Address and not “(All Unassigned)” is selected - if DNS or WINS is running on the local LAN or domain. However, it can still fail if the server has multiple NICs and routes to the wrong one. To get the computername type “echo %computername%” at a command prompt.
• Configure the local HOSTS file (usually %systemroot%\system32\drivers\etc\, “HOSTS” with no file extension) to target the correct correct local machine IP for IIS to work. Note: this may break other services or server daemons running on the box in question, so this is only a brute force option.

You can leave a response, or trackback from your own site.