The .NET Platform
Development Tools
COM & COM+
Data Access
Web Development
XML Technologies
Windows Servers
Wireless & Mobile
Security issues
Design & Process
Career Development
Analysis & Comment
Disposable Objects
We found this book useful!
You are not logged in: login here to access all areas.
Dave Thompson on Windows .NET Server
Windows .NET Server, the next version of Microsoft's operating system for servers, has now reached Release Candidate 1 status. Matt Nicholson and Tim Anderson quizzed Microsoft's Dave Thompson about the new features in Windows .NET Server, as well as about .NET Passport, technologies for distributing software and patches, and Microsoft's development strategies.
Author: Matt Nicholson
Last updated: Aug 2002
Dave: IIS 6 is a new design for most of the Web server.
It's been completely cleaned-up with respect to security issues. Application
developers, and the operations guys deploying applications, can take advantage
of a new process model. All the applications can run totally independently.
If one crashes it doesn't affect the others. There are automatic restart
capabilities. You can actually monitor the memory consumption and, when
you hit certain levels, reset the process. Matt: This is automatic? Dave: Yes. You can restart after a certain number of
instances, if you hit a certain memory consumption level, or if it's got
a leak. There's also a function which will poll periodically to see if
it's locked up, to see if it's responsive, and if necessary reset that
process. There are about six different ways to configure the process recycling.
Matt: What about new security features? Dave: We have a new authorisation framework that we
call Authz. That's a key piece of the application platform. Authz basically
lets you build roles-based authorisation and you can extend it with code
to do authorisation using any algorithms you want. One of the pieces of
code, which we ship as an extension, is called Web Authorisation: it'll
look at the URL and then allow or disallow access based on a look-up of
the user and the policy to be applied. It's a .NET Server specific feature. Tim: Is there a versioning issue here because you can
tie your application to a specific version of the .NET Framework? Will
the version number in .NET Server be different from the one that's in
Service Pack 1 for the .NET Framework? Dave: I would expect the answer to be "yes",
because they've made some other changes - for large memory configurations
and support for the 3G byte switch. It wouldn't surprise me though if
it's synched up with a Service Pack 2. So we'd ship the .NET Server and
then there'd be an SP2 for the .NET Framework. I would bet a lot of money
that's the plan. Tim: Can you say something about the Software Update
feature? Dave: It basically lets you run your own Windows Update
service. Matt: This is to actually host it locally? Dave: Yes. So you run your own Windows Update service
and sync with the content that's on Windows Update. Then you decide what
content you want to redistribute locally. There's an auto-update client
that is an enhancement to the one that was in XP. You can load it on Win
2K and it's in .NET Server. You can use it to configure how and when to
take updates. So you can set up a configuration where updates automatically
flow from Windows Update into your corporation. You can also choose to
install or reboot according to policy. Tim: Can you add your own applications into that? Dave: You can't use it to install or update applications
yet. Our strategy is that Windows Update is going to be the source of
content. Today it's got critical fixes, but we'll extend that. The Software
Update service can be considered the pipes that will distribute content.
It can be used as a complete solution in small and medium-sized organisations. Tim: Do you plan to extend that technology? As an application
developer I'd like to run my own Update server on the Internet and have
my customers configure their Update clients to go to my Web site to update
my application. Dave: We're thinking about that, but we don't have specific
plans. We focused on getting the 1.0 version out as quickly as we could,
as part of the toolkit to help people secure their systems quickly. It
only supports critical patches today, but we recognise users want a unified
infrastructure for distributing software - for critical fixes, for service
packs, for whole applications. That's one of the things we have to make
easier. Matt: Will you distribute Windows or Office using this
technology in the future? Dave: It's possible. We're expanding the number of things
which we distribute both through the Windows Update pipe and the distribution
infrastructure. It's a natural direction for us to go. Today we have Office
Update, which is a separate service. It's great that we supply updates
through these paths, but it would be better for users if it were more
unified. Tim: I've heard that there are difficulties running
Exchange 2000 on Windows .NET Server. Can you clarify that? What's going
to be the upgrade path for customers with Exchange 2000? Dave: Exchange 2000 will not be supported to run under
.NET Server. The version that's going to be supported on .NET Server is
code-named Titanium. That was a difficult decision but we decided to focus
on Titanium. Titanium has a number of new features that Exchange 2000
customers are interested in getting. Tim: This is Exchange with the SQL Server engine? Dave: No. Titanium is Exchange 2000 with a set of customer-focused
improvements. We have an internal initiative focused on making sure we
get the best fidelity between Windows .NET Server, Exchange Titanium and
the Outlook that's going to be in Office .NET. This is in terms of addressing,
making remote cached operation easier for clients, and improving the deployment
of the combined messaging solution. There's also operations monitoring
and knowledge packs for MOM [Microsoft Operations Manager]. We've focused
on addressing customer feedback for our messaging solution. Tim: So if I've got Windows 2000 Server currently running
Active Directory on my Exchange 2000 box, I can upgrade the servers around
it as long as I use Exchange 2000 Server on the Windows 2000 server? Dave: That's right. Titanium will run on either Windows
2000 or Windows .NET. Windows .NET has a number of improvements, so if
you're going to go to Titanium the natural step is to go to Windows .NET
as the server. But you do have to have Titanium if you're going to use
Windows .NET as the OS for the messaging server. Matt: What's the timeframe on release of those? Dave: Windows .NET Server will probably come out about
90 days before Titanium does. So there will be a gap during which we won't
have a released version of Exchange that runs on the .NET Server. It would
be nicer to have everything run on everything, but it's less frequent
that people would upgrade the OS underneath an application. Matt: The important thing is that it inter-operates. Dave: Absolutely. We've been extremely careful about
inter-operability. We've spent a lot of time focussing on the upgrade
paths for the Active Directory infrastructure so that you can replace
servers one at a time. We try this in our own deployment testing. Matt: These are working systems? Dave: These are production systems at Microsoft. At
Microsoft we have more forests and Exchange organisations than we might
normally have. This is to simulate the most complex environment and lets
us keep multiple versions of our products for service pack and inter-operability
testing. Testing on live systems. Live deployment testing on enterprise
products convinces me that we understand how well it works. Tim: One of the most interesting technologies coming
out of Exchange has been the Web Storage System, which we've seen in SharePoint
Portal Server and Exchange SP2. This would seem to make sense as an extension
to the server operating system rather than as a feature of Exchange -
the way it enables different approaches to document sharing, for example.
Are we likely to see it become part of the server OS or is it one a technology
that is going peter out? Dave: We definitely see integrated rich storage as part
of the operating system in the future. As to the specific technology solution
for that, I'm not in a position to comment right now. Matt: There's a roadmap where the SQL Server database
technology will move into Exchange, and eventually to the file system
itself. Dave: In different applications at Microsoft, both in
SQL based applications and in Exchange, there's been a focus on rich storage
capabilities. Over time we'll see the OS having the capability of rich
integrated storage and then our applications would converge over time
and use that platform. Our aim with the OS is to have integrated storage
where you can perform database-like queries on files, and files can have
associated properties, and things like that. The same data can be shared
and used between different applications. That's definitely the direction
we're going in future. Tim: Do you think developer's would be better off making
future plans on ASP .NET or on the Web Storage System, because both of
them are platforms for Web applications? Dave: ASP .NET and the .NET Framework form our core
developer platform. The best bets are made on that and the things that
it supports. Integrating with .NET Passport Dave: We didn't make any changes to the Active Directory
- we used a capability it already has. Windows 2000 supports smart card
log-on. There are other ways that you can authenticate the user and then
use the Active Directory's Kerberos-based infrastructure, both on the
server and off. Passport is used for authentication. There's some code
that ships in the server that lets you use Passport as the authentication
entity, but then it maps to a Windows security identity from that point.
So you can do the same thing as before, but previously you had to add
code. Now you don't. We've just made it easier. Matt: Active Directory was built to be able to use a
number of different authentication mechanisms? Dave: Right. There's an alternative identity that maps
to an Active Directory identity. There's a field where you store the unique
identity for Passport, so you can go off to Passport and authenticate
a user with the credentials provided. You generate a token as if you'd
done a log-on with Kerberos. The same thing happens with smart card, but
you use a different mechanism for validating who the user is, instead
of a password. We have a generalised mechanism now called 'protocol transition
and constrained delegation'. This allows other kinds of protocols to be
used and validated, then converted to a Kerberos infrastructure. With
constrained delegation you can actually go off-box to another box in a
secure, controlled way. So you can go off-server to another server and
provide impersonation on that server as well. Matt: So you could go off to a Web site, a database,
or another application server, and authenticate yourself through Passport.
You wouldn't have to log-on - you're just recognised? Dave: Right. Kerberos carries the appropriate information. Matt: What about federation? Dave: Federation is a broad term. It basically means
unifying different environments. You can federate environments today by
setting up trust relationships. Putting forests together is a federation
exercise. If you use MMS [Microsoft Metadirectory Services], you can federate
identities. You can essentially build a super-global catalogue - like
the global catalogue in Active Directory. Matt: Just to clarify, when you talk about protocol
transition is that purely to do with security? Dave: Yes, that's purely in a security context. Tim: What was the impetus behind all the new command
line commands that you've put into .NET Server? Dave: It was pretty simple. Customers managing servers
found that there were gaps in the support for command line scripting in
Windows 2000, which is the way that they wanted to do repetitive automated
scripting or scripting across multiple machines. There wasn't a complete
set of utilities. You could add utilities from the resource kit, and you
could get your favourite shell and install that. We've pulled-in the resource
kit tools, and looked to see where there were other gaps. We surveyed
administrators to find out the things that they needed to do. Tim: Have you looked at Cygwin? It makes Windows more
like UNIX in terms of how it behaves. It extends the commands available
at the prompt in Windows so you can do things like running UNIX batch
files. For administrators that have got both UNIX and Windows machines
it's very useful. Dave: I'm not familiar with it, although I'm sure others
at Microsoft are. Among our services for UNIX we have a set of utilities
from Interix, a company that we acquired, that does some similar things. Matt: If you have a mixed environment then that is quite
important. Dave: It can be. You're going to have some differences
anyway. You fundamentally have to understand the different environments
- you have to understand what you're managing. I can see that it's valuable
to have similar shell languages because when you construct programs you
develop programming skills around a particular shell. That's certainly
something that you would want to be transportable and is largely independent
of the underlying commands. But I think the underlying commands probably
have to be different between operating systems. Tim: Who decided that the slash would go one way on
Windows and the other way on UNIX? Dave: Good question! Tim: Microsoft seems to have lagged somewhat in the
server appliance area. There's a good argument to take something like
Small Business Server and implement it as an appliance - something which
you just turn on and access anywhere on the network using a Web interface.
Are you interested in that market at all? Dave: We are very interested in the appliance market.
We have found that network attached storage has emerged as one of the
more successful appliance categories. We've actually been pretty successful
in that emerging market with the appliances our OEMs deliver based on
Windows. We're actually doing fairly well in terms of market share. We
have explored the categories of appliances as they've emerged. Tim: Two of the big categories would be Web appliances
and small business or departmental. Dave: It turns out that the storage one has actually
been the most successful. Not just for Microsoft, but in general. With
Web appliances, we've found that customers basically want Web servers.
It's not HTML administration of the boxes that is important, it's just
having a fixed function or a server that just has Web server capabilities.
We have Web Blade which is one of the new versions of the server. We've
focused on disabling or removing the additional things that you don't
need in a Web application server. Tim: Does that handle email as well? Dave: There is a POP3 server, but you don't run Windows
applications on it. Tim: Can you use ASP .NET? Dave: Yes, that's exactly what it's for. It's less expensive
and is targeted at areas such as Web farms. You don't run Exchange on
it or SQL Server. In the small business area the Small Business Server
is still going to be our focus. We're making improvements and configuration
changes to simplify it. There are other things changes in terms of packaging
and licensing, which I can't talk about yet, that will make it an even
more effective entry-level product for small businesses. Tim: I like it. I think the biggest problem is with
the installers. My experience is that it's a lovely product to set up
as long as you're intolerant of any errors. I've seen this by going into
businesses where others have set it up. Typically the installers produce
an error, such as an unsupported modem or something of that nature. If
you just let it carry on things fail to install, then when you try to
repair it, it becomes complex quite quickly. Dave: Is that with SBS 2000 or with 4.5? Tim: In both cases. Dave: We’ve seen in 2000 that it's a lot more
tolerant of those kinds of things. I know there were some issues with
4.5 but I'm surprised to hear that about 2000. Tim: But I think it's a lovely product, particularly
because Exchange is included - which is really the big selling point. Dave: Exchange is used on around 95 per cent of Small
Business Server installations. Tim: Whereas SQL Server often isn't. Dave: That's right. SQL Server is used where someone
runs a specialised small business application that needs it. It's the
only time customers use SQL Server basically. I think we understand and
recognise that. Tim: Will you be putting Mobile Information Server into
Small Business Server? Dave: That's a good question. It was one of the things
we talked about. I don't think we've finally settled on that. Tim: Application Center Server has always overlapped
with functionality in Windows 2000 Server. Is that continuing as a separate
product? Dave: It overlapped in what way? Tim: In respect that you could set up clustering, and
so on, with the basic server. Application Center Server adds more manageability
and additional options. Dave: Application Center Server is a tool that's focused
on end-to-end manageability in a scale-out scenario. Scale-out is a core
scenario for us. So over time you'll see Application Center Server, MOM,
and other things, converge with server management technologies. Tim: So will there be an Application Center Server for
Windows .NET Server? Dave: Application Center Server will work with Windows
.NET Server. There's a service pack update. Most of the server applications
will each need a service pack. Exchange is the one case where you're going
to need the next version. Titanium was initially going to be a service
pack, but then we decided there was a bigger set of customer features
that we wanted to add, so we changed the plan. Matt: Does that include SQL Server? Dave: Yes. Most of the things in the service pack are
things that make the overall configuration more secure. Tim: With NT Server people often have to log-on as administrator
more than they really wish to. In the UNIX world you can just type 'SU',
make changes and exit. Is that something you're looking at? Dave: You can do that as well. You can use the 'run
as' feature, which is basically the same as 'SU'. It lets you take a particular
command and run it in an administrator's context. Tim: MSN Messenger, for instance, won't let you install
updates unless you're running as an administrator. Unfortunately it doesn't
try to find out whether you're in administrator mode before it asks if
you'd like the update. It could also be a managed code application which
ought to be able to run in my own personal safe area. Dave: That's evolution. It should do the right thing
without having to ask at all. In the short term the answer is my managed
IT environment where they just update Messenger without me even knowing
it. They do application upgrades all the time. Matt: With Windows NT4 and Windows 2000, the desktop
and server versions seemed to come out of the same development stream
- the release pattern was the same. Now Windows XP is the current desktop
operating system, while Windows .NET Server doesn't have the same brand
name and is on a different time frame. Is this a conscious move to develop
a desktop operating system separately? It always seemed to be a mistake
to develop them together because the issues involved on a desktop are
different to those in a server. Dave: Well, it turns out from an engineering perspective
that it was simplest to develop them so that they were delivered at the
same time - even though the system lets you do specific things for the
desktop and specific things for the server. For instance, the desktop
doesn't ship with a lot of services on it. When the server ships it has
certain desktop features disabled - there's no theme service for example.
It's intentional to run as few extra services as possible. One of the
things we debated was whether or not to support the more sophisticated
video drivers. Matt: Are the kernels still the same? Dave: Yes, the core kernel is the same but a lot of
the features just don't run on desktop machines. For instance, when you
make the scheduler more efficient it has no impact on the desktop. There
are good reasons to keep the code as common as possible in some places,
but then in other places let it diverge. When it has to diverge for the
needs of either system, we do that. The services are managed differently
as a result. They're managed to minimise memory footprint on the desktop
and they're configured to maximise isolation on the server. But it's the
same service code so when you make a fix you make it in one place. Tim: Is the default set of services and applications
going to be reduced in .NET Server? Dave: IIS itself isn't even enabled by default. Nothing
is enabled by default in Windows .NET Server. You have to turn services
on if you want them.
Matt: Can you tell us about Internet Information Server
(IIS) 6, which will be in Windows .NET Server?
We've found that with the support
calls we take for IIS, the vast majority of them are helping people debug
their applications. So we've included some improved tools. There are tools
that help you isolate where some of the bugs are.
When I've talked to customers, one
of their biggest issues is being afraid to put multiple applications on
the same machine because of the interactions between the application code.
Now you can almost transparently recover from a lot of failures in Web-style
applications, because of the statelessness in a lot of cases, and then
debug the application and upgrade and fix it. It continues running just
fine.
In the future, I would expect the
enterprise products we have to use those pipes and be able to get granularity
and control. The key thing is that once you've configured a client, the
client can ask for updates. We've found that when some people are updating
for security fixes, they don't know where all their servers are. In large
corporations, the departmental servers may not be managed servers - servers
that are understood and joined to the domain, for example, in order to
effect control or enforce policy. But once the auto-update client is installed
they can look for updates whenever they're available. So that model is
more robust in terms of applying fixes.
Exchange 2000 will inter-operate with
Active Directory in .NET, so you can upgrade your Active Directory infrastructure
in .NET and Exchange 2000 will be fine. We test and support that combination.
Matt:
Moving on to the Active Directory and its integration with .NET Passport.
What changes have been made to the Active Directory to support that?
We're also developing an additional
service which will ship after .NET Server as an add-on. It will be a federation
service that will let you set up trust relationships using SOAP, so that
it will pass through firewalls in a secure and managed way. But it's basically
about setting up trust relationships between organisations. The other
key element is that it will support sign-on from a broader variety of
clients, by using some of these other protocols that support protocol
transition. These are steps towards federation.
The area of automation, more generally defined, is one where we're making
future investments as well. We're also making future investments in the
Windows management infrastructure - that's a fairly major area of investment
for us.
The most important thing is to have
a broad, uniform, powerful way to administer systems through script and
to administer lots of systems simultaneously. The functions are specific
to each type of system so we've debated the value of trying to be as syntax
compatible with UNIX as possible. It sounds like a good idea, and would
be appealing in some cases, but didn't seem like the biggest issue.
Have you set-up Small Business Server
before? What did you think?
We also had an appliance kit that
added HTML admin and that is in the Small Business Server itself now.
But we don't have plans to build a small business appliance using that
kind of administration. It hasn't been our major focus.
Customers seem to want HTML admin for single function devices. Appliances
are really aimed at making it as easy as possible to perform a narrow
set of functions. HTML admin is great so long as what you're doing is
pretty simple, but it's a clunky way to do certain kinds of administration.
We'd really like to have a converged administration model that makes it
easier to set up servers. I want to provide a solution that's got richness
when you need it, but simplicity when you don't. That's really our goal.
We see two types of server administration
scenarios - managed and unmanaged environments. A managed environment
is looked after by an IT professional. An unmanaged environment is where
someone does the admin part-time as part of their job, and in this case
it needs to be made very easy. We have people who focus on usability issues
in both these scenarios.
At the same time we're also putting
infrastructure in the operating system that makes it easier tools to set
up, manage and scale-out scenarios. Infrastructure and tools that support
scale-out are a key direction for us. We want to build a platform that
basically lets you manage an abstracted set of computing resources, that
will be both dynamic and self-healing. You realise how important manageability
is as you build more sophisticated systems.
Application Center Server is the product
that we have today that supports that specific scenario. In terms of it
overlapping, some of its functions are things that should really be in
the infrastructure.
One of the main reasons the server applications will need a service pack
is because we've gone back and changed the configuration of the systems
by default. We've also addressed security vulnerabilities in the core
operating system, and that broke compatibility in some cases. For example,
when you install exchange it expects IIS to be running. By default it's
not and it gets confused by that. So the service pack will re-enable IIS
and the specific service it needs.
It's similar with these other applications.
If a function is expected to be there, and it's not, the service pack
re-enables it. That is the right way to build secure systems. In the core
system things will be turned off by default.
All the service packs are coming. Within a month of RC1 of Windows .NET
Server you'll be able to run Application Center Server on it, for example.
We work very closely with the other application teams at Microsoft and
with third party vendors. We do a lot of work with vendors of back-up
products and ant-virus vendors ,for example. These people have to closely
integrate with our system. We work with them very early in the development
cycle to make sure that everything works. It's one of the biggest challenges,
but we've got to do it.
Actually, I haven't come across people
that need to run as administrator on NT Server. I have with desktops.
The applications are the things that have to change. We'll implement a
variety of changes in the system, and have a strong logo programme making
sure applications don't force users to be an administrator to do day-to-day
operations. In the next version we're going to push that through for sure.
We'll probably use other techniques, like creating a new class of user
that's got administrator capabilities. That way you can maintain compatibility
and perform the tasks you need to do without really being an administrator.
At work my main system is my laptop
and my desktop system is run in an IT managed environment as a test. We
don't normally run that way at Microsoft because, as developers, we just
do anything we want. But this is a locked-down desktop where I am not
an administrator and I can't install any software. It is run by our hardware
test team that runs it like an IT operation and deploys the apps that
I need. It's actually very rare that I encounter any problems, but it
does happen sometimes. I have to run my mobile phone synchronisation program
on my laptop because I can't load it onto that managed machine. But most
of the business apps I use are on that locked-down machine.
The reason that the developments split was because they had different
business and timing needs. When we stopped the Windows 98 line and XP
took over, it became much more critical to ship on a cycle that fitted
the OEM business. We started out with the intention of shipping on the
same schedule, but when we realised this wouldn't address the business
needs of the server we split the developments. It's a source of tension
- engineering efficiency versus the business needs. It's not a technical
issue because we've steadily increased the componentisation of the system
and built the system with separable pieces.
Click here for our Privacy Statement. Copyright © Matt Publishing. All rights reserved. No part of this site may be reproduced without the prior consent of the copyright holder.
