Tuesday, October 31, 2006

Windows error: Directory or File could not be created

I once helped a guy out with a wierd problem: he was trying to save an Excel Spreadsheet to a USB flash drive, and kept coming up with this error:

The file or directory could not be created.

We tried dragging and dropping the file – same error. There was plenty of space available on the USB drive, and fragmentation was not an issue.

I finally figured out that the problem was that the flash drive’s root directory (where we were trying to save the file) had too many files with really long filenames. The FAT filesystem has a limit on the number of filename characters that can be used in the root directory. From MS TechNet :

“An interesting side effect results from the way VFAT stores its long filenames. When you create a long filename with VFAT, it uses one directory entry for the MS-DOS alias and another entry for every 13 characters of the long filename. In theory, a single long filename could occupy up to 21 directory entries. The root directory has a limit of 512 files, but if you were to use the maximum length long filenames in the root directory, you could cut this limit to a mere 24 files. Therefore, you should use long filenames very sparingly in the root directory. Other directories aren’t affected by this limit.”

This drive’s root directory had a lot of files with very long filenames, so that although there was plenty of physical space available for storage, the limitations of the filesystem itself prevented the addition of another file with more than ten or so characters in the filename.

This was confirmed when we renamed the file “test.xls” (fewer letters) and were able to copy it to the flash drive successfully.

The solution, as you might suspect, is better organization. Rather than storing all your files in the root directory, create some folders and store your files inside those.

Most USB drives are formatted as FAT for compatibility between various platforms and I suggest you leave it that way.

Friday, October 27, 2006

Internet Explorer keeps crashing when accessing CRM

Can you tell we've been having fun with Microsoft CRM lately? On one of our machines, IE was able to access CRM as normal but would always crash after a couple of clicks. This turned out to be a known IE bug. Microsoft has released a fix which you can download here.

Sharepoint Site - "access denied"

Incidentally, we have also had users unable to log in to SharePoint sites — the browser would say something like "access denied" without even giving them a chance to login — and found that the cause was essentially the same problem as the post below: cached incorrect username/password combinations.

Once again, simply delete the affected sites' entry from the Managed Passwords list as described in that post. Also make sure that any SharePoint sites you use are in your "trusted sites" list under IE's Internet Options window.

CRM Outlook client won't go back online; IE CRM client closes abruptly

When using the outlook client for MS CRM 3.0, and trying to click the Go Online button, you may get an error message saying:

“Microsoft CRM cannot go online. The Microsoft CRM server was not found.”

Often when this is the case, you are also unable to access CRM directly through Internet Explorer. You can confirm this is the problem by opening a new Internet Explorer window, typing the name of your CRM server in the address bar (usually just “crm”), and clicking “Go.” IE will resize for a split-second and then just abruptly disappear.

First of all, make sure of the following:

  1. That you are connected to the LAN and logged in to the Windows domain
  2. That the url of your CRM server is in your “Trusted Sites” list in Internet Explorer, and that the security level for “Trusted Sites” is set to “Low”.
What’s happening is that IE has cached a username/password combo for the CRM server that is incorrect. It fails in the background, and gives up without ever letting you know what happened or giving you a chance to enter it correctly.

To fix it:

  1. Go to Control Panel → User Accounts. Click the Advanced tab, and click “Manage Passwords”.
  2. If we’re on the right track, you will see an entry for the CRM server among the list of stored passwords. Go ahead and delete it.

Thursday, October 5, 2006

Possible reasons you can't get a TLS connection working on your Exchange server

So you set up your MS Exchange Server 2003 to use TLS connections for a specific domain, and when you try and send email to that domain, it gets stuck in the queue. If you look in the Exchange System Manager, under Queues, you see those emails just sitting there with a status of "retry" and clicking on the affected queue shows "The remote SMTP service does not support TLS."

As you can guess, this happened to me recently. Using Ethereal on the affected server, I did a network packet capture while sending an email from an internal client to the required domain (them.com):

220 Mail1.them.com ESMTP

yourserver> EHLO mail.myserver.com

Response: 250-Mail1.them.com
Response: 250-8BITMIME\r\n
Response: 250 SIZE 20971520\r\n

You can do the same thing by doing a telnet mail.them.com 25 to open a manual connection to their mailserver. Once you get the 220, go ahead and type EHLO yourserver.com and you will get a list of responses. The main thing to note is the presence or absence of the line 250 STARTTLS among the list.

So you see, because Exchange does not see STARTTLS listed, it does not believe the remote SMTP service can handle TLS transactions, so it closes the connection.

This particular case was strange because both of our servers had successfully used TLS connections in the past. Even more strange, I could get the STARTTLS response when telnetting from an outside server but not when connecting from our company's mail server. The problem in this case turned out to be the firewall on the other end - they happened to be using IronPort. This firewall checks every incoming IP address and assigns it a score, then uses different policies based on the score. They had neglected to allow TLS in one of these policies and our server's IP address happened to be scored high enough by the firewall to fall into that policy.

Thursday, September 28, 2006

Laptop User Not Authenticating in an NT Domain After Changing Password

I just spent a ton of time figuring this one out, so maybe it will help someone else out there doing a Google search (which is kind of the point of everything on this blog). We had a user with an XP pro laptop who changed his password one morning (it was going to expire soon). Later he noticed that none of his drives were mapped, and that his Outlook client not connecting properly. Normally the problem in this scenario is cached logon credentials. When you change your domain password, the laptop doesn't cache your credentials until the next time you log in. So, to ensure that they get cached properly, you need to log out and log back in again using your new password while still connected to the domain network (i.e., do this before disconnecting the laptop and bringing it home). Now, we reset the password several times and it still didn't work. A capture of all network packets during the login (using Ethereal on the server) showed that the Kerberos authentication was failing but of course didn't say why. Articles and mailing lists found while googling for an answer suggested the following:

  • Edit the Registry to disable caching of credentials (info found here, scroll down towards the middle): this didn't work for me, I think because it doesn't actually remove the cached credentials.
  • Manually map a drive using NET USE to authenticate: This idea was found on this page (first item on the list) which seems to contain a lot of good info but it really turned out not to be helpful. In this case I was able to map drives manually using this method but this didn't trigger a re-caching of the credentials, thus in the end the windows login still was not authenticating the session into the domain. Bzzt!
  • Some loser somewhere even claimed the problem for him had been a bad network cable, even though (like me) he was still able to get an IP address and browse the web. Umm, yeah.
Solution: I finally found out where the cached credentials arew actually stored: Go to Control Panel → User Accounts → Advanced tab → Manage Passwords. In this case I found that there was a saved username/password combo stored for the domain controller. I deleted it, logged out, and logged back in again, and it worked.