Blog

I've used the open source telnet/ssh client Putty for many years to manage remote machines. Recently I was using a blog post to setup a virtual machine to be used as a web server. The instructions were complete, but the commands were long and difficult to retype. I wanted to copy and paste but I couldn't use the Ctrl-V to paste in Putty because the key sequence is just sent to the connected computer. It turns out copy and paste is extremely easy in Putty, but you need to read the help file. Copy and Paste works with the mouse. Select any text with the left mouse button and it is immediately copied in the Windows clipboard. Right-Click to paste the contents of the clipboard into Putty. Here are a few bonus tips: [more]

Shift-Insert will also Paste into the Putty window.

Shift-Right-Click will bring up a context menu in the Putty window. The top menu item is Paste.

Double-Click will select the whole word below the mouse cursor and copy it to the clipboard.

Triple-Click will select the whole line below the mouse cursor and copy it to the clipboard.

During a level platforms monthly maintenance window, there was a server that decided it wanted to do updates the following week and not the night of the scheduled maintenance.  It appears for some reason it didn’t receive the update policy until after the scheduled time so it set the schedule to the following week.  If you have this problem, the follow procedure worked for me:

1. Log into the SC.
2. Go to Patch Management – Settings
3. Click on Windows Update Agent Policies, and select the appropriate server group.
4. On the Policy tab, change the Automatic Update option to “Auto download and notify for install”
5. Log into the server that you are having problems with and run the following command in command prompt:
   • wuauclt.exe /detectnow
   • Windows Server 2008 makes it a little more friendly.  You can just open up the Windows Server Update Service console and click on the “Check for updates” link.

Recently, I was working on two similar issues with two different laptops. Both users reported problems with opening word documents. When I started troubleshooting the first laptop, I opened Word and then proceeded to wait for around 15-20 seconds for the application to start and another 15 seconds for a new document to be created. When I closed Word, I got a prompt telling me that there were changes to the normal.dotm template and asked if I wanted to save them. Sure, why not? Re-opened word and the problem still existed. When I received the same error message on closing Word, I decided to go check out the templates folder where normal.dotm is stored. In both the Templates folder and the STARTUP folder (for Microsoft Word), there was a template file that was stuck open with a tmp file present. I removed both tmp file instances and successfully started Word. Problem solved!

The second laptop was slightly different. Word would start immediately, but when double-clicking on a document, it would fail to load. No error message; it just wouldn’t load. Looked in the templates directory and didn’t see the same symptoms. After more troubleshooting, I began disabling add-ins for Word. Turns out, the “Send via Bluetooth” add-in was causing these problems. I disabled the add-in and all was good in the world.

I was working with a third party vendor to set up SQL Reporting Services. The reporting services install was on a remote server, while the database for SQL Reporting services was on a remote SQL Server.  Once SQL Reporting Services was installed and I was using the Reporting Services Configuration Tool, I kept getting an error when trying to create the Reporting Service database.  The error was non- specific and said I should look into permissions.  I checked permissions and determined that was not the problem.

One interesting note in this case was that there was already a database for another SQL Reporting Services install on the SQL Server named ReportServer, which is the default name. Because of that, I had to change the default name of the database for this install to a different name other than the default – in this case it was EdgeSightReportServer.

The configuration tool would create the databases as requested on the SQL server, but would give errors when running the scripts post creation. In looking at the logs, I found errors stating that the database could not be found – the name of the database in the log was ‘EdgeSight’. The ReportServer portion of the name had been removed when the script ran, and of course was nowhere to be found. [more]

The error was that ‘EdgeSight’ database did not exist. Indeed it did not. The big question is why did the script say Use EdgeSight to start with? I then set out to try the following:

• Try to configure reporting services with a database named XYZReportServer
• Try to configure reporting services with a database named XYZ

What needs to be kept in mind is that the default name for a SQL Reporting Services database is ReportServer.  Generating scripts for these two different database names gave some interesting results.  No errors with the database name as XYZ.  But XYZReportServer will generate the error.  Further testing showed that [AnyName]ReportServer generated this error.  Any other database name worked.

So what’s with this?  I briefly searched and did not find anything on this subject.  Is it a bug?  a feature?  Is it something that only I have experienced? Who knows, but in the meantime if you are getting an error creating a reporting services database check the name.

At a bank IT consulting customer, the print spooler on both of print cluster nodes was crashing multiple times a day and posting the following error. The DLL in question was part of the Xerox Global Print Driver package.

Faulting application spoolsv.exe, version 6.0.6002.18294, time stamp 0x4c6a9898, faulting module x2utilGO.dll, version 5185.4100.0.0, time stamp 0x4d46e6ea, exception code 0xc0000005, fault offset 0x0004cf8a, process id 0x778, application start time 0x01cc15d439353ddd. [more]

SOLUTION:
When looking at the orphaned spool files, I found that some of the files had a .TMP extension. These type of spool files are associated with LPR print jobs. I was able to pull the printer name from the spool file and found the specific printer that sent the job. This printer was added to the network on the evening of the 16th – the print spooler started having issues on the 17.

In looking at the configuration of the printer, the TCP\IP port was set to use the LPR protocol. This was a configuration that we had used on some printers in the past. When the new printer was setup, it was assigned to the port that was used previously (which is a common procedure). Even though the documentation states this printer supports the LPR protocol, it clearly has an issue with this configuration. I set the port back to the Raw protocol and also checked every other Xerox printer port and set it from LPR to Raw where necessary (8 printers total).

A customer who does CPA work, was getting errors submitting tax returns electronically. They were instructed to install an update to install the new forms needed. During the installation by one of the employees, it stopped responding and only half installed. They had been instructed to reinstall the old version over the current  install then run the update again. I was asked to perform the procedure.

Every time I attempted to re-install the older version it would hang and then give me an error that it was the wrong operating system.  I attempted the install from a Windows 2003 and Windows XP system which is how it is normally installed. After consulting with ProSystems support found that the problem was that the Microsoft installer was trying to run with the installation. The tech said “right after starting the install, open the task manager and kill any instances of MSIEXEC.exe that is running”. I did this and the install ran without any problem. I then apply the updates and it installed the needed updates, using the built in update agent, without any issues.

The nice thing is that when I asked the tech if this was documented anywhere, his response was “nope”.

From time to time, one of my desk monitors would take on a yellow cast.  It happened recently and was persistent in lasting about three days.  I was thinking the monitor would have to be replaced when a co-worker came by my desk, glanced at the monitor and said “you’ve got a bad connection.”

At that time we checked the monitor cable and found it was secure, but the “bad connection”  idea made me wonder if perhaps my laptop wasn’t properly seated in the dock.  I undocked and then docked again, taking care the laptop was firmly locked into place.   When the monitor came up this time, it was back to the normal color.

Thanks my to my co-worker for recognizing the problem right away.  And when checking connections, it is important to think through every link along the way.

I’ve been upgrading our internal Office Communication system to the new Lync 2010 environment. Everything I had been reading showed the two servers can run side-by-side, albeit with different pools created. Running side-by-side allows for easy testing and migration rather than switching everyone over and hoping it works. Unfortunately, what I didn’t realize was the two servers use some of the same database names. While Microsoft has documented this, you have to dig a little through the documentation to find it.

I discovered this travesty soon after I hit the magic “go” button. This button (also known as “Publish topology”) started the deployment of the Central Management Store into my SQL instance. This process involves taking existing databases and placing them into restricted mode. Then the installer attempts to drop the database and recreate it. Since these were OCS R2 databases, however, the Lync installer had problems recreating over the existing table layout. The whole process choked, leaving the databases in a funky, inconsistent, restricted state and communicator non-functional. I was able to connect as ‘sa’ and remove the restriction, but the databases were pretty much a lost cause. Restoring from the previous night’s backup allowed everyone get back online.

Moral of the story: Here’s yet another Microsoft product that does not warn you before dropping databases. Be wary when installing applications that automatically set up databases as part of the installation procedure.

Recently, I was working on our Cisco 3560E switch. I needed to create a route-map and apply it to an interface for some changes we were planning to make. I was able to create the route-map, but it wouldn’t allow me to apply it to the interface with the “ip policy route-map” command. After doing some research I realized to apply a route-map to an interface for policy-based routing our switch had to be licensed for “IP Services.” The command wasn’t even available, which makes sense being that it wasn’t supported. While upgrading the license; I tried to apply the “ip policy route-map” command again. I did a “sh run int vlan 1” to see if the command was showing up in the config and to my surprise it wasn’t listed!  I went back to the documentation and found the route-map command “set ip default next-hop” was not supported at all on the 3560/3750 switch platforms. I removed this command from my route-map and applied the route-map to the interface and everything seemed to apply correctly. Unfortunately, our whole plan revolved around the ability to use the “set ip default next-hop” command.

So when you are working with Cisco equipment there are at least 3 ways they let you know a command isn’t supported in the IOS:[more]

1. The logical way:  The command isn’t present in IOS and it can’t be used.
2. The illogical way: Allow you to apply a command, but doesn’t prompt you with an error if another “child” command is not supported.  This can only be discovered if you review the configuration and see that the command you entered is nowhere to be found.
3. And what I like to call “The Cisco Way”:  Include the command in the IOS to lead users to believe that the command is supported and works with that IOS/platform all the while not supporting the command in any variation of the IOS/Platform.

After further review, the documentation did have a note that stated the command we needed wasn’t supported on these platforms.  In summary, it is a good idea to fully read any and all documentation on supported/unsupported commands for a platform.