Blog

Who remembers the DOS days when files could only be 8 characters long with 3 character extensions?  Do you remember when Microsoft introduced long files names in Windows 95?  In order to maintain backward compatibility, the system still created 8.3 files names.  Well every version of Windows still does that, even Windows 7.  This can be disabled for performance reasons by setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem:NtfsDisable8dot3NameCreation=dword:00000001 (http://support.microsoft.com/kb/121007) but you never know when you will need them. [more]

I was running an application that had been installed down under C:\Program Files, and it’s configuration file was there, and I needed to pass that as a parameter to the program.  I tried using quotation marks, backslashes to quote the spaces, backslashes to quote the quotation marks, quotation marks to quote the quotation marks – everything I could think of it and still did not work.  Using the short file name with no spaces worked great.

I had some directories created that were made up of only spaces and I could not delete or rename them.  The Windows Easy Transfer would get stuck in a loop because of these, so I decided I better delete or rename them.  I did a dir/x to find the short names, and then I could access them using that.

If you want to find the “short name” path, just run the good ole’ trusty DOS COMMAND.COM.  It’s still there, even on Windows 7!.  Just enter command at the command prompt and a cd if your prompt does not indicate your path.

One side effect to look out for.  Since the short name is based on the first few characters of the long name, renaming the long name and leaving the first few characters the same will result in the short name staying the same.  So you cannot just rename the file to “long file name with spaces-old.txt” to get it out of the way if something is accessing LONGFI~1.TXT.  Renaming it to .old would work.

A while back, before the recent VMware ESX upgrade, I was having problems logging into the VC server. As soon as the main console window would pop up, I’d receive “Exception has been thrown by the target of an invocation”. The fix, which I found in the VMWare forums, is to open regedit, go to HKEY_CURRENT_USER/Software/VMWare and delete both entries (Virtual Infrastructure Client and VMWare Infrastructure Client). Doing this, and making sure the compatibility setting was set to Windows XP, let me in successfully.  [more]

http://communities.vmware.com/thread/119422

Here are a couple tips for working with Cisco sticky MAC addresses on port security:

If a mac address has been assigned by port security to one port and the device is then moved to another port you have to clear the mac address off of the old port before the new port will allow this device to pass traffic even if the new port does not have port security enabled.

Also if you are seeing a duplicate mac address and seeing two interfaces interchangeably locking each other out when the other is enabled you might check to see if someone has two ports on a phone plugged into these ports. I ran accross this at a customer site recently where it was creating a loop on the two interfaces.

In a recent information security audit, we noticed an inordinate amount of broadcast HTTP traffic - primarily from one XP workstation (traffic to/from an external address owned by peak10.com - a hosting organization).  We looked again to be sure we didn't have any rogue hubs in the network and then asked the bank about the situation.  After we gave them the specific workstation name and address, they discovered a user was listening to streaming Internet radio.  They then had to look into why their Internet content control wasn't blocking like they thought it would.

The interesting part of this is the fact the traffic was being broadcast throughout the whole branch network rather than just her system.  Of course, the Internet bandwidth consumption would normally be of more concern than the local network traffic.  However if there already had been a problem with the LAN, this could have made it worse.

ICBA and Visa are providing a free Data Breach Toolkit available to all ICBA member banks.  The toolkit was developed due to the recent data breach at Heartland Systems, and is designed to help community banks answer customers' questions following a breach of credit and debit card account information.  The toolkit provides member banks with customizable materials, including cardholder letters, statement inserts, FAQs and media statements.  You can login to receive your toolkit at http://www.icba.org/publications/visa.cfm?ItemNumber=37529

I worked on a problem the other day in which a user with Outlook 2003 would search for an item in her inbox using a keyword in the subject of an email and the search results would come back empty even though you could clearly see items that should have been returned in her inbox. At first, I thought she just had a setting set incorrectly in her Outlook client, but after trying it with my mailbox, I saw the same behavior. I found the following powershell command VERY useful.

Test-ExchangeSearch –Identity <username>

This command inserts a test message containing a GUID into your mailbox and then searches for it to test the full text catalog. Both with accounts failed this test. Next, I tried to rebuild the index using using the following command.

ResetSearchIndex.ps1 <dbname> [more]

This command stops the MSExchangeSearch service, deletes the full text catalog and restarts the services (which then rebuilds the catalog). I found it interesting that the catalog folders and files were recreated, but the index files never grew. The catalogs for other databases/storage groups were gigs and this one was only 145 kilobytes after 2 hours which should have been plenty of time for the service to at least start crawling the database. I had tried everything I could find from google searches so I started reading through release notes for the Exchange 2k7 SP1 Update Rollup patches (there are currently 5 for SP1 and 7 for pre-SP1). I found fixes for indexing in three of them so I installed the latest one, SP1 Update Rollup 5 at the DR site and moved my mailbox. Everything worked. Moved it back and it was broken again. Pretty convincing. I installed the patch on all production Exchange servers and started another index rebuild. But, I saw behavior differently from I had seen before. When running the Test-ExchangeSearch command with no identity/username, it worked. When I used a real account it didn’t work. I also saw that the event logs said the index service was rebuilding the catalogs, but they were not increasing in size. Very strange…turns out that during a backup operation (which was running at the time when I did the second index rebuild operation), the search service will NOT start a database crawl. It waits until after the backup is done. The next day everything was running normal. Lesson learned…patch and be patient.

The iPhone currently supports the following security policies from Exchange (note: you must have Exchange Server 2003 SP2 or Exchange Server 2007 SP1 or greater):

• Remote Wipe
• Enforce password on device
• Minimum password length
• Require alphanumeric password
• Require complex password
• Inactivity time in mimutes

When you perform the remote wipe from Exchange, it restores your iPhone to factory default (note: this could take up to an hour).  The gotcha – after you perform remote wipe, be sure to “remove mobile device partnership” with your iPhone; otherwise, the next time you try to sync with Exchange it will wipe (restore to factory default) again . . .

I recently ran into a problem trying to restore a SQL Server 2005 database to a Windows XP machine.  The database back up was created on a Windows Vista machine and I thought that the different OS versions was the culprit.  However, it turned out to be related to SQL server instances and folder paths.  Here is full error I received when I attempted to restore the database using SQL Server Management Studio:

Restore failed for Server 'localhost\sqlexpress'.  (Microsoft.SqlServer.Express.Smo)

Additional information:
System.Data.SqlClient.SqlError: The operating system returned the error '5(Access is denied.)' while attempting 'RestoreContainer::ValidateTargetForCreation' on 'c:\Program Files\Microsoft SQL Server\MSSQL.2\MSSQL\[my database name].mdf'. (Microsoft.SqlServer.Express.Smo)

I searched the Internet using the error message and found several posts stating that it was a problem with the privileges of the user account that my SQL Server Express service was running as. I hadn't changed the account it was running as and I had restored other databases in the past, but I checked the SQL Server Configuration Manager anyway.  As I suspected the service was still running as the default account (Network Service), so that wasn't it.   [more]

After I couldn't find a quick fix on the Internet I decided to look around the options in the Restore Database window.  It turns out the problem was with the paths under the restore options.  The backup was trying to restore the .mdf and .ldf files to the c:\Program Files\Microsoft SQL Server\MSSQL.2\MSSQL\ directory.  The instance of SQL Server I was working with was storing all it's data files in C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\.  Once I changed the paths for the database file and log file to be the same as where my other database files were being stored the restore ran fine with no errors.  For additional reference, here is an article that explains the naming of folders for SQL Server 2005 instances: http://weblogs.sqlteam.com/tarad/archive/2006/06/07/10114.aspx

To export a selection list in Backup Exec – edit job, select Submit, copy and paste.  This will give you a nice text version suitable for saving, searching, etc.  Portions of this can be copied and pasted back into the text view of the selection list.

The selection lists are accessible in the SQL server in the BEDB database in the vwScriptPropertiesBackup view.  The fields of interest are ScriptName, ScriptDescription, DeviceSelectionName, PathName, and FileName. A SQL command like this could be used to list these fields.

SELECT [ScriptName]
      ,[ScriptDescription]
      ,[DeviceSelectionName]
      ,[PathName]
      ,[FileName]
  FROM [BEDB].[dbo].[vwScriptPropertiesBackup]

You could set up a DSN and access this with Excel, or use the sqlcmd from the command line.  Adding a WITH clause to select a particular selection list could be useful also.

UPDATE:  This is not applicable to BackupExec 2010.  Instead, you can go to the Job Setup tab, find the selection list, right click "View Summary", and then highlight and copy the text from the window that pops up.