- Sign-up Now!
 - Current Issue
 - Edit Your Profile/Unsubscribe

Subscribe | Media Kit | About Us | All Issues | Subscriber Feedback | Contact Us | Privacy Statement
Sunbelt W2Knews™ Electronic Newsletter
The secret of those "who always seem to know" - Over 500,000 Readers!
Sat, May 23, 1998
  This issue of W2Knews™ contains:

Hi All,

I could finally make some time to look at NT 5.0 from a System 
Admin perspective. I'm giving you the "bare bones - nutshell"
overview so that you at least have a conceptual understanding 
of the (major) changes to come in the NT system admin area.
Now that Beta 2 of NT 5.0 is coming out, it's a good time to
spend a bit of time looking at where we are going to live in
the future.

Oh, and before I forget, our people reminded me to warn you
about the May special: anyone that puts in an order of $500+
before the end of the month makes a chance to win a $1,000 Harman
Kardon stereo OR a full LearnKey MCSE training kit with a value 
of $1,695: the lucky winner can choose which one of the two...
Now, having the commercial out of the way, lets dig into 5.0!


First of all, for most of us, we will not see 5.0 in production
until the year 2000 or later. Final release of this enormous 
new version I expect will be first half '99 at the earliest.
It's more than twice the size of the current 4.0 due to the
inclusion of many additional modules. And it may be three times
larger as I keep on hearing about extra pieces of software that 
are getting included, like the recent Hewlett Packard and 
Computer Associates code.

A recent survey by one of the three leading USA NT magazines 
showed the following response on the question: "How rapidly do you 
anticipate migrating the majority of your machines over to 5.0?"

10% Immediately
22% 3 to 6 months after its release
27% As soon as budgetary or business obligations permit the upgrade
28% Only when business or technical needs force an upgrade
13% After the first Service Pack is released
(there were some more answers, but these are the most important)

Looking at the above, most of you will take 5.0 into production
in 2000 so we have some time to prepare. From a system admin 
perspective BY FAR the most important feature is Active Directory
(AD). That's what we are going to look at and give you 
understanding about the limitations of 4.0 and how AD will make 
your life easier.


You will be able to get to AD via the new Microsoft Management 
Console (MCC). In MMC will be the User Manager, Performance 
Manager and Event Log among other snap-ins you can define yourself.

AD is designed to allow NT to grow into a true large scale NOS,
but what will it really mean to you? We'll first look at the 
current 4.0 architecture.

Your current 4.0 domain architecture is built on the Security 
Accounts Manager (SAM) database. Every domain controller contains 
a replica of the SAM. It contains information about all users and 
servers in your domain. When your users try to access domain 
resources, your domain controllers provide authentication. 

The SAM can be compared to a clearinghouse for access to work-
stations, servers and BackOffice products, but it has some 
limitations that cause admin headaches.

The limitations come to light in the example of an example medium 
size company we'll call YesCorp, they sell posters with motivational
pictures and quotes. It has three departments in three buildings: 
first is Management HQ, then there is Design, and the production 
department which is the printshop. 

Because of severe server downtime that occurred 9 months ago, the 
three departments have been assigned their own administrators. The 
Human Resources people thought these three individuals would be 
compatible but one has a Novell background, the second is a true
blue IBM Mainframer and the third has been trained as an MCSE from
the ground up. They do not get along well at all ;-)

The Design department adopted Windows NT the moment Quark Express
was available (early) and did all the domain configuration. When
the two other departments implemented NT the systems administrator 
of Design would not let them manage his domain, and as it goes
neither would the other two. So here we have three domains with
three admins and no one will let the other two mess with their 

All three domains need a trust relationship with the other domains, 
but access to domain resources by other domain groups is very 
restricted. As you know, account restrictions on non-granular rights 
are "all or nothing". These rights can be managed by local groups, 
but control through this mechanism is cumbersome to say the least. 
Several third party tools fill these gaps. One of these is Trusted 
Enterprise Manager.

The SAM is MS proprietary and the architecture of the accounts 
database is restricted so that no other application can access 
the information. That means all apps have to maintain their own 
user account database. (For example non-MS Email systems)

A few months ago a "Billy Backhoe" cut through the cables that 
connected two of the buildings and it took 3 days for a contractor 
to repair the cable. During those 3 days, no changes to groups 
could be made and no passwords could be updated. You see what I 
mean, the current domain account model is fragile, no redundancy 
has been built in. Account updates can occur only at the PDC 
and are replicated to the BDC's. 

In case the PDC fails, BDC's will continue to provide user log-on 
validation. But they will not be able to update account information
until the PDC is back in use. YesCorp has to maintain both Windows
Internet Name Service (WINS) additional to Domain Name System (DNS) 
databases. The result is that when your users open their Network 
Neighborhood they have to wait a long time to get a list of all 
the available machines.

Name Services are not provided by Domains. Systems in an NT 4.0 LAN
connect to other systems in three ways. To connect boxes with the NT
domain names, NetBIOS names must get resolved to IP via WINS, which
is an MS proprietary database. And to connect to hosts on the 
Internet, names must be resolved using DNS. When your users open 
their Network Neighborhood, a box called the Master Browser must 
populate that dialog box. 

The Master Browser can be any system on the LAN, including a WFW box
and is determined automatically. The problem is that none of these 
three systems really interact, and all three have similar data in 
them. You can see that Murphy's law has a field day with this kind 
of a setup. So how will NT 5.0 Active Directory be an improvement?


The Domain viewpoint has completely changed. That is the first thing
to understand if you want to get the new 5.0 domain concept. In NT 
3.51 and 4.0, all domains are separate entities. No directory 
lookups can be done across domains. But in AD, all domains are 
linked into one big master directory. You can see this massive 
directory as a "tree" of domains. Every domain functions as a 
logical container for users, servers, and files, but it is possible 
to search through all the domains for user or resource.

With this setup, YesCorp can continue with their current three
departments and their own domain. But they can now be linked into a 
tree and not sacrifice each admin's autonomy. The benefit is that
users are able to search for a resource in all three domains.

Something else that is new, is that AD introduces the concept of 
Organizational Units (OU). These are a logical continuation of the
Global User group concept. OU's are logical groupings of not only 
users, but servers, printers, and also other domain resources. 

Making this a bit more real, our YesCorp's three departments have
their own groups of users, but you could put all three into one OU.
This overhauled system lets you organize your domains according to 
the logical structure of your organization, and not just the 
geographic location of your users. Using a tool like Trusted 
Enterprise Manager you can create OU's now which will ease the
migration to 5.0, and continue to use it in that new environment.


In NT 50, every domain controller accepts changes and will transmit 
these changes to other domain controllers. You can promote a member 
server to become a domain controller just by starting a service, 
and you no longer have to rebuild the whole O/S!

With all your controllers sending updates about accounts, AD uses
a new system to synch changes and avoids to override updates.
This new system is multi-master replication, and uses Update
Sequence Numbers to make sure changes are synched. There is more
detail to this but for this briefing it suffices to look at the
results: it allows multiple changes and no longer requires time 
stamp tracking. Also, only the changed properties of objects that 
are changed are replicated, reducing your bandwidth consumption. 

You can design the scheme of replication partners and manage the 
replication intervals. You can build in loops in the replication 
topology to make sure that account updates arrive at all your
servers regardless of the status of those systems. This new way
of setting it up definitely increases the fault tolerance of 
your NT infrastructure. If YesCorp's printshop loses connection
by another cut cable, users will at least be able to change their 
passwords at their own local domain controller.


In this light, the most important 5.0 change is the switch from 
NetBIOS based server communication to TCP/IP based communication. 
This improvement ends your reliance on the WINS service (which is
a major headache) and makes the DNS service the primary platform
that does name resolution.

In the new AD, domains have DNS compliant names. The top of your
domain tree has the same logical name as your Internet Domain 
Name. Domains under your top one are subdomains. For example, 
the domain for YesCorp is yescorp.com. The design domain would 
appear as design.yescorp.com. Easy!

When your users click on the Network Neighborhood Icon, (which has 
been renamed "Directory"), they can access Active Directory and 
search it. The Master Browser is no longer queried, but instead 
it runs its queries against domain controller information. This is 
better than aspirin for admin headaches.

In 5.0 your users can log on to a domain by using their current 
domain name. They can also use their fully qualified user-account 
name to log on, which includes their full domain path. For example, 
our guy that cut the cables from the printshop could log on as 
[email protected] In 5.0 any user can log on from 
any desktop as long as that desktop had access to the AD.

It's not going to be easy to migrate to 5.0 but as you can see
once you've got that major operation behind you it will pay off
in being able to go home early a few days per week.

Hope this has made Active Directory a bit more clear for you!

See you next week with the full NTools E-News where we will
talk about Microsoft Authorized Technical Education Centers 

Warm regards,

Stu Sjouwerman

(email me with feedback: [email protected])