1 / 33

What a tangled mess…. Tackling Windows Complexity

What a tangled mess…. Tackling Windows Complexity. Rob Short Development Manager Windows NT Microsoft Corporation. What I’ll talk about. The problem Hardware detection/installation issues Application installation Managing large installations. Today’s Situation.

naida-giles
Download Presentation

What a tangled mess…. Tackling Windows Complexity

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. What a tangled mess….Tackling Windows Complexity Rob Short Development Manager Windows NT Microsoft Corporation

  2. What I’ll talk about • The problem • Hardware detection/installation issues • Application installation • Managing large installations

  3. 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

  4. 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!!!!!!

  5. 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

  6. Windows NT 4.0 HCL

  7. 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

  8. 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

  9. 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

  10. Windows NT 5.0Plug And Play Architecture Mouse kbd CPL Spooler Setup Plug and Play Manager Enumeration control HW event manager Applications Enum cntrl HW event notify User mode Kernel mode Plug and Play I/O Power Management Plug and Play Mgr Exec WDM Interface Plug and Play bus drivers WDM Device Drivers ACPI PC Card USB PCI

  11. SCSI disk FDO (disk.sys) SCSI CD-ROM FDO (cdrom.sys) SCSI disk PDO (scsiport.sys) SCSI CD-ROM PDO (scsiport.sys) “Toaster” FDO (toaster.sys) SCSI adapter FDO (scsiport.sys) “Toaster” PDO (pci_bus.sys) SCSI adapter PDO (pci_bus.sys) PCI bus FDO (pci_bus.sys) PCI bus PDO (Plug and Play Manager) WDM Device Tree Attachment (Functional Device Object, Physical Device Object) Parent-child relationship Logical device instance

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. Connected to a Network 1: Open any file - redirected to network 2: Store copy in client side cache 3: Read from local client side cache 4: Write-through cache 5: “Pin” cached files to prevent eviction

  18. Working Off-line 1: Request to open network file 2: Redirect to local cached copy

  19. 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

  20. 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

  21. 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

  22. Centralized Management • 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

  23. 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

  24. 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

  25. Office 98 CD Network Server “Sales Force” Group Policy Pat Deployment Process 1: Create a network install for app. 2: Customize installation options 3: Assign application in policy 4: User in OU “receives” policy 5: At User Logon, the machine receives portions of the app. 6: Upon user invocation, the app is installed on user’s machine

  26. 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

  27. Remote Boot (cont’d) • NT maps client physical storage to “D:\” • “C:\” is a cache -- replica lives on net • Entirecontents 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

  28. 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

  29. Directory Services Install Server Remote Boot Server Client A Client B Scenario: New Machine Machine Account Machine Account Policy Class Store

  30. Directory Services Install Server Remote Boot Server Client A Client B Scenario: Existing Machine Machine Account Policy Class Store ?

  31. Directory Services Install Server Remote Boot Server Client A Client B Scenario: Machine Failure Machine A Account Machine B Account Machine B Account Policy User Selects “Replace Machine”

  32. 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

  33. Questions? ?

More Related