End the OS Flame Wars

PowerShell is a great tool for scripting. It is not installed by default on any Operating System, but will be the defacto scripting platform to come, at least in the Microsoft world. So start learning it! With Systems Administration, every vendor is trying to push their platforms. Sun is pushing OpenSolaris to fight Linux. Open Solaris certainly has many advantages over Linux. Linux has some advantages over OpenSolaris. This is a whole blog post in itself.  In my opinion, OpenSolaris is better for a Server OS than a desktop OS. I will blog about that later though. Windows is another beast which definitely has a strong hold of the business software market. It is gaining market share on four socket systems beating Sun and Linux out, but not on the eight socket plus systems. Microsoft is not in that space yet as far as adoption goes.

Now, I mostly support Windows based systems. For the past five years, I’ve also been support VMWare products as well including ESX Server and now the Virtual Infrastructure 3i.  I’ve always had some Linux distro installed on an old PC for tinkering too.

So what does all of this really mean?

This means that no systems administrator can really focus on one operating system anymore. (No, I’m going to qualify the various Linux Distributions as different, because the basic architecture is the same. Yet another blog post topic). We are living in a distributed systems world where one must learn all different operating systems, programming languages and above all be OK with it. Now I’m all for pointing out differences, strengths and deltas (delta is a management term for weaknesses) in different OSes, but the folks all tied to the idea that one operating system is great for everything are sorely mistaken. Yes, I’m talking about all of the Windows Systems Admins that think Windows should run Oracle on 32 processor servers. (I haven’t met one yet, but I’m sure they are out there).  I am also talking about the Linux zealots that think Linux is then end all and be all for all computing applications because of it’s particular licensing scheme. It’s not. Get over it and move on. I am also talking to all of the creative types that think Apple will take over the world and aliens will pop out of Steve Jobs and run for President.

The fact of the matter is that most companies will use the best application running on the best OS/Platform for the job. Bar none. If Oracle runs better on AIX than Solaris. Companies will make the move because it’s more reliable and cost effective. In the Windows world, IIS 6.0 was a huge win over IIS 5.0. Folks upgraded to Windows Server 2003 and IIS 6.0 in record time because IIS 6.0 was a very compelling upgrade. PHP is a programming language that is gaining adoption everywhere. Microsoft is now fully supporting PHP, because the company wants to make sure that when people deploy PHP, they don’t deploy it on Liunx. They deploy it on Windows. There are some good arguments to running it on Windows now. (Hey another great idea for a blog post).

If you are a startup, sometimes cost is the large issue, so you may opt for more open source solutions. Just bear in mind that there are programs out there to use Solaris and Windows very cheaply. Believe me when I say that Microsoft, Sun and other vendors want adoption to their platforms over cost any day. There are many programs out there that can get startups commercial software at reasonable prices or a very delayed billing timeframe. (Yet another good idea for a blog post).

Well, I hope you got the drift that Systems Administration in the future will not be about which OS kicks the other OS in a kung fu battle. It’s about making applications work in a heterogeneous environment and understanding the underlying technologies that run everything. You will be more valuable as a Systems Administrator by understanding more Operating Systems, programming languages and platforms.

  • Share/Bookmark

CScript Visual C++ Runtime Library Error

Last week I had interesting issue with running cscript to execute wsf jobs on a  Windows Server 2003 x64 Edition Server running SQL Server 2005. Every time Cscript ran, a Microsoft Visual C++ Runtime Library Error popped up.

Error Details:

——————————————

Runtime Error!

Program: C:\winnt\system32\cscript.exe

R6034

An Application has made an attempt to load the C runtime library incorrectly. Please contact the application’s support team for more information.

—————————————————————————–

CScript Visual C++ Runtime Lbrary Error

CScript Visual C++ Runtime Lbrary Error

We have five other SQL Server that run the same job, so I know the job works. In order to find out what was going on, I ran Process Monitor to see what dlls are being called by cscript. As you can see from the error, the Microsoft Visual C++ Runtime library was being called from the Microsoft SQL Server Tools\Binn directory. CScript should be calling the msvcr80.dll from the C:\winnt\WinSxS directory as noted in the screen shot below. (I ran the job and Process Monitor on a system where the job ran correctly.)

CSCript Correctly Calling msvcr80.dll

CSCript Correctly Calling msvcr80.dll

Now that we know that the incorrect msvcr80.dll is being called, we need to figure out why and how to correct it.

Microsoft WinSxs Directory is for Side-by-Side assemblies and dlls. The Windows Kernel works with Fusion to find the correct dll needed for the application. (Learn more about Fusion). In the case of the working system, fusion was finding the correct msvcr80.dll.

The Result:

The wsf script called SQLDMO.dll for a function call. The working system had an updated version of the dll with a Manifest which pointed to the correct msvcr80.dll.

The problem system had an older version of the dll with no Manifest, so the closest msvcr80.dll was being used after SQLDMO.dll was called.

To fix, The SQLDMO.dll was updated to the latest version and the problem was solved.

With this issue, using Process Monitor was the best tool to figure out what the problem system and the control system were doing since it pointed out the different msvcr80.dlls being used.

  • Share/Bookmark

The many ways to control Windows Services

I’m often asked how windows services are controlled in the enterprise. There is a variety of convenient ways to control services, each with strengths and weeknesses. We’ll go through some of them today.

1. The services.msc MMC is the nice GUI provided by windows. This features a very intuitive interface, but can only connect to one system at a time. This is not very scalable if you need to shut down many services on multiple machines.

2. net start, net stop etc.. This is the original command line version to control services. Good when you are on the system. This is scriptable via a batch file. This command came with Windows NT.

3. sc.exe comes with the Windows Resource Kit. This is a great tool and allows to control services on remote machines. Setting up services can also be done with this tool.

scquery

scquery

 4. PS Service (psservice.exe) from the PS Tools Suite, authored by Mark Russinovch. psservice runs on the command line like sc.exe and shares some of the same features like controlling services on remote machines. One advantage is displaying the security descriptor in a readable format.

PSService Security

PSService Security

5. WMI or Windows Management Instrumentation can control services. WMI can be programmed from VBScript, c# (.NET) and PowerShell. Flow control can be quickly executed with any of the mentioned programming languages giving administrators precise control over which services and systems need to have services controlled. Below is an example of some VBScript functions starting and stopping services via WMI. These functions also start/stop the dependate services which is important.

Function StopServiceWMI(strServiceName)

  strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colServiceList = objWMIService.ExecQuery("Associators of " _
   & "{Win32_Service.Name='" & strServiceName & "'} Where " _
        & "AssocClass=Win32_DependentService " & "Role=Antecedent" )
For each objService in colServiceList
    objService.StopService()
Next
Wscript.Sleep 5000
Set colServiceList = objWMIService.ExecQuery _
        ("Select * from Win32_Service where Name='" & strServiceName & "'")
For each objService in colServiceList
    errReturn = objService.StopService()
Next

End Function

Function StartServiceWMI(strServiceName)

  strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colServiceList = objWMIService.ExecQuery _
    ("Select * from Win32_Service where Name='" & strServiceName & "'")
For each objService in colServiceList
    errReturn = objService.StartService()
Next
Wscript.Sleep 5000
Set colServiceList = objWMIService.ExecQuery("Associators of " _
   & "{Win32_Service.Name='" & strServiceName & "'} Where " _
        & "AssocClass=Win32_DependentService " & "Role=Dependent" )
For each objService in colServiceList
    objService.StartService()
Next

End Function

5. One of the last methods is to use the native Get-Service PowerShell CmdLet. To understand what Get-Service can do. Type in Get-Help Get-Service in the PowerShell command prompt. You can resume, start, stop, restart, suspend, set service properties and create a new service. PowerShell does not currently have remoting capabilities, so all CmdLets are executed on the local server. PowerShell V2 will have remoting capability using WS-MAN, but that will be a topic for another time.

I hope you’ve enjoyed the quick tour with controlling Windows Services. Automation is the key to success in the enterprise.

  • Share/Bookmark