Windows paradigm has changed over the years, and with Windows 2000 takes a huge step forward into a true enterprise solution.

•Initially, you had standalone workstations.

•With Windows 95, you had workgroups, which are roughly analogous to OU’s in Windows 2000. The workgroup allowed limited sharing of resources like printers.

•With Windows NT, you had domains. The domain had a common authentication and name resolution, but lacked true directory services, and wasn’t really enterprise capable.

Now with Windows 2000, you have a forest or tree of domains, with Active Directory providing three basic enterprise services: Name resolution, directory services, and authentication. Microsoft chose common standards in implementing Windows 2000, so DNS, LDAP, and Kerberos are the protocols underlying these three basic services. Stanford already has enterprise implementations using these standards, and fortunately, Microsoft’s implementation allows for interoperability.

Windows enterprise paradigm

Integration with Existing Enterprise

The Windows 2000 Project is about integrating Microsoft’s Active Directory (AD) with the existing enterprise, and

making AD work given Stanford’s organizational structure.

Windows DNS: NetDBWindows workstations will retain names such as myworkstation.stanford.edu, and will continue to require

an entry in NetDB.

Windows Directory: Stanford.youThe Stanford Directory (Stanford.you) provides an authoritative source for person-related data. The

Windows infrastructure will subscribe to a partial set of this data.

Windows Authorization: SUNet IDAccess to all campus kerberos-based services from a Windows workstation in the infrastructure will require

a single login. Windows users will login as SUNetID@stanford.edu.

Domains, OUs and Computers

Computers join a domain other than the root domainDomains are based on school or large group distinctions. A general domain is available. The root

domain is for enterprise objects only, which provides a security zone.

Local Windows administrators retain local power over desktops and serversOUs provide a way to delegate authority. Have ability to create local accounts, administer

computers, manage resource access, restrict login, manage your environment.

User Account administrationAccount OUs

All accounts will be under a common root OU, placed in a second level OU named the value of the department listed for the person. This enables us to give departments the ability to directly manage their Windows accounts, via the standard Microsoft tools. This management will only be for Windows-only

account attributes, such as Home Directory location, Profile location, and Terminal Server settings, which is data that is not stored in the existing Registry/Directory. All other person/account related data should be

managed via the existing source systems. There will be no web portal as previously discussed, and departments will be able to set account based GPOs, without loopback.

What is a harvester?•Several source systems feed the registry.

•The registry posts an event to an event queue when any record changes.•A harvester is a program which polls this event queue for events, and takes

action by copying the person’s record to another directory.•Currently, a harvester loads the Stanford Directory. A different harvester

will load the PeopleSoft implementation.•This event-driven architecture makes it easy to initially load or reload a

directory, by manually placing an event for each person in the event queue.

Harvesting to AD

Ensuring privacy of personal data is top priority, and we do not want to replace the existing directory services

With this in mind, very little is harvested. Currently, we only plan to harvest a person’s:unique SUNetID, department, privilege group memberships, name, and privacy settings.

Passwords are synchronized but outside of the harvester process

What is ITSS’ role?

ITSS wants to enable departments to do business how they want, but provide a reliable and secure infrastructure

ITSS will manage the following:All domain controllers,

the integration pieces of the infrastructure,the harvester,

account creation/deletion & passwords,delegation of account OUs,

creation and delegation of domains,infrastructure-wide policy,and the general SU domain.

ITSS also wants to provide technical leadershipITSS will provide:

Migration assistance for departments,facilitation of infrastructure-wide schema management,

limited emergency departmental administration,security warnings and prevention,

Windows administrator contact lists,and documentation.

•24x7x365 on-call rotation•ITSS has 99.999% uptime for the 80+ Windows servers it currently manages

•Generator-backup UPS, climate control, and multiple locations •Dedicated Network

•Domain controllers security is tight: Campus Security reviews security logs & regularly scans domain controller subnet

•Frequent infrastructure data backups: Global catalog servers backed up 6 times a day

Operational details

Still in development

1. Gb Networking not here yet• Sweet Hall co-location details still being worked out

2. Full NetDB support• SRV record support for Domain Controllers• Machine data sync’d to AD (i.e. user and location)

•File sharing with colleagues in other departments

•Access your data from any campus Windows machine

•Less account maintenance, and the possibility of single sign-on

•Software distribution via Group Policy

•Other possible infrastructure services•Exchange mailboxes

•Remote Desktop Management

•Allows for other advanced features, such as:

Benefits

File

•Quotas

•Mount points

•Defrag

•Deep UNC support

•Self-healing OS

•Installer service

•SW installation via GP

Management

•Built-in Terminal services w/ admin mode

•RIS

•Delegated administration

•WSH

•Auto-restart services

•Run As …

•Multi-video output

Networking

•Improved IP stack

•No reboot for IP changes

•QoS

Directory

•LDAP support•Delta-only replication•No primary DC•Pro/demotion of DCs

Security

•Kerberos •Smart card support•IPSec

What is the timeline?

1.    

1.     Pre-pilot work begins – early January ‘022.     Windows 2000 Infrastructure testing complete – late

February ‘023.     Begin pilot migration of users – late March ‘024.     Pilot complete – late April ‘025.     Begin ITSS user migration - late April ‘026.     First Exchange 2000 Server in Infrastructure – early May

‘027.     Finish ITSS migration – early June ‘02

8. Begin Facilities user migration – early June ‘02

    9.  Facilities migration complete – early July ‘02     

10.  Begin GSB user migration – early July ’02

11. GSB migration complete – early August ‘02

What is the timeline?

http://windows.stanford.edu E-mail: windows-feedback@lists.stanford.edu

Stanford Windows Infrastructure