Quickly Add Telnet

Have you found yourself on a server or workstation that doesn't have telnet (typical in new builds and new Azure VM's from the gallery), and need it to test port connectivity? Did you receive this error when you tried to execute telnet in cmdshell or powershell?

telnet : The term 'telnet' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1

Three quick ways to add the Telnet Client to the server you're on right now that are much faster alternatives than adding telnet via the Windows features section of the Control Panel. Note that you must launch PowerShell or Command Prompt as an administrator to run these commands, so non-administrators will need to track down a helpful sysadmin first.

Install telnet via DISM (via cmd/PowerShell):

This option should complete the installation of Telnet in seconds. You may receive an error if a reboot is pending because of another installation.

dism /online /Enable-Feature /FeatureName:TelnetClient

Install telnet via pkgmgr (via cmd/PowerShell):

This option should also complete the installation of Telnet in seconds. PkgMgr was deprecated along with a few other tools when replaced by DISM for Windows 7. PkgMgr still works on later operating systems, including Windows 8.1 and Windows Server 2012 R2.

pkgmgr /iu:"TelnetClient"

Install telnet via Install-WindowsFeature (via PowerShell):

This method is just as fast but unfortunately doesn't work for desktop installations (client-based operating systems) like Windows 7 or 8.1. Neither does the cmdlet it replaced, the deprecated Add-WindowsFeature. For desktop operating systems, go with the first option above.

Import-Module servermanager

Install-WindowsFeature telnet-client

Can't find SQL Server Configuration Manager in the Windows Start Menu

You may have noticed, like I did, that searching for "SQL Server Configuration Manager" in the Windows Start Menu returns no local results. There is no familiar SQL Server Configuration Manager in the Start Menu any more. Searching for "Configuration" returns other local configuration programs, such as MDS Configuration Manager and SSRS Configuration Manager, but not SQL Server Configuration Manager.

SQL Server Configuration Manager is still right where it belongs, in C:\Windows\SysWOW64. 

A workaround solution is basic. When you find it in Explorer, right-click and "pin to start". Then you will be able to search for it as "sqlserverManager1x". Now it will appear in the Desktop category of the Start Menu.

Microsoft Docs now includes this text to remedy this problem and an explainer on how to find SQL Server Configuration Manager for each version of SQL Server.

Fun with SQL 2005 Service Pack 3

At a remote client site last night, I ran into a series of problems with SQL 2005 RTM and updating it to SP3.

Error Number : 1612

Error Description : Unable to install Windows Installer MSP file

like that, on the SQL, AS, NS, RS, DTS and Tools components. Furthermore, the SP3 install was asking me for the original install media locations of the .msi files before failing each component during the Service Pack installation.

I tried a few of things unsuccessfully: setting explicit admin permissions on numerous folders (has worked in the past), using a different copy of SQL 2005 CD1 media, trying SP2 instead (same problems), uninstalling the antivirus software, googling like a mad man. (Er... I mean Binging.)

Eventually, my mad searching led me to this MSDN Blog Entry, which initially seemed very daunting. And I was correct, it was very time-consuming. But it worked.

(Note that if you've found this blog entry because you're experiencing some of the errors within, the above Blog Entry link Parts 1 and 2 are what you are looking for.)

This error in the service pack log files was the most telling:

Warning: Local cached package 'C:\WINDOWS\Installer\a1b67256.msi' is missing.

45 minutes of searching through logs for eight-digit random strings, copying files from the unpacked SP3 exe and the original media into c:\windows\installer, SQL, AS and RS all were installed by the service pack correctly.

But, the NS, DTS and Tools components gave me an entirely different error.

Error 2902
Operation ixfAssemblyCopy called out of sequence.

 I re-copied the msi and msp files, thinking that perhaps I had done something wrong. That didn't work. I reinstalled, noticing that NS and DTS were installed to be available on first run. I fully installed all features this time around for NS, DTS and Tools, but again, SP3 reported the above ixfAssemblyCopy error.

To get SP3 to take Tools, I had to uninstall and reinstall that component, using the CD2:\Setup\SqlRun_Tools.msi. That allowed Service Pack 3 to finally successfully update. 

What a night!

Some talking points:

• Interesting how I was told five years ago that when Microsoft made SSIS, they didn't re-use a single line of code for DTS. That is hard to believe, since the installers for SSIS are still called SqlRun_DTS.msi.
  
  
• There was some interesting stuff in the logs that threw me off. Stuff like
  
  MSI (s) (74:74) [20:12:05:278]: Note: 1: 2203 2: i:\35a1934bc4ebd525729353c57bb8\HotFixSQL\Files\sqlrun_sql.msp 3: -2147287037
  MSI (s) (74:74) [20:12:05:278]: SOURCEMGMT: Source is invalid due to missing/inaccessible package.
  
  That's really odd, since there actually is an I:\ drive mapped on this server, and it doesn't contain any folders like that. I assume that long-string-named folder is temporary and that its use of I: would be virtual. 
  
  Could the Service Pack actually have been thrown off by the fact that an i: drive existed? I couldn't unmap it, wasn't my server, but I can't help but thinking that was fishy.  Anyone else encountered service pack issues when an I: drive exists?
  
  
• I still don't know the problem with why SP3 couldn't copy the .msi and .msp files on its own. Seems simple enough, what's the explanation? Couldn't be permissions, I gave explicit admin rights to the installing user to every folder I could. Talk about aggravating.