08/12/97

What a tangled mess….Tackling Windows Complexity

Rob Short

Development Manager

Windows NT

Microsoft Corporation

08/12/97

What I’ll talk about

• The problem

• Hardware detection/installation issues

• Application installation

• Managing large installations

08/12/97

Today’s Situation

• Computers are being used by everyone• >100 Million installed Windows systems• Feedback indicates severe problems• Changes are unpredictable

– add/remove hardware– add/remove software

• Windows is too hard to manage– both in single and large environments

08/12/97

Hardware configuration

• Obvious: This should not be hard– most systems have less than two dozen devices– resource allocation is well defined problem

• Reality – One out of ten attempts to change hardware has

a problem of some sort– Out of 100 Million users that is 10 Million

people with a problem!!!!!!

08/12/97

Hardware related issues

• Incredible number and variety of devices– 4808 different system designs– 4000 + add in cards– 1200+ different printers

• Few hardware standards,– many devices don’t implement the whole spec– newer devices are better, but people expect

their old systems/devices to work

08/12/97

Windows NT 4.0 HCL

08/12/97

Hardware Standards(oxymoron)

• No standard basic system structures– AT compatible core in most x86 systems

• required to run DOS or WIN95

• software can, sort of, assume its there

• System buses, implementations are different– PCI, ISA, EISA, Microchannel,

• Newer standards address SW problems– PCI, 1394, USB, ACPI, etc

08/12/97

Windows Driver Model• Plug and Play and Power Management device

driver interfaces for both flavors of Windows• Supports load/unload, start and stop• Support Plug and Play hardware standards• Built on existing Windows NT input/output

(I/O) infrastructure• Separate class and port drivers

08/12/97

WDM Bus Drivers

• Standard WDM driver that exposes a bus

• “Bus” is any device (virtual or physical) on which other devices are connected

• Includes enumeration routines

• Responds to new Plug and Play and Power Management I/O request packets (IRPs)

• Extensible via filter drivers

08/12/97

SetupSetup

SpoolerSpoolerMouseMouse

kbdkbd CPLCPL

Plug and Play ManagerPlug and Play Manager

EnumerationEnumerationcontrolcontrol

HW eventHW eventmanagermanager

ApplicationsApplications

User modeUser mode

Kernel modeKernel mode

WDM Device DriversWDM Device Drivers

I/OI/OExecExec

PC CardPC CardACPIACPI PCIPCIUSBUSB

Plug and Play bus driversPlug and Play bus drivers

HWHWevent event notifynotify

EnumEnumcntrlcntrl

Windows NT 5.0Windows NT 5.0Plug And Play ArchitecturePlug And Play Architecture

Plug and Plug and Play MgrPlay Mgr

Plug Plug and Playand Play

PowerPowerManagementManagement

WDM InterfaceWDM Interface

08/12/97

Attachment (Functional Device Object, Physical Device Object)Attachment (Functional Device Object, Physical Device Object)

Parent-child relationshipParent-child relationship

Logical device instanceLogical device instance

PCI bus PDO(Plug and Play Manager)

PCI bus FDO(pci_bus.sys)

““Toaster” PDO(pci_bus.sys)

“Toaster” FDO(toaster.sys)

SCSI disk PDO(scsiport.sys)

SCSI disk FDO(disk.sys)

SCSI adapter PDO(pci_bus.sys)

SCSI adapter FDO(scsiport.sys)

SCSI CD-ROM PDO(scsiport.sys)

SCSI CD-ROM FDO(cdrom.sys)

WDM Device Tree

08/12/97

Windows Software Issues

• “State” on systems has grown out of control– Poor separation of system, application, or user

state (history of one pc, one user, few apps)– Applications put files in system directories– Shared libraries shipped with applications

• versioning nightmare

– End user has no idea what each file does• or what happens if it is deleted or replaced

08/12/97

Solutions

• Guidelines to separate the state

• Better application guidelines– ideally an app can be dropped onto the system

• Add an installation service to system– takes a “package” and installs it– tracks versions of shared components– puts application files in separate directories– tracks ownership of files– Tools needed to create packages

08/12/97

Managing large InstallationsGoals

• End user must not need to be administrator

• Automatically install or update OS and apps

• Keep SW consistent across the organization

• Policies/apps assigned to groups of users

• Support “roaming” users

• Make system replacement possible

08/12/97

Technology to make this happen

• Coda-like file system features– client-side caching– single instance store

• Directory service includes “Class Store”

• Automatic application installation

• Remote booting

• Policy based management

• Improved UI and tools

08/12/97

File/Document ManagementClient side caching

• Master copy of files live on the server

• Copy is cached on the local system

• Caching is done by network re-director

• Data is stored in file system with minimal meta-data

• Improves performance and availability of network files and installed applications

08/12/97

Connected to a Network

1: Open any file - redirected to network

2: Store copy in client side cache

5: “Pin” cached files to prevent eviction

3: Read from local client side cache

4: Write-through cache

08/12/97

Working Off-line

1: Request to open network file

2: Redirect to local cached copy

08/12/97

Reconnecting to the Network

1: Automatically copy locally modified files up to the server

2: Automatically copy server modified files to client side cache

3: When file changes collide Wizard walks user through reconciliation process

08/12/97

File/Document management (cont)

• Server provides single instance store– Asynchronous process on server– Detects duplicate files– Replaces with links to a master– Performs “copy-on-write”

• Drive letters, system files, other clutter only available in “Advanced” explorer views

08/12/97

Directory Service

• Global, replicated, easily accessed place to store things

• Class store resides in the directory– Populated automatically by administration tools– Takes a class ID and returns a path, or URL to

an application or component

08/12/97

• Administrator creates groups of users, e.g. payroll, and assigns desktop properties and apps to groups and/or individuals

• Profiles are stored in the directory

• Easy to create “locked down” systems

• End user performs no administration– OS installs and upgrades automatically

– Application installation is automatic

– Users can log on anywhere and see the exact same environment, including applications and documents

Centralized Management

08/12/97

Application Installation

• Applications appear on desktop, start menu, and in class associations at log in

• Application installation is transparent no matter how the App is invoked

• Application invocation patterned on object instantiation for legacy apps– Verify if App is installed and if the version is correct

– If version is incorrect, silent setup is performed

– App is invoked after verification

• System decides via policy if app should– be installed normally, Cached to local disk, or Run from the net

08/12/97

App Deployment ModelAssigned & Published Applications

• Assigned Applications are automatically installed– User can’t delete app from machine

• Published Applications are optional– Installed via “Add/Remove Programs”– Document invocation will auto-install too!

e.g.: click on Visio doc in email

• Apps deployed to users or machines– App pushed to machine; pulled by user

08/12/97

Office 98 CD

2: Customize installation options

1: Create a network install for app.Network Server

3: Assign application in policy

“Sales Force” Group Policy

4: User in OU “receives” policy

6: Upon user invocation, the app is installed on user’s machine

Pat

5: At User Logon, the machine receives portions of the app.

Deployment Process

08/12/97

Remote Boot

• Goals– Enable Remote Boot of Windows NT– Simplify management of server images

• Most costly problem with remote boot today

– Maintain ability to function offline– Automatic OS update & simple repair

• Solution– Remote boot solution based on caching and single instance

storage

08/12/97

Remote Boot (cont’d)

• NT maps client physical storage to “D:\”

• “C:\” is a cache -- replica lives on net– Entire contents of C:\ drive is placed on net

• i.e.: Each client has their own disk image

– Single instance storage (NTFS filter driver) eliminates storage of duplicate files

• Enable flexible configuration without drive bloat.

E.g.: older app, different driver

08/12/97

Remote Boot

• Client boots via new boot ROMs

• DHCP server hosts extensions– Dialect between OS-less client & server– Fully defined in NetPC specification

• Policy used to define client behavior

• DS accounts used for state storage

• Applet (OSChooser) sent as “bootstrap” code to offer initial choices

08/12/97

Scenario: New Machine

Directory Services

Client A Client B

Remote Boot Server

InstallServer

Policy

Machine Account

ClassStore

MachineAccount

08/12/97

Scenario: Existing Machine

Directory Services

Client A Client B

Remote Boot Server

InstallServer

?

Policy

MachineAccount

ClassStore

08/12/97

Client A

Scenario: Machine Failure

Directory Services

Client B

Remote Boot Server

InstallServer

Policy

Machine BAccount

Machine AAccount

Machine BAccount

User Selects “Replace Machine”

08/12/97

Summary

• Plug and play is non-trivial– requires significant hardware and software

• Application installation problems– Architectural improvements,– engineering discipline

• Large systems– use caching and single instance store to

eliminate end user administration

08/12/97

Questions?

?