|

The .NET Platform
Tools & Components
COM & COM+
Data Access
Web Development
XML Technologies
Windows Servers
Wireless & Mobile
Security issues
Design & Process
Career Development
Analysis & Comment
Disposable Objects
Events Diary
Software Update
Contact Us
Advertisers
Search
|


And Another Thing
Server services, licensing, Terminal Services and Gobbledegook come
under Jon Honeyball's
scrutiny this month.
Server
Services
"Wouldn't it be lovely if I could just...." This is the typical
musings of a frustrated programmer, especially one who comes from the Visual
Basic background. Multithreading, proper safe low level access and so forth
have been just a few inches beyond our grasp in the past.
However, I have been having great fun with
the final release code of Visual Studio .NET. One thing I have always wanted
to be able to do is to write my own monitoring tools to run on my server
farm.
Obviously, its best if these run as services
rather than as applications, so they can survive without a logged in desktop
session. In the past, you had to use hack-o-matic tools to get your
application running as a service. With VS.NET, you just create the type of
application you need - in my case a VB.NET Service Application.
Being presented with the opportunity to write
fully-fledged VB services is quite a thrill for an aging (and undoubtably
sad!) Basic hacker like myself. Dammit, I did my Petzold initiation over a
dozen years ago, and I see no reason to worry about WinMain() any more. Most
of the things I want to monitor can be done via PerfMon scripts, or
something equivalent. However, sometimes it is most useful to roll your own
solution. VS.NET gives me the tools to do just that.
I managed to get a server service running in
not many minutes, mostly by stabbing at the dialog boxes until something
appeared to install and run. It says something for the quality of the VS.NET
user interface that such a cowboy approach can reap dividends.
Versioning
Can I put in a plea for some common sense? If you want your application to
run on a desktop machine and not on servers, then make sure you are using
the APIs in the OS which allow you to determine the version of the platform
onto which you are installing and running. This is not hard, but it does pop
up time and time again.
It happened this morning. I had a blazing row
with a solutions house. Their software installs perfectly happily onto
Windows 2000 Server, but they are adamant it is licensed for 2000
Professional only. When pushed as to why this might be, they bleated on
about how it was a desktop software solution and not aimed at the server
marketplace. It appears that running the software on 2000 Server is
considered a breach license.
Yet there are many reasons why you might want
to have Windows 2000 Server on a laptop, for example. Maybe you want to be
able to demo a whole end-to-end line of business application which requires
Server rather than Professional. In which case, logging into Server and
tweaking the tasking settings will give you a Pro With Server Power Bits
Attached. But no, according to the fools at this software house, that's a
breach of contract. Some people seem to go out of their way to make it hard
to do business!
Terminal Services
If you are deploying a server application out to a key customer, can I
strongly recommend putting Terminal Services in Administrative Mode onto the
target box? You will need to get the firewall managers to allow an incoming
TS connection from your network to theirs, maybe via an encrypted VPN tunnel
if you are really paranoid. But there is nothing quite like getting the
real-time server loading information from a target server and seeing what is
happening. It can be quite galling when you have developed a complex
ASP/n-tier application and then have no real idea of what is happening out
in the field.
Of course, testing should have given good
performance metrics, but there is nothing quite so sobering as a real-world
test. Being able to TS onto the box in question is a godsend.
Gobbledegook
In the past, I had the warm comfortable feeling that I knew where everything
was located on my desktop machine. All the folders made sense; everything
had a structure and a place. Then along came the idea of redirected folders:
'My Documents' is somewhere on the hard disk, its position dictated by the
login name.
Now, with VS.NET, this has taken on a
completely new and quite scary level. Can you work out where
"c:\winnt\assembly\gac\system.drawing\
1.0.3300.0__b03f5f7f11d50a3a\systemdrawing.dll" is actually located?
Isn't that a pathname that just trips off the tongue? Imagine having to tell
that over the phone to someone fixing a dead computer. "No, I said
1.0.3300.0 and then TWO underscores, not THREE".
There's even whole areas of your NTFS hard disk
which you can't get into at all. Try attempting to get rid of old system
breakpoint data by hand, for example. And what about those hidden files that
Microsoft leave scattered all over the shop? Internet Explorer is notorious
for this too.
If things get much worse, we will have to
start a Campaign For Clean Disks. Sign me up as a charter member, please!
Top of page
Back to Articles
Copyright © 2002 Matt Publishing Limited. All rights reserved. No
part of this site may be reproduced without the prior consent of the
copyright holder.
|
Nov 2002
Sept 2002
July 2002
May 2002
March 2002
|