 |
|
| ActiveWin | Active Network | AskAW | Reviews | Interviews | FAQ's | Mailing List | Forum |
|
|
|
|
|
DirectX |
|
ActiveMac |
|
Downloads |
|
Forums |
|
Interviews |
|
News |
|
MS Games & Hardware |
|
Reviews |
|
Support Center |
|
Windows 2000 |
|
Windows Me |
|
Windows Server 2003 |
|
Windows Vista |
|
Windows XP |
|
|
|
|
|
|
|
News Centers |
|
Windows/Microsoft |
|
DVD |
|
Apple/Mac |
|
Xbox |
|
News Search |
|
|
|
|
|
|
|
ActiveXBox |
|
Xbox News |
|
Box Shots |
|
Inside The Xbox |
|
Released Titles |
|
Announced Titles |
|
Screenshots/Videos |
|
History Of The Xbox |
|
Links |
|
Forum |
|
FAQ |
|
|
|
|
|
|
|
Windows XP |
|
Introduction |
|
System Requirements |
|
Home Features |
|
Pro Features |
|
Upgrade Checklists |
|
History |
|
FAQ |
|
Links |
|
TopTechTips |
|
|
|
|
|
|
|
FAQ's |
|
Windows Vista |
|
Windows 98/98 SE |
|
Windows 2000 |
|
Windows Me |
|
Windows Server 2002 |
|
Windows "Whistler" XP |
|
Windows CE |
|
Internet Explorer 6 |
|
Internet Explorer 5 |
|
Xbox |
|
Xbox 360 |
|
DirectX |
|
DVD's |
|
|
|
|
|
|
|
TopTechTips |
|
Registry Tips |
|
Windows 95/98 |
|
Windows 2000 |
|
Internet Explorer 5 |
|
Program Tips |
|
Easter Eggs |
|
Hardware |
|
DVD |
|
|
|
|
|
|
|
ActiveDVD |
|
DVD News |
|
DVD Forum |
|
Glossary |
|
Tips |
|
Articles |
|
Reviews |
|
News Archive |
|
Links |
|
Drivers |
|
|
|
|
|
|
|
Latest Reviews |
|
Xbox/Games |
|
Fallout 3 |
|
|
|
Applications |
|
Windows Server 2008 R2 |
|
Windows 7 |
|
|
|
Hardware |
|
iPod Touch 32GB |
|
|
|
|
|
|
|
Latest Interviews |
|
Steve Ballmer |
|
Jim Allchin |
|
|
|
|
|
|
|
Site News/Info |
|
About This Site |
|
Affiliates |
|
Contact Us |
|
Default Home Page |
|
Link To Us |
|
Links |
|
News Archive |
|
Site Search |
|
Awards |
|
|
|
|
|
|
|
Credits |
Microsoft� Whistler
Beta 2 Release Notes
These notes support a preliminary release of a software program that bears the project code name Whistler.
Information in this document, including URL and other Internet Web site references, is subject to change without notice and is provided for informational purposes only. The entire risk of the use or results of the use of this document remains with the user, and Microsoft Corporation makes no warranties, either express or implied. Unless otherwise noted, the example companies, organizations, products, people and events depicted herein are fictitious and no association with any real company, organization, product, person or event is intended or should be inferred.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Whistler Beta 2 is a time-limited release and will expire 180 days after initial installation is completed. Due to the nature of pre-release software, it is not recommended for production systems, and some of your applications and hardware might not function correctly. This product does not include an uninstall feature: therefore, we recommend that you back up your data before installing this release.
� 2001 Microsoft Corporation. All rights reserved.
Microsoft, Windows� , Windows NT, Active Directory, ActiveSync, ActiveX, BizTalk, DirectShow, DirectSound, FrontPage,Hotmail, MSN, Outlook, PowerPoint, SharePoint, SideWinder, Visual Basic, Visio, Visual C++, Visual FoxPro, Visual Studio, Win32, Win64,and Windows Media are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Contents
Introduction
Change and Configuration
Clustering
Component Services
Directory Services
Hardware
Internet Services
Microsoft Management Console
Network and Communications
Postinstallation
Security
Server Management
Storage
Support
Terminal Services
Windows Update
Issues for 32-Bit Editions of Whistler Only
Issues for 64-Bit Editions of Whistler Only
Introduction
Welcome to the Beta 2 release notes for Microsoft Whistler Personal, Whistler Professional, Whistler Server, Whistler Advanced Server, Whistler Datacenter Server, Whistler Professional for Intel Itanium systems, Whistler Advanced Server for Intel Itanium systems, and Whistler Datacenter Server for Intel Itanium systems. This is a limited technical release that expires 180 days from the date of installation.
This document provides late-breaking or other information that supplements the Whistler documentation. In addition, there are several other release notes files on your Beta 2 compact disc (CD) that you should read:
- Read1st.txt (important preinstallation information, located in the Whistler CD root directory)
- Setup text files (located in the \Setuptxt folder on your Whistler CD)
- Readme Notes (compatibility and postinstallation notes, located on the Whistler desktop)
- Featguid.doc (what's new in this release, located in the Whistler CD root directory)
Change and Configuration
Action List
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, in administrative template (.adm)files that use an action list in policy settings, these policy settings are not reported correctly in Resultant Set of Policy (RSoP). The associated registry keys that appear in RSoP under Extra Registry Settings should not be present. This issue will be addressed in a future release.
The following list includes the policy settings in the System.adm file that use action lists.
- Computer Configuration\Administrative Templates\System\Error Reporting\Display Error Notification
- Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Sessions\Set Time Limit For Disconnected Sessions
- Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Do Not Allow New Client Connections
- User Configuration\Administrative Templates\Windows Components\Terminal Services\Sessions\Set Time Limit For Disconnected Sessions
Applies to users: administrators
Cross-Forest Scenarios Using Group Policy Are Not Fully Supported
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, cross-linking Group Policy objects across forests is not supported. Some administration and delegation tasks are supported. This issue will be addressed in a future release.
Applies to users: administrators
Deleting a WMI Filter Associated with a Group Policy Object
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, you can associate a Windows Management Instrumentation (WMI) filter with aGroup Policy object (GPO) in Active Directory� directory service. If you associate a WMI filter with a GPO and then delete the WMI filter, the association between the WMI filter and the GPO still exists. This issue will be addressed in a future release.
Applies to users: administrators
Editing Group Policy Objects in a Windows 2000 Domain
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, if you use the Whistler client toedit aGroup Policy object (GPO) in Windows 2000 Active Directory, the System.adm file located on the Whistler client is copied into the Group Policy object that is being edited. This new System.adm file contains all of the previous Windows 2000 policy settings and the 170 new settings available in Whistler. Therefore, these new settings appear when a Whistler or Windows 2000 client tries to edit theseGroup Policy objects that contain this updated System.adm file.
Administrators need to remember that:
- All of the old settings function on Windows 2000 and also on Whistler clients.
- All of the new settings that appear only affect Whistler clients and have no effect if applied to Windows 2000 clients.
To avoid confusion, in a mixed computing environment (such as Whistler and Windows 2000 clients), you should only editGroup Policy objects using a Whistler client. Whistler clients have an updated version of Group Policy that identifies the operating systems supported by a policy in the Group Policy snap-in. This issue will not be addressed in a future release.
Note
If a Windows 2000 client contains a more recent version of an .adm file in a Group Policy object that is being modified, this more recent version is always copied into the Group Policy object.
Applies to users: administrators
Folder Redirection
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, if you select the newRedirect to the user's home directory option for folder redirection, the user's My Documents folder, which is redirected to the home directory, will not be redirected to the new path. This applies when the user's home directory path is changed. The result is that the user's My Documents folder view and the view of their home directory will be inconsistent until folder redirection policy changes and a foreground refresh of policy occurs while logging on. To work around this issue, edit a folder redirection setting in a Group Policy object that applies to this user (this can be done simply by toggling any one of the folder redirection check boxes). This will result in a policy refresh and folder redirection will move the user's documents correctly and update the My Documents path the next time the user logs on. This issue will be addressed in a future release.
Applies to users: administrators
Internet Explorer Maintenance and Resultant Set of Policy
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, Internet Explorer Maintenance displays a message when Resultant Set of Policy (RSoP), in logging mode, successfully reports the RSoP data. This issue will be addressed in a future release.
Applies to users: administrators
Public Key Policies Settings
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, Public Key Policies settings write data to registry keys. The data remains in the registry keys even if these policies are later removed.
Applies to users: administrators
Refreshing Group Policy
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, to force a refresh of Group Policy for either the user or the computer, use the new command line tool GPUpdate.exe. The RefrGp.exe tool used in Whistler Beta 1 is no longer available. Secedit.exe also cannot refresh all of Group Policy as it did in Windows 2000, but can still be used to refresh security policies. This issue will not be addressed in a future release.
Applies to users: administrators
Resultant Set of Policy
The following issues apply to Resultant Set of Policy (RSoP).
- On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, due to a change in schema between Whistler Beta 1 and Whistler Beta 2, you might experience problems while remotely retrieving all the RSoP information from a computer running Whistler Beta 1 when using a computer running Whistler Beta 2 to view the data. This issue will not be addressed in a future release.
- On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, Resultant Set of Policy offers three views for applications, one of which is Removed Applications. If you click Removed Applications and then right-click Removed Applications, the Package Properties dialog box appears. On the Cause tab, text that lists reasons for the removal of an application (for example, Removed by user via Add or Remove Programs) appears. Some of these reasons might be disjointed or unclear. This issue will be addressed in a future release.
Applies to users: administrators
Resultant Set of Policy in Planning Mode
Different Domains
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, if you use Resultant Set of Policy (RSoP) in planning mode to analyze a user in a domain different from the domain you are in, RSoP does not function correctly. To work around this issue, select a Whistler domain controller in the user's domain to perform the simulation. This issue will be addressed in a future release.
Applies to users: administrators
Logon Server
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, the Resultant Set of Policy Wizard uses your logon server by default to perform the RSoP planning mode simulation. In a mixed computing environment where both Windows 2000 and Whistler domain controllers exist, if your logon server is a Windows 2000 domain controller, the RSoP data is not generated and the simulations do not function correctly. To work around this issue, always ensure that you select a Whistler domain controller during the RSoP installation. This issue will be addressed in a future release.
Applies to users: administrators
Roaming User Profiles with NetWare
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, users cannot gain access to roaming user profiles located on Novell NetWare, or other non-Server Message Block (SMB) shares. Users with profiles stored on non-SMB shares will see the following message when logging on:
"Windows cannot locate the server copy of your roaming profile and is attempting to log you on with your local profile. Changes to the profile will not be copied to the server when you logoff. Possible causes of this error include network problems or insufficient security rights. If this problem persists, contact your network administrator. DETAIL - The network path was not found."
If the user previously logged onto this computer, Whistler loads the user�s locally cached profile. Users who have never logged on are issued a temporary profile. To work around this issue, relocate the user's profile to an SMB based-share and update the users' profile path in their user object. This issue will be addressed in a future release.
Applies to users: administrators
Setting System Access Control Lists on WMI Filters
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, you cannot change the system access control lists (SACLs) on WMI filters stored in Active Directory. The default SACLs on these objects allow only domain administrators to add or remove WMI filters from Active Directory.
Note
All authenticated users can only gain access to read WMI filters. Therefore, any user who has permission to create or modify a Group Policy object also has permission to link WMI filters to a Group Policy object.
This issue will be addressed in a future release.
Applies to users: administrators
Software Distribution Using Group Policy
Applies to users: administrators
Clustering
Applications
Failover of Individual Sites in Internet Information Services 6.0
Failover of individual sites is not supported in Internet Information Services (IIS) 6.0. This might affect customers who deploy earlier versions of Windows NT� 4.0. To upgrade to IIS 6.0, follow the Setup instructions. Windows Clustering support for the entire IIS 6.0 service will be addressed in a future release.
Applies to users: administrators, developers, original equipment manufacturers (OEMs)
Services for Macintosh
On computers running Whistler Advanced Server and Whistler Datacenter Server, Services for Macintosh (SFM) is not supported on a server cluster and might result in data loss. This is a result of the current implementation of Services for Macintosh, not the Cluster service.
For more information about Services for Macintosh, see article Q243839, "Services for Macintosh Not Supported in a Cluster Environment" in the Microsoft Knowledge Base.To find this article, see the Microsoft Knowledge Base link on the Web Resources page at:
http://www.microsoft.com/windows/reskits/webresources/
Applies to users: administrators, developers, OEMs
Applies to scenarios: improving technology
Terminal Server
On computers running Whistler Advanced Server or Whistler Datacenter Server, Terminal Server (also known as Terminal Services in application server mode) is no longer blocked on a server cluster. In Windows 2000, Terminal Server installation was blocked on a server cluster. Although Terminal Server can be deployed on a cluster (it can co-exist with Windows Clustering on a server), it does not fail over.
Applies to users: administrators, developers, OEMs
Cluster Setup
Domain Name System Name Registration
and Replication
On computers running Whistler Advanced Server or Whistler Datacenter Server, if you have multipleDomain Name System (DNS) servers, there might be delays in DNS Name Registration and Replication. This might cause Cluster Node Join to function incorrectly.
The following scenario is a known issue. Assume that you have DNS 1 and DNS 2 and both are domain controller integrated (and have latency in replicating changes). Node 1 forms a cluster and the cluster name is registered at DNS 1. Node 2 cannot join and verify the cluster name at DNS 2 unless DNS 1 replicated its changes to DNS 2. To work around thisissue, wait for replication to occur or manually perform the DNS replication.
Applies to users: administrators, OEMs
Fully Qualified Domain Name
The Whistler Setup Wizard generates a message if a fully qualified domain name (FQDN) is entered for the computer name for computers running Whistler Advanced Server or Whistler Datacenter Server. If an FQDN is entered as the computer name when either forming or joining a cluster, the Setup Wizard generates a message stating that the name does not comply with DNS specifications. This issue will be addressed in a future release.
Applies to users: administrators, OEMs
IP Address
If the incorrect IP address is entered during cluster setup on computers running Whistler Advanced Server or Whistler Datacenter Server, the cluster forms but the cluster IP resource is incorrectly labeled as "failed."
Applies to users: administrators, OEMs
Evicting a Node from a Cluster
On computers running Whistler Advanced Server or Whistler Datacenter Server, if you change the Cluster service account used to start Cluster service, you might not be able to evict a node from the cluster. It might display the following message: "Not enough storage is available to complete the operation." The Cluster service account must be a domain-level account that is a member of the local Administrators group.
To reproduce this issue
cluster.exe node /force
For application programming interface (API) calls, the format of the account must beDomain/User. The message appears because the local account is inUser format.
To work around this issue, change the account used to start Cluster service to a domain-level account with local Administrators rights. This issue will be addressed in a future release. For more information about recreating the Cluster service account, see article Q269229, "How to Manually Re-Create the Cluster Service Account" in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the Web Resources page at:
http://www.microsoft.com/windows/reskits/webresources/
Applies to users: administrators, OEMs
Fibre Channel Configurations
If you are running a cluster on Whistler Advanced Server or Whistler Datacenter Server configured with QLogic QLA2200 Fibre Channel adapter with driver version 7.4.8.0�8.0.0.3 through a Fibre Channel fabric Switch, you might encounter one of the issues.
- The message "error 170, unable to reserve PhysicalDiskx" appears, where x is the number of the physical drive, or
- You lose connectivity to the disks, and then the cluster.log message "SCSI:Unable to attach to disk signature 0xsssssssss, error 2" might appear in the cluster.log file on the node.
To work around this issue, use the QLogic software to update the following QLogic BIOS settings to the following values on all cluster nodes:
- Enable LIP Reset = No
- Enable LIP Full Login = No
- Enable Target Reset = Yes
Applies to users: administrators, OEMs
Applies to scenarios: improving technology
Forming or Joining a Cluster
Cluster Service Account in DNS Format
On computers running Whistler Advanced Server or Whistler Datacenter Server, you might be unable to join a node to a cluster if the Cluster service account was specified in the following Domain Name System (DNS) formatUser@domain.com instead of the NetBIOSDomain/User format.
To reproduce this issue
- user: Name@company.com
- password: Enter your password
- domain: Name@company.com
- When you attempt to type the password, a message appears stating that the domain is not valid.
- Log on to the cluster server.
- Start Cluster Administrator and connect to an existing cluster.
- On the File menu, click New, and then click Node.
- Select the local computer.
To work around this issue, change the Cluster service account from the DNS naming format to the NetBIOS naming format. This issue will be addressed in a future release. For more information about recreating a Cluster service account,see article Q269229, "How to Manually Re-Create the Cluster Service Account" in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the Web Resources page at:
http://www.microsoft.com/windows/reskits/webresources/
Applies to users: administrators, OEMs
Logging on Locally to the Cluster Server
If you attempt to join a node to a cluster while you are logged on locally to a cluster server running Whistler Advanced Server or Whistler Datacenter Server, you might receive an "Access Denied" message. This occurs even if you are logged on with a local account that has administrative rights.
To join a node to a cluster
The Cluster Administrator does not provide a prompt for credentials when you are trying to create a cluster with insufficient privileges, which results in this message appearing.
To work around this issue, log on to the local node with a domain-level account that is a member of the local Administrators group. Add the node to the cluster again. This issue will be addressed in a future release.
Applies to users: administrators, OEMs
Installation of Cluster Resources
DHCP/WINS Resources
On computers running Whistler Advanced Server or Whistler Datacenter Server, Dynamic Host Configuration Protocol (DHCP) cluster resource or Windows Internet Name Service (WINS) cluster resource might not start or install because DHCP or WINS:
- Cannot start if the service has already started, or
- Cannot be installed if an instance of the resource already exists.
Only one instance of a DHCP resource and WINS resource is allowed per cluster. If the cluster resource has already been installed or started, you cannot install or start another instance of the resource. To work around this issue, delete the DHCP or WINS resource, and then recreate the resource. This issue will be addressed in a future release.
Applies to users:administrators
NNTP/SMTP
Network News Transfer Protocol (NNTP) and Simple Mail Transfer Protocol (SMTP) no longer provide cluster dynamic-link libraries (DLLs) in Whistler Advanced Server or Whistler Datacenter Server. This issue will not be addressed in a future release.
Applies to users: administrators, developers, OEMs
Applies to scenarios: improving technology
Network Load Balancing
Adding a Host from a Network Load Balancing Cluster
If you add a host to the Network Load Balancing cluster using Network Load Balancing Manager, you will not be able to immediately remove the new host from the cluster. This happens because the icon for the new host is displayed in Network Load Balancing Manager before Windows Management Instrumentation (WMI) has finished binding Network Load Balancing on the host and adding the cluster IP address to the host. To work around this issue, wait a few minutes before removing the host from the cluster. This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience
Changing Cluster Parameters Using Network Load Balancing Manager
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, the following three-step scenario results in an issue with Network Load Balancing.
Network Load Balancing Scenario
Network Load Balancing Manager does not update the host that was removed from the cluster. If the usermanually adds this host back to the cluster, the host will have settings that are inconsistent with the rest of the cluster, potentially causing the cluster to exist in a converging state.
To work around this issue, the user should turn off Network Load Balancing on this host when it is added back to the cluster and ensure that the cluster IP address is removed from this host. Then, the user should use Network Load Balancing Manager to add this host to the cluster so Network Load Balancing Manager can propagate the correct new settings to this newly added host. This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience
Creating a New Cluster
On computers running Whistler Server, Whistler Advanced Server, Whistler Datacenter Server, when a new cluster is created using Network Load Balancing Manager, Network Load Balancing Manager does not check to see if this cluster already exists on the network. The responsibility of creating a new cluster that is unique rests with the user. If two clusters are created using the same Cluster IP address, this could result in IP address conflicts and router disruption. This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience
Full Internet Name
On computers running Whistler Server, Whistler Advanced Server, and Whistler Datacenter Server, when Network Load Balancing Manager is used to connect to an existing pre-configured Network Load Balancing cluster, it assumes that the cluster has been correctly configured. This means that the entries in theFull Internet Name box in Network Load Balancing Manager on each host must be the same. However, if different Full Internet Names have been entered in the Network Load Balancing hosts, the cluster still converges and is functional. However, Network Load Balancing Manager displays the Full Internet Name that exists on the host to which it connected in order to get the cluster parameters. This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience
Internet Group Membership Protocol
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, Whistler Datacenter Server, when Network Load Balancing Manager connects to an existing Network Load Balancing cluster that has Internet Group Membership Protocol (IGMP) support turned on, Network Load Balancing Manager does not show that IGMP is functioning. To work around this issue, you should manually turn on IGMP. This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience
IP Address Conflict
On computers running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, there is an issue with the IP address when you are using Network Load Balancing Manager.
To reproduce this issue
This procedure is equivalent to moving Host H with NIC #1 from Cluster A to Cluster B. However, this might cause an IP address conflict.
To work around this issue
This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience
Managing a Network Load Balancing Cluster
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, if you simultaneously manage a Network Load Balancing cluster from separate computers running separate copies of Network Load Balancing Manager, this might result in inconsistencies in the cluster state. This can potentially hamper the Network Load Balancing functionality of that cluster.
Applies to users: administrators
Applies to scenarios: improving user experience
Modifying Cluster Parameters
On computers running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, after a user has finished creating a Network Load Balancing cluster by using Network Load Balancing Manager, the user is not able to modify any cluster parameters by using Network Load Balancing Manager. TheCluster Parameterstab is unavailable. To work around this issue, make any changes to the cluster parameters by using theLocal Area Connection Properties dialog box. The user can still modify host specific properties on each host by using Network Load Balancing Manager. This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience
Multicast Mode with IGMP
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, when Network Load Balancing Manager is used to add a new host to an existing Network Load Balancing cluster configured in multicast mode with IGMP turned on, the new host does not turn on IGMP automatically. To work around this issue, the user must turn on IGMP manually by using Network Load Balancing Manager or the Network Load Balancing user interface on the host. This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience
Network Configuration User Interface
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, if the Network Configuration user interface (used to configure TCP/IP) on a host is open, Network Load Balancing Manager cannot connect to that host remotely using Windows Management Instrumentation in order to configure Network Load Balancing on the host. To work around this issue, close the Network Configuration user interface. This issue will not be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience
Network Load Balancing Cluster Host
Port Rules
On computers running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, the following scenario causes an issue with port rules.
Network Load Balancing Manager connects to one host in the cluster and incorrectly identifies that the remaining hosts in the cluster have the same set of port rules as that host. Network Load Balancing Manager incorrectly identifies that it is connecting to a correctly configured cluster and so displays the port rules of the host it is connected to as the port rules for the entire cluster. The user tries to use Network Load Balancing Manager to manage an existing incorrectly configured Network Load Balancing cluster having hosts with mismatched port rules.
To work around this issue, users should ensure that when using Network Load Balancing Manager to connect to an existing operational Network Load Balancing cluster, the cluster is correctly configured. To determine this, run the Wlbs.exe query command at the command prompt.
Applies to users: administrators
Applies to scenarios: improving user experience
Unicast Mode
On computers running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, Network Load Balancing Manager should not be run on a Network Load Balancing cluster host when the cluster is configured in unicast mode and each host only has a single network interface card (NIC) in it. This is because in this mode there is no intra-host communication possible and so Network Load Balancing Manager will not be able to set Network Load Balancing parameters on hosts other than the one it is running on.
To work around this issue, run Network Load Balancing Manager on a computer that is not a Network Load Balancing cluster host and remotely manage the cluster. This issue will not be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience
Network Load Balancing Installation
On computers running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, Network Load Balancing is supported, but not installed by default. To work around this issue, install Network Load Balancing manually.
Applies to scenarios: improving technology
Refreshing Network Load Balancing Manager
On computers running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, there is no way to refresh the view in Network Load Balancing Manager. If a configuration parameter on a host is changed outside of Network Load Balancing Manager, Network Load Balancing Manager does not recognize this change. To work around this issue, the user must make this change in the Network Load Balancing Manager manually. This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience
Removing a Host from a Network Load Balancing Cluster
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, if the user removes a host from a Network Load Balancing cluster using Network Load Balancing Manager and then immediately adds the host back using Network Load Balancing Manager, then Network Load Balancing Manager might stop responding.
To work around this issue, the user should allow a few minutes to pass before adding the host back. This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience
Saving Cluster Settings
On computers running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, Network Load Balancing Manager does not have an option to save cluster settings to a file. If the user closes Network Load Balancing Manager, all existing settings are lost. To work around this issue, restart Network Load Balancing Manager and reconnect to existing clusters to populate Network Load Balancing Manager with cluster information. This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience
Single-Host Port Rules
On computers running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, Network Load Balancing Manager cannot configure single-host port rules in a Network Load Balancing cluster. To work around this issue, configure the single-host port rules by using the Network Load Balancing user interface in the Local Area Connection Properties dialog box. This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience
Uninstalling and Reinstalling Network Load Balancing
On computers running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, if the user uninstalls Network Load Balancing and then reinstalls it without restarting the computer, then even if the user configures Network Load Balancing, Network Load Balancing does not function correctly. To work around this issue, restart the computer while Network Load Balancing is still uninstalled. Turn on the computer, reinstall Network Load Balancing, and then configure it. This issue will be addressed in a future release.
Applies to scenarios: improving technology
Virtual Private Network Servers
On computers running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, when virtual private network (VPN) servers usingPoint-to-Point Tunneling Protocol(PPTP) are clustered using Network Load Balancing in multicast mode, sometimes client VPN calls are dropped. In this scenario, users should use unicast mode instead.
Applies to scenarios: improving technology
Windows NT Load Balancing Service
When a computer running Windows NT Server 4.0 or Windows NT 4.0, Enterprise Edition with Windows NT Load Balancing Service (WLBS) installed is upgraded to Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, then Network Load Balancing (NLB) might appear as either bound but not configured or as not installed at all.
To work around this issue, before upgrading a computer running Windows NT Server 4.0 with WLBS installed to Whistler, first remove the virtual IP address from TCP/IP, and then upgrade the computer to avoid an IP address conflict after the upgrade is done. Once the upgrade is completed, install NLB (if uninstalled) and re-configure it. This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving technology
WMI Provider for Windows Clustering
Windows Management Instrumentation (WMI) Provider for Windows Clustering is not supported in Whistler Advanced Server Beta 2 or Whistler Datacenter Server Beta 2. This issue will be addressed in a future release.
Applies to users: administrators, developers, OEMs
Applies to scenarios: improving technology
Component Services
COM+ Administration
Administering Windows 2000 Computers
On computers running Whistler Professional or Whistler Advanced Server, you cannot administer Windows 2000 COM+ from the Component Services administrative tool. This issue will be addressed in a future release.
Applies to users: administrators
COM Security
To clarify the current documentation for the EOAC_MAKE_FULLSIC constant (which is described under the EOLE_AUTHENTICATION_CAPABILITIES enumeration), COM servers might specify this flag in a CoInitializeSecurity call to cause COM to send the fullsic form of the SChannel principal name to the client during security negotiation. The principal name is extracted from the server certificate. If the EOAC_MAKE_FULLSIC flag is not specified, COM sends the msstd form of the principal name. This issue applies to all versions of Whistler operating systems.
Applies to users: administrators, developers
COM+ Applications
In releases prior to Windows 2000, the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Transaction Server\
Local Computer\My Computer
specified which Oracle client libraries should be used by COM+ to communicate with Oracle. On computers running Whistler Professional or Whistler Advanced Server, the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\MTxOCI
specifies which Oracle client libraries should be used by COM+ to communicate with Oracle. For more information, see the Microsoft Product Support Services Web site at:
http://search.support.microsoft.com/
Caution Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.
Applies to users: administrators
Component Services (Formerly Known as COM+) Partitions
On computers running Whistler Professional or Whistler Advanced Server, the following issues apply to Component Services partitions.
Administration in Whistler Personal and Whistler Professional
You can create COM+ application partitions on computers running Whistler Server, but not on computers running Whistler Personal or Professional. However, you can remotely administer COM+ application partitions on a computer running Whistler Server from a computer running Whistler Personal or Professional.
Applies to users: administrators
Administration of Base Application Partition
To administer programs in the base program partition, you must be a global administrator.
Applies to users: administrators
Administration of Program Roles
An administrator of any partition can modify roles and role memberships of any program in any partition. The only exception is the role memberships on the system program.
Applies to users: administrators
Installation of Long Application Names
You cannot install a COM+ application with a name longer than 12 characters into any COM+ application partition other than a base application partition. This issue will be addressed in a future release.
Applies to users: administrators
Reader Access for All Partitions
If users are given reader access to any partition, then they have reader access to all partitions. Also, an administrator of any partition has reader access to all partitions.
Applies to users: administrators
Microsoft Visual Basic� Debugging
The debugging of Visual Basic (VB) programs that are in a partition other than the base application partition is not supported at this time. To work around this issue, for VB program development, debug and test the program in the base application partition. After development is complete, move the program to another partition.
Applies to: administrators, developers
Exporting COM+ Applications
When a COM+ application export fails, the following message appears:
"Error occurred writing to the application file."
This can occur if the same type library is registered with two
different paths under the HKEY_CLASSES_ROOT\TypeLib key and the HKEY_CLASSES_ROOT\CLSID\
{}\TypeLib key. An example of this is short file name versus long file
name or different capitalization in the paths. This should not affect
components generated by Visual Basic. To work around this issue, either
write the same path to both the type library and the class registration
key by changing the component's self-registration code or manually modify
one of the registry keys by using Regedit.exe before exporting the
application.
Caution Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.
Applies to users: administrators
Enabling Message Queuing on a Domain Controller
On computers running Whistler Professional or Whistler Advanced Server, Message Queuing Server running on a Whistler domain controller provides support for a Message Queuing dependent client.
To set up a Message Queuing Server on a Whistler domain controller
Applies to users: administrators, developers
Applies to scenarios: improving technology
Enterprise Deployment
On computers running Whistler Professional and Whistler Advanced Server, Message Queuing has multiple forest limitations. For example, if a user in Forest A logs on to a computer in Forest B, the user is required to specify the Directory Services server to install Message Queuing. All queries for queues issued by this user do not work correctly.
Applies to users: administrators, developers
Applies to scenarios: improving technology
"Failed to Install Message Queuing" Message
If you are installing Whistler Professional or Whistler Advanced Server on a computer, when Message Queuing is selected during Whistler setup, you might see this message when you selectMessage Queuing in the Configure Your Server Wizard for the second time. Message Queuing installation is not affected. This will be addressed in the next release.
Applies to users: administrators, developers
Applies to scenarios: improving technology
Internet Messaging
On computers running Whistler Professional or Whistler Advanced Server, Message Queuing supports sending messages to queues on the Internet and an intranet by introducing the following URL-style format name:
DIRECT=HTTP://sitename/msmq/queuename
Note the mandatory msmq component in the name. For Message Queuing to support Internet and intranet messaging using the URL-style of queue naming, the Message QueuingHTTP Support subcomponentmust be installed and correctly configured.
This Message Queuing subcomponent installs Internet Information Services (IIS) and creates an IIS extension for Message Queuing, called MSMQ, during Setup. In this Beta 2 release, the SOAP_ENVELOPE and the COMPOUND_MESSAGE properties are not available for messages sent to local queues and the maximum size of a message sent using the new DIRECT=HTTP format name is limited to 2 MB. This issue will be addressed in a future release.
Applies to users: administrators, developers
Applies to scenarios: improving technology
Internetwork Packet Exchange Network Protocol
On computers running Whistler Professional or Whistler Advanced Server, Message Queuing does not support the Internetwork Packet eXchange (IPX) network protocol.
Applies to users: administrators, developers
Applies to scenarios: improving technology
Message Queuing Multicast
The following issues apply to computers running Whistler Professional or Whistler Advanced Server.
- Message Queuing is designed to support message delivery to Internet Protocol (IP) multicast groups using the Pragmatic General Multicast IP multicast protocol. In this Beta 2 release, messages sent to multicast addresses while the sending computer is off-line are lost. This issue will be addressed in a future release.
- When the multicast address for a public queue is sent from a computer other than the one hosting the queue, the queue might not start accepting the messages until after a sufficient delay for Active Directory replication (commonly about 15 minutes).
Applies to users: administrators, developers
Applies to scenarios: improving technology
Message Queuing on Server Clusters
On computers running Whistler Professional Beta 2 or Whistler Advanced Server Beta 2, the Message Queuing service is not supported on server clusters. This will be addressed in future release.
Applies to users: administrators, developers
Applies to scenarios: improving technology
Message Queuing Support for Earlier Versions
On computers configured as a dependent client running Whistler Professional or Whistler Advanced Server, Message Queuing does not support the new functionality in Whistler. Message Queuing functions with clients in MSMQ 1.0 and 2.0 domains where the Microsoft Message Queue Server is installed on a domain controller to provide directory service functionality. Message Queuing supports upgrades from previous versions of MSMQ independent clients, dependent clients, and routing servers.
Clients using earlier versions as well as a Beta 2 Message Queuing dependent-client can access Active Directory using the new Message Queuing directory service, called Downlevel Client Support. This service is only required for the mentioned functionality and can be safely stopped if not needed without affecting other Message Queuing functionality.
Applies to users: administrators, developers
Applies to scenarios: improving technology
Migration of MSMQ 1.0 and 2.0
The migration of MSMQ 1.0 and 2.0 enterprise deployments tocomputers running Whistler Professional Beta 2 or Whistler Advanced Server Beta 2 is not supported. This will be addressed in a future release.
Applies to users: administrators, developers
Applies to scenarios: improving technology
Multiple Queue Format
The Message Queuing COM object model does not support multiple-element format name addressing through the MSMQQueueInfo.FormatName property. To utilize multiple-element format name addressing, use the new object MSMQDestination introduced in Whistler. To work around this issue, set MSMQDestination.FormatName to a multiple-element format name and pass the object to MSMQMessage.Send. You can optionally call MSMQDestination.Open before passing it to MSMQMessage.Send.
Applies to users: administrators, developers
Applies to scenarios: improving technology
Queue Aliases
Message Queuing introduces a new Active Directory object called a queue alias (CN=MSMQ-Custom-Recipient) that has a single Message Queuing queue format name attribute (MSMQ-RecipientFormatName). This object can act as a reference to any Message Queuing queue. This is particularly useful in allowing private queues and URL-named queues to be elements of a Message Queuing distribution list object.
Applies to users: administrators, developers
Applies to scenarios: improving technology
Sending Messages to Multiple Destinations
Message Queuing also supports sending messages to distribution lists (DL) hosted in Active Directory as objects in the group class. Usage and format are similar to that of Public Queues: DL=GUID.
Creating and managing a distribution group object in Active Directory is done by using the Active Directory Service Interfaces (ADSI) API or by using Active Directory Microsoft Management Console (MMC) snap-ins. Messages can also be sent to multiple destinations by constructing a quotation-mark-enclosed list of comma-delimited destinations in various formats, called a multiple-element format name, for the destination parameter when sending a message.
For example, a multiple-element format name containing a direct format name, a public format name, and a distribution list format name has the following form:
"DIRECT=OS:Computer\Queue,PUBLIC=GUID,DL=GUID"
Applies to users: administrators, developers
Applies to scenarios: improving technology
Microsoft Distributed Transaction Coordinator
The following issues apply to Microsoft Distributed Transaction Coordinator (MS DTC).
Applies to users: administrators
Client Access
On computers running Cluster services on Whistler Professional or Whistler Advanced Server, if MS DTC clients select the Use network name option in Cluster service for the client cluster resources, they might not be able to connect to MS DTC. To work around this issue, select the Network Client Access option.
Applies to users: administrators
Cluster Upgrades
On computers running Whistler Professional or Whistler Advanced Server, MS DTC does not support rolling upgrades on the Cluster services clusters.
To work around this issue
Applies to users: administrators
Component Services Administrative Tool
On computers running Whistler Professional or Whistler Advanced Server, if you use an inactive node of a cluster, the Component Services administrative tool might not connect to the shared MS DTC instance. To work around this issue, select the Network Clients option in the MS DTC security configuration, and restart the node. This ensures that the system program is restarted.
Applies to users: administrators
Configuring MS DTC
On computers running Whistler Professional or Whistler Advanced Server, administrators cannot access the MS DTC property sheet by clicking Properties on the specific computers in the Component Services administrative tool. To work around this issue, administrators can configure MS DTC by clicking Configure Microsoft DTC. This issue will be addressed in a future release.
Applies to users: administrators
Domain Controllers
MS DTC does not support Microsoft Cluster Service clusters with a subset of member nodes that are domain controllers on computers running Whistler Professional or Whistler Advanced Server. Either all nodes in the cluster must be domain controllers or none of the nodes can be domain controllers.
Applies to users: administrators
MS DTC on Clusters
On computers running Whistler Professional or Whistler Advanced Server, if you have a single-node cluster and the MS DTC log is on the local quorum disk, the MS DTC resource might not come online.
To work around this issue
Or, delete the log file in the winnt\System32\MsDTC\Msdtc.log folder.
Applies to users: administrators
Security Enhancements
On computers running Whistler Professional or Whistler Advanced Server, by using MS DTC you can turn off certain features such as Transaction Internet Protocol (TIP), Extended Architecture (XA), Network Transactions, Network Administration, and Network Clients. This minimizes the security risks involved with running unused features that open network ports or load user DLLs. In addition, MS DTC was also modified from running under the LocalSystem account to running under the lower privileged Network Service account. This change lessens the potential for damage to the system if there is a security problem. By default, TIP, Network Administration and Network Clients are turned off on all installations. In addition, on domain controllers, XA and Network Transactions are also turned off. These features are important because the administrator needs to enable features before existing client software is supported.
Applies to users: administrators
Directory Services
Active Directory Domains and Trusts
To check the status of a trust
- At the command prompt, type
nltest /sc_query:domain
Or, you can verify the trust from Windows 2000. Trusts from Window 2000 to Whistler verify correctly. This issue will be addressed in a future release.
Applies to users: administrators
Active Directory Domains and Trusts Snap-in
On computers running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, to convert a one-way forest trust to a two-way forest trust, first delete the existing one-way trust and then create the new two-way trust. If you use the New Trust Wizard to convert a one-way forest trust to a two-way forest trust without deleting the existing trust first, it creates an external trust instead. This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience, improving technology
Adding Whistler Domain Controllers to Windows 2000 Domains
In Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, the default security descriptors of various objects are adjusted to strengthen Active Directory security. By default, domain controllers that are upgraded from Windows 2000 to Whistler do not receive these security enhancements, and the security descriptors of existing objects are not changed.
A script is supplied with Whistler to add these enhancements to existing domains and the forest. You MUST run this script if you wish to retain compatibility with services running on Windows 2000 or earlier systems. If you do not run this script, services on Windows 2000 or earlier systems that read data from the directory, such as Remote Access and Terminal Server, might fail to authenticate properly. This script must be run immediately after introducing the first Whistler domain controller into an existing Windows 2000 domain.
Note that a Whistler domain controller can be added to an existing forest by upgrading a Windows 2000 domain controller to Whistler or by promoting a Whistler server to the domain controller role. The script is located in the \support\tools\UpgradeACL folder. For details about the changes the script makes and directions for running the script, see the UpgradeACLReadme.txt file in the \support\tools\UpgradeACL folder. This issue will be addressed in a future release.
Applies to users: administrators
Create Replica From Media
On computers running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, when using Create Replica From Media to promote a replica domain controller, you should restore a backup copy of the system state data of an existing domain controller.
A user can restore a System State backup to an alternate location by using Ntbackup.exe. An alternate location is a user-specified folder where the data will be restored with its original directory structure in place. These restored backup files must be present on a local drive of the computer that will be promoted using Create Replica From Media.
Due to an issue in Beta 2 with restoring large system state files, it is not possible to restore an Active Directory backup that is over 40 GB in size to a mapped drive on a remote computer. To work around this issue, copy the backup file to the computer to be promoted and restore it locally on that computer. If the backup is on tape, either restore it directly to the computer to be promoted or restore it to a different computer and copy it to the computer to be promoted. This issue will be addressed in a future release.
Applies to users: administrators
Domain Controller Naming
A change in the domain controller computer name might cause failure to bind to any domain controller in the same domain. Change in the global catalog computer name might cause failure to bind to any domain controller in the same forest. The type of workaround that you choose depends on whether a domain controller exists in the same site where the renamed domain controller resides.
To work around this issue if a domain controller exists
HKEY_LOCAL_MACHINE/SYSTEM/CCS/Services/Netlogon/Parameters
to the value greater than that used by other domain controllers in the domain (or, if the renamed domain controller is a global catalog, then also greater than that used by other global catalogs in the forest). If the value is not specified on some domain controllers or global catalogs or both, then they register SRV records using the default value of Priority = 0.
HKEY_LOCAL_MACHINE/SYSTEM/CCS/Services/Netlogon/Parameters
to the previous value. If the previous value was not specified, then delete the value from the registry.
Caution Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.
To work around this issue if no domain controller exists
net pause netlogon
net continue netlogon
Caution While Netlogon is paused, the domain controller is not discoverable by other devices as the domain controller for the domain. It also does not pass through the NTLM authentication requests directed to other domains.
This issue will be addressed in a future release.
Applies to users: administrators
Domain Name System Server
On computers running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, a Domain Name System (DNS) server configured with a stub zone fails to resolve iterative DNS queries for the names within this stub zone. In such a scenario, the server responds with SERVER_FAILURE. The DNS server usually receives an iterative query only from other DNS servers performing recursive resolution on behalf of its clients. A DNS server usually receives an iterative query for some name only if it is authoritative for the zone containing this name or if it is authoritative for the original and progeny of the authoritative zone. To work around this issue, do not create stub zones on the DNS servers authoritative for the original and progeny zones of the stub zone. This issue will be addressed in a future release.
Applies to users: administrators
Interoperability Between Whistler Beta 1 and Beta 2 Domain Controllers
If you add Whistler Server or Whistler Advanced Server Beta 2 domain controllers to a forest with Whistler Beta 1 domain controllers, this might result in the loss of data. Whistler Beta 2 domain controllers cannot coexist in the same forest as Whistler Beta 1 domain controllers.
Note
Whistler Beta 2 domain controllers can be added to a forest by binary upgrading an existing Windows 2000 domain controller or by promoting a Whistler server to a new replica, new child domain, or new tree.To work around this issue, demote all Whistler Beta 1 domain controllers in a forest before introducing any Whistler Beta 2 domain controllers. This issue will not be addressed in a future release.
Applies to users: administrators
Hardware
Audio
Global Effects Support Filter
On computers running Whistler Personal, Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, after installing a Global Effects Support filter, you must restart your computer to activate the filter. This issue will be addressed in a future release.
Applies to users: developers
OpenGL
On computers running Whistler Personal, Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, the OpenGL installable client driver (ICD) is not installed as a standard component. Some OpenGL-based programs can run correctly with the display drivers installed in Whistler. If you have an OpenGL-based program that does not run correctly and you need to get the correct OpenGL ICD for your computer, contact the video card manufacturer for the most up-to-date display drivers. This issue will not be addressed in a future release.
Applies to scenarios: improving user experience
Internet Services
Administration
On computers running Whistler Server or Whistler Advanced Server, for faster completion of the task, you should turn off World Wide Web service (W3SVC) before adding thousands of sites by using the IIS snap-in. You can also use the metabase APIs (ABO) to create sites, but if you do, close the metabase keys frequently. This issue will be addressed in a future release.
Applies to scenarios: improving user experience
Clustering
On computers running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, Iissync.exe does not function correctly in IIS 6.0. IIS support for Cluster services will be removed in a future release.
On computers running Whistler Server, Windows Clustering and failover support of individual sites is not supported. This issue will not be addressed in a future release.
Applies to users: administrators
Installation
On computers running Whistler Server or Whistler Advanced Server, default Web site permissions change after a clean installation. The default permission for Web sites changes from Full for Everyone to Read. If a user's application is required to create files in the user directory, then permissions must be reset accordingly. To work around this issue, change the permissions on the directory to give the relevant user (IUSR_machinename or any impersonated users or both) the appropriate permissions. Check all Web sites that inherit security properties and isolate these Web sites for security reasons. This issue will not be addressed in a future release.
Applies to scenarios: improving user experience
Internet Explorer
On computers running Whistler Personal, Whistler Professional, Whistler Server, or Whistler Advanced Server, Internet Explorer is currently developing privacy features in version 6.0. If you experience problems while using a particular Web site or receive errors related to cookies, try adjusting your Internet Explorer Privacy settings toLow to ensure compatibility.
To work around this issue
Applies to scenarios: improving user experience
Microsoft FrontPage� Server Extensions
After installing FrontPage Server Extensions with IIS 6.0 on a computer running any version of Whistler, the FrontPage Server Extensions snap-in for the Microsoft Management Console does not function correctly. To work around this issue, configure the FrontPage Server Extensions by using the command line tool fpsrvadm.exe. This issue will be addressed in a future release.
Applies to users: administrators, OEMs
Applies to scenarios: improving user experience
Network News Transfer Protocol
On computers running Whistler Server, Network News Transfer Protocol (NNTP) does not function when used with the default settings. To work around this issue, give the Everyone group write permissions for the Inetpub\Nntpfile directory. This problem will be addressed in a future release.
Applies to users: administrators
Performance
On computers running Whistler Server or Whistler Advanced Server, system resources become depleted when the World Wide Web service is started on systems with greater than 3800 sites.
To work around this issue, control system resources by setting the following registry parameter:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\
Parameters\LogBufferSize
Setting this key overwrites the internally set default value. LogBufferSize is a REG_DWORD type, and the values are in bytes.
You can also increase paged pool memory for the kernel by using the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
SessionManager\MemoryManagement\PagedPoolSize
Set PagedPoolSize to -1 (0xFFFFFFFF), which is the maximum possible paged pool for the kernel memory.
Caution
Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.
This issue will be addressed in a future release.
Applies to users: administrators
URL Redirection
On computers running Whistler Server or Whistler Advanced Server, when processing a URL that passes in an argument containing the plus character (+), IIS escapes the '+' character. As a result, character substitution occurs and redirection fails. To work around this issue, use redirect arguments singularly or use another character. This issue will be addressed in a future release.
Applies to scenarios: improving user experience
Localized/International Versions
German Language Version of Certification Authority
On computers running Whistler Personal, Whistler Professional, Whistler Server, or Whistler Advanced Server, when using the German language version of certification authority and proxy Web pages, the user is requested to download and register the Xenroll.dll ActiveX� control every time the user visits the Web page because the control is not correctly registered. This issue will be addressed in a future release.
Applies to users: administrators
Microsoft Management Console
Administration Tools Pack
If you upgraded from Windows 2000 or an earlier beta version of Whistler to the Beta 2 release for Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server and installed Adminpak.msi, remove the Administration Tools Pack by using Optional Components in Add or Remove programs. You can obtain an updated version of Adminpak.msi from the current Whistler media (do not install earlier versions of Adminpak on Whistler). The Terminal Service Client has been removed from Adminpak. The Terminal Service Client is now installed by default with the operating system (On theStart menu, point toPrograms, point toAccessories, point toCommunications, and clickRemote Desktop Connection). Terminal Server Manager is still included with Adminpak. Additions to Adminpak in the Beta 2 release include Network Load Balance Manager and Certificate Manager.
Applies to users: administrators
Object Model: Scripting
On all versions of Whistler, there is a known issue in the Whistler Beta 2 release because the MMC 2.0 class ID is not set correctly in the registry. The registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MMC20.Application
does not have a subkeyCLSID. It should have the sameCLSID subkey as
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MMC20.Application.1
Developers writing scripts using the MMC 2.0 object model receive a message when attempting to run a script that tries to create the COM object of type"MMC20.Application", and Visual Basic Scripting Edition (VBScript) applications change the script reference from"MMC20.Application" to"MMC20.Application.1".
For example, the workaround for VBScript is:
Set objMMC = WScript.CreateObject("MMC20.Application.1")
If you have a Visual Basic application, use late-binding and refer to"MMC20.Application.1".
For example, the workaround for Visual Basic is:
Set objMMC = CreateObject("MMC20.Application.1")
This issue will be addressed in a future release.
Caution Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.
Applies to users: administrators, developers
Applies to scenarios: improving user experience
Network and Communications
Connection Manager
On computers running Whistler Personal, Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, new Connection Manager client features include the following:
- Users can select a VPN server to use when initiating a VPN connection.
- An administrator can fill in the User Name and Password boxes for client use.
- Client log files for a connection can be created, cleared, and viewed by a user.
- Client use of terminal windows during connection is supported for all Windows platforms except Windows 2000.
- The Connection Manager client features the ability to define, save, and apply Favorite location properties and dialing rules as defined by the user.
- On a successful connection, the server can call back the client.
- Server/client authentication includes a dialog box that allows a user to re-enter a rejected user name or a password or both.
Applies to users: administrators
Applies to scenarios: improving user experience
Connection Manager Administration Kit
On computers running Whistler Personal, Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, new Connection Manager Administration Kit (CMAK) features include the following:
- TheConnection Manager Administration Kit Wizard supports inclusion of a VPN server file to make available user choice of VPN server at connection time.
- The dialog boxes for constructing service profiles have been improved.
- TheConnection Manager Administration Kit Wizard supports inclusion of automatic proxy configuration in a service profile.
- TheConnection Manager Administration Kit Wizard supports inclusion of routing table updates in a service profile (to enable split tunneling).
- A dialog box for advanced customization allows and simplifies editing .cms and .cmp files before the service profile is built.
Known Issues
- The Connection Manager client features listed above are not available for clients running Windows 2000.
- Users logging on to a Windows operating system with a Connection Manager profile might encounter problems authenticating the connection. To work around this issue, users should retype their password information.
- Users might experience a temporary delay when they open the Properties dialog box of a Connection Manager profile. To work around this issue, administrators should set the HideICSTab key to 1 in the .cms file of the profile.
- Some Connection Manager profiles might not be fully compatible with Internet Connection Sharing or Internet Connection Firewall. Users might encounter unexpected results if they choose to designate a Connection Manager profile as a shared connection.
These issues will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience
Internet Authentication Service
On computers running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server,Internet Authentication Service (IAS) features the ability to ignore dial-up properties of the user account. To support multiple types of connections where IAS is providing authentication and authorization, it might be necessary to turn off the processing of the dial-up properties of the user account to support scenarios where specific dial-up properties are not needed.
The dial-up properties of the user account contain the following:
- Remote access permission
- Caller ID
- Callback options
- Static IP address
- Static routes
The caller ID, callback options, static IP address, and static routes properties are designed for a dial-up client dialing into a network access server (NAS).
These settings were not designed for wireless access points. A wireless access points that receives these settings in theRemote Authentication Dial-In User Service (RADIUS) message from the IAS server might be unable to process these settings and disconnect the wireless client. When IAS is providing authentication and authorization for users who are both dialing in and gaining access to the organization network using wireless devices, the dial-up properties must be configured to either support dial-up connections (by setting dial-up properties) or wireless connections (by not setting dial-up properties). In Whistler, you can turn on the processing of the dial-up properties of the user account for some scenarios (such as incoming) and turn off the processing of the dial-up properties of the user account for other scenarios (such as wireless and authenticating switch) by configuring the Ignore-User-Dialin-Properties attribute on theAdvanced tab of the profile settings of a remote access policy.
To turn on the processing of the dial-up properties of the user account, set the Ignore-User-Dialin-Properties attribute at its default value, which is 0. For example, for the remote access policy that is designed for dial-up connections, no additional configuration is needed.
To turn off the processing of the dial-up properties of the user account, set the Ignore-User-Dialin-Properties attribute to the value of 1. For example, for the remote access policy that is designed for wireless or authenticating switch connections, set the value of the Ignore-User-Dialin-Properties attribute to 1.
When the dial-up properties of the user account are ignored, remote access permission is determined by the remote access permission setting of the remote access policy. These issues will be addressed in a future release.
Applies to users: administrators
IP Security Monitor Utility
The Windows 2000 Internet Protocol security (IPSec) monitor utility Ipsecmon.exe does not function on any version of Whistler. The IP Security monitor MMC snap-in replaces Ipsecmon.exe. This issue will be addressed in a future release.
Applies to users: administrators
IPSec Using Encapsulating Security Payload
On all versions of Whistler, IPSec usingEncapsulating Security Payload (ESP) with encryption only (DES or 3DES) and without integrity (neither MD5 nor SHA1) is being deprecated. ESP with encryption SHOULD always be used with integrity to prevent network attacks on ESP packets. ESP with integrity only and no encryption is still supported. This issue will not be addressed in a future release.
Applies to users: administrators
Ipsecpol.exe
The Windows 2000 tool Ipsecpol.exe does not function on any version of Whistler. Ipseccmd.exe replaces Ipsecpol.exe in Whistler. This issue will be addressed in a future release.
Applies to users: administrators
IP Telephony and TAPI
On computers running Whistler Personal, Whistler Professional, or Whistler Server, the following network and communications issues involve Internet Protocol (IP) telephony and Telephony Application Programming Interface (TAPI). These issues will be addressed in a future release.
- IP telephony video streaming support and video streaming related features are not available on Itanium-based systems.
- Internet Locator Service (ILS) is no longer shipped with the operating system. To work around this issue, use a TAPI Application Directory Partition within Active Directory to store Conference and Users objects. Whistler TAPI clients can still use servers to store these objects. For more information about TAPI Application Directory Partition, see Whistler Help and Support Services.
- Acoustic Echo Cancellation (AEC) might cause IP telephony sessions using Session Initiation Protocol (SIP) or H.323 to fail to interoperate with other systems. To work around this issue, you should turn off AEC by using one of following methods.
By using Phone Dialer
- On the Start menu, point to Programs, point to Accessories, point to Communications, and then click Phone Dialer.
- On the Edit menu, click Options.
- On the Audio/Video tab, clear the Enable acoustic echo cancellation check box.
By using the Tuning Wizard
- Right-click Start, and then click Explore.
- In Microsoft Windows Explorer, click the Program Files folder, and then click the Windows NT folder.
- Double-click Rtcclnt.exe to open Phoenix.
- On the Tools menu, click Tuning Wizard. Follow the instructions that appear.
- Select the I am using a headset check box.
- You cannot install Dialogic boards on computers running Whistler Beta 1 or Whistler Beta 2. To work around this issue, install Dialogic (DNA 3.x) boards on a computer running Windows 2000, and then upgrade to Whistler Beta 1 or Whistler Beta 2.
- If the computer name is changed after publishing the Tapisrv.exe, which is a service process for telephony service providers, you will not be able to run Tapisrv.exe on this computer.
- Whistler TAPI and real-time communications clients were tested and are known to work with the following video cameras:
- Intel PC Camera Pack USB
- Intel PC Camera Pro Pack USB
- Intel Create and Share Camera Pack USB 2.0
- Philips PCA645VC PC Camera VGA USB with Video Creator SW
- Philips Vesta Pro SuperVGA USB PC Camera
- Philips PCA646VC USB PC Camera
- Intel Create and Share Camera Pack USB 1.0
Applies to scenarios: improving user experience
IP Version 6 Networking Support
Internet Protocol version 6 (IPv6) networking support is available in all versions of Whistler. To install the IPv6 protocol on Whistler Beta 2, at command prompt, type
ipv6.exe install
and restart the computer when prompted. For IPv6 software development, use the Platform SDK for WhistlerBeta 2. For more information about IPv6 support, see Whistler Help and Support Services. This issue will be addressed in a future release.
Applies to users: developers, OEMs
Applies to scenarios: improving technology
Legacy Networking Components
Support for the following networking protocols has been removed from all versions of Whistler. This issue will not be addressed in a future release.
- NetBEUI - a non-routable protocol for file and print sharing.
- DLC - a non-routable protocol for communicating to certain mainframes and older printers.
To work around this issue
http://www.microsoft.com/hiserver/
Applies to scenarios: improving technology
Network Configuration
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, turning on the group policies that prohibit Windows 2000 group policies for administrators results in undefined behavior. These policies do not work correctly and administrators still have all privileges with regards to the connections folder and other entities managed by the Network Configuration Group Policy engine. This affects all user policies for administrators when the policy called Enable Windows 2000 policies for administrators is turned on. Computer policies (ICF, Bridge and Shared Access UI) will still work correctly. This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience, improving technology
Resource Kit
Timestamp.sys
If you've installed Timestamp.sys from the Resource Kit (the client and server versions) and upgraded to Whistler Personal or Whistler Professional, your IP settings will be lost. To work around this issue, uninstall Timestamp.sys by running Tsinstl.exe from the Resource Kit and follow the instructions that appear. First select(2) uninstall, next select the interface (per network adapter). You will need to restart your computer before you perform an upgrade to Whistler.
Applies to scenarios: improving user experience
Routing and Remote Access Service Client Features
Whistler Personal, Whistler Professional, Whistler Server, Whistler Advanced Server, and Whistler Datacenter Server Beta 2 versions include new Routing and Remote Access service and virtual private network (VPN) client features, as detailed below:
- Routing and Remote Access service messages include additional Help information.
- Dial-up connections to the Internet created with the Make New Connection Wizard have NetBIOS over TCP/IP (NetBT) turned off by default, preventing probing of computer and user names.
- All-user connections appear in the Network Connections folder for every user.For Whistler Professional computers not joined to a domain, and for all Whistler Personal computers, all new connections are created as all-user connections. For the Whistler Server family, and for Whistler Professional computers joined to a domain, an administrator can create a new outgoing connection for all users, or for individual use only; non-administrative users can create connections only for their individual use.
- Global credentials: Users can make user name and password information available to all users of an all-user connection. Any user can then start this connection without needing to know the user name and password. If user name and password information is saved for all users, an outgoing connection remains active if different users log on and off.
- An outgoing connection can be designated as the default Internet connection. This connection is dialed automatically if a program requests an Internet resource and no Internet connection is active.
- Internet Connection Firewall integrates seamlessly with incoming VPN connections.
- VPN connections authenticate and connect more quickly and robustly.
- Pre-shared keys are supported for Internet Protocol security (IPSec)-based VPN connections.
- The remote access client supports Point-to-Point Protocol over Ethernet (PPPoE) for broadband connections.
- On a successful connection, the remote access client caches user credentials so that they can be used to access resources on the remote network.
- On a successful connection, the remote access client issues DHCP-inform requests to obtain the DNS domain name and subnet mask for the network to which it has connected and to obtain optional routing information for that network.
At the release of Whistler Beta 2, most third-party VPN clients are functioning incorrectly in all versions of Whistler. If you encounter a problem with one of these clients, please contact the application vendors to ensure they are aware of your issues and to see if they have an updated client. Whistler Server and many third-party VPN servers support Layer 2 Tunneling Protocol (L2TP)/IPSec and Point-to-Point Tunneling Protocol (PPTP). If your third-party VPN client is not working correctly, to work around this issue, use the native Whistler VPN client for L2TP/IPSEC or PPTP connections. For more information on the native client, please see the online Help or your product documentation.
Applies to users: administrators
Applies to scenarios: improving user experience
Routing and Remote Access Service Server Features
All Beta 2 versions of Whistler include new Routing and Remote Access service and virtual private network server features.
New RRAS and VPN server features:
- Pre-shared keys are supported for IPSec-based VPN connections.
- If Quality of Service (QoS) is enabled, a Routing and Remote Access service can be configured to prioritize multimedia packets over other network traffic for modem and ISDN connections.
- The Routing and Remote Access service includes an NetBT gateway so that remote access clients can access intranet resources by name without requiring a WINS or DNS server on the intranet.
Known Routing Issue
- The routing interface that sends packets in IP tunneled mode (IP-in-IP interface) is no longer supported.
This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience
Services For Macintosh
Guest
In the Password box, do not make any entries. This issue will be addressed in a future release.
- A computer running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server does not include a Microsoft user authentication module (UAM) that runs on Mac OS X. Users should be able to run the current Whistler and Windows 2000 Microsoft UAM under OS 9 compatibility mode.This issue will be addressed in a future release.
- If a computer running Whistler Server, Whistler Advanced Server, or Whistler DatacenterServer has the AppleTalk protocol installed and bound to a network interface and the Remote Access Service (RAS) is turned on, then this server advertises itself as an AppleTalk router. As a result, other AppleTalk clients send traffic to the server. The server does not route the AppleTalk packets. The result is loss of AppleTalk connectivity for the network. To work around this issue, turn off AppleTalk for that network interface. Edit the connection properties for the network interface and clear the check box that turns on the AppleTalk protocol. This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience
Token Ring Adapter
On a computer running Whistler Personal, when sending a data packet on a token ring adapter, there might be a loss of functionality because the data packet could contain a variable length MAC header. This bug check will be in Generic Packet Classifier (GPC) caused by QoS Packet Scheduler or in the Packet Scheduler itself. To work around this issue, restart your computer and uninstall the QoS Packet Scheduler driver. This issue will be addressed in a future release.
To uninstall the QoS Packet Scheduler driver
Once these steps are completed, you can upgrade to Whistler.
Applies to scenarios: improving user experience
Postinstallation
Remote Installation Services
The following sections address issues for Remote Installation Services (RIS).
RIPrep.exe Tool
The following issues apply to using the RIPrep.exe tool with Remote Installation Services (RIS).
- If you run RIPrep.exe on a computer running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server and let it run through mini-setup three times, when you run it a fourth time, RIPrep fails immediately before it gets to the copy file phase. No message appears to note this has happened. This issue will be addressed in a future release.
- When you run RIPrep.exe on a computer running Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, a message might appear stating, "Access denied � c:\documents and settings\foldername (where foldername is either networkservice or localsystem) could not be copied because access to the file was denied. The file will not be included in the new installation image." The RIPrep image will still be created and can be used for testing. This issue will be addressed in a future release.
Applies to users: administrators, OEMs
RIS Server
Due to Active Directory changes, if you have any Whistler domain controllers within your Active Directory directory service, your RIS Server must also be upgraded to Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server. If all domain controllers within your domain are running Windows 2000, you can run either a Windows 2000 or Whistler RIS server. This issue will not be addressed in a future release.
Applies to users: administrators, OEMs
Setup
The Remote Installation Setup description is incorrect. When you run RISetup.exe on Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server byusing Windows 2000 Server media, the description will incorrectly identify the operating system as Windows 2000 Professional rather than Windows 2000 Server. All files will still be copied correctly. This issue will be addressed in a future release.
Applies to users: administrators, OEMs
Security
Certificate Services
Automatic Enrollment for Version 2 Certificate Templates
Computers runningWhistler Server or Whistler Advanced Server configured to automatically enroll for version 2 certificate templates that require a signature on the certificate request will fail. No message is displayed.To work around this issue, do not require signatures on templates used for computer certificates.This issue will be addressed in a future release.
Applies to users: administrators
Certificate Manager
On computers running Whistler Server or Whistler Advanced Server, a Certificate Manager allowed to manage a group (issue and revoke certificates for that group) cannot manage a user within that group. To work around this issue, add the Certificate Manager user account to the Pre-Windows 2000 Compatible Access group in the domain of the group being managed. This issue will be addressed in a future release.
Applies to users: administrators
Certificate Templates
On computers running Whistler Server or Whistler Advanced Server, version 2 templates cannot be used or issued by a Whistler certification authority until they have been initialized.
To work around this issue
Applies to users: administrators
Certrqxt.asp
On computers running Whistler Server or Whistler Advanced Server, Certrqxt.asp currently does not display any certificate templates that are a CROSS_CA type. This is a new certificate type in addition to MACHINE and USER. Therefore, cross-certificates cannot be issued through the Web enrollment pages in Whistler Beta 2.
To work around this issue, cross-certificates can still be issued by using the command line tool Certreq.exe. This issue will be addressed in a future release.
Applies to users: administrators
Netscape 4.76
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, a Netscape 4.76 client enrolling to a Microsoft Enterprise certification authority (CA) fails and the message "Request Status Code: 0x80094805 (-2146875387) -- The request is missing a required SMIME capabilities extension. Request Disposition: 0x1f (31) -- Denied Request Disposition Message: Denied by Policy Module" appears. This issue will be addressed in a future release.
Applies to users: administrators
Web Enrollment
On computers running Whistler Professional, Whistler Server, or Whistler Advanced Server, Web enrollment to a cross-certified root CA with the Enable user root store Group Policy object turned off causes the Web enrollment client to fail while downloading the root certificate. Although a message to the contrary does appear, the certificate was issued successfully and the message can be ignored. This issue will be addressed in a future release.
Applies to users: administrators
Whistler Enterprise Certification Authority
A Whistler Server or Whistler Advanced Server Enterprise certification authority (CA) in a Windows 2000 domain issues certificates with a blank subject name or fails to issue certificates from version 2 templates. To work around this issue, upgrade the schema of the forest to a Whistler schema. This issue will be addressed in a future release.
Applies to users: administrators
Configuring Web Proxy to a Stand-alone Certification Authority
On computers running Whistler Server or Whistler Advanced Server, when you configure a Web proxy to a stand-alone certification authority and both computers are not in a Windows 2000 or Whistler domain, certificate requests do not function correctly. The message "Access Denied" also appears. This issue will be addressed in a future release.
Applies to users: administrators
Forest Trust
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, domain tree depth is limited for logging onto a network between forests when using Kerberos V5 authentication. The server can be located in the first (root), second, or third level of the domain tree in the trusted forest. The client must be located in the first or second level of the domain tree in the trusting forest. If the client's domain is any lower in the tree, Kerberos V5 authentication to a server in a trusted forest fails. NTLM is not affected. Thus, deeper domain trees can be used with applications that request authentication protocol negotiation because they will roll back to NTLM.
Applies to users: administrators
Applies to scenarios: improving user experience
Smart Card
On all versions of Whistler, to enable monitoring of Microsoft's internal smart card testing, code has been added to Winlogon to record smart card usage. When configured and able to connect to the appropriate database, the monitoring code writes information to a SQL server such as: successfully logging on with a smart card, failure while logging on with a smart card, error code on failure, computer name, smart card reader type, and smart card type. Monitoring is switched off by default. A key exists to switch on logging; it is switched off by default. Microsoft is investigating ways of making the schema available to enterprises planning on deploying smart cards. The value used to switch on monitoring is:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\
CurrentVersion\Winlogon\EnableSmartCardAuthMonitor
This value is of type REG_DWORD. The default value is 0 (0 = disabled, 1 = enabled).
Caution
Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.
Applies to users: administrators
Applies to scenarios: improving user experience
Smart Card Certificates
On all versions of Whistler, certificate auto renewal fails for smart card certificates on Gemplus smart cards when the card has been used to log on to the session where renewal is initiated. This issue will be addressed in a future release.
Applies to users: administrators
Applies to scenarios: improving user experience, improving technology
Smart Card Enrollment
When enrolling users for logging on using a smart card by using the Smart Card Enrollment Station or the Certificates MMC snap-in on all versions of Whistler, you cannot use the smart card enrolled for logging on from a Windows 2000 computer. If you want to use the smart card to log on from a Windows 2000 computer, the enrollment should take place from a Windows 2000 computer. You can use the smart card enrolled in this way to log on from a Windows 2000 or Whistler computer.
Applies to users: administrators
Applies to scenarios: improving user experience, improving technology
Smart Cards/Terminal Server
On all versions of Whistler, if a user connects to a Whistler Terminal Server which has redirection turned off or to a Windows 2000 Terminal Server, using a Whistler Terminal Server client running on a Windows 2000 or Whistler computer with a smart card reader attached and a smart card in the reader, the Terminal Server will show theWelcome to Windowsdialog box (asking the user to enter the secure attention sequence) instead of the password dialog box. On a server running Whistler Terminal Server, this behavior is a result of smart card redirection on the Terminal Server being turned off by default. On a server running Windows 2000 Terminal Server, this behavior is as a result of smart card redirection not being supported. This issue will be addressed in a future release.
To work around this issue
Or, ensure that your users are aware that Terminal Server requires the user to press CTRL+ALT+END (instead of CTRL+ALT+DEL) to open the password dialog box.
Applies to users: administrators, OEMs
Applies to scenarios: improving user experience, improving technology
Smart Cards/Terminal Services
Terminal Services inWhistler Server, Whistler Advanced Server, or Whistler Datacenter Server support smart card redirection, which is a new feature for users who have a smart card reader and a smart card suitable for logging on. By using this new feature, a person using the Whistler Terminal Server client running on Windows 2000 or Whistler can use the smart card to log on to a Whistler Terminal Server. This feature is turned off by default in Whistler Beta 2.
To turn it back on, you need to set the following registry value:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\
Windows NT\Terminal Services\fEnableSmartCard
Caution
Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.Note To implement this change, you must restart your computer.
There are certain scalability limitations for Whistler Beta 2 that were fixed after the feature was developed. These changes could cause problems in certain stress conditions. You should turn on this feature only on Terminal Server to test the usability of the smart card logon feature. This issue will be addressed in a future release.
Applies to users: administrators, OEMs
Applies to scenarios: improving user experience, improving technology
User Names and Passwords
All versions of Whistler have a new feature that you can use to store user names and passwords for later reuse when connecting to specific servers or Web sites. The user is prompted to enter these credentials and has the choice of saving them for future use. When using Internet Explorer in Whistler Beta 2, if the user is prompted to enter credentials when accessing a Web site and the user does not select theRemember my password check box, Internet Explore saves the credential until the user logs off. To remove this credential, go to the key ring and delete the credential.
Applies to scenarios: improving user experience
Windows Logon Issues
On computers running Whistler Personal or Whistler Professional, when you lock or log off a non-domain-joined computer that has a smart card reader installed, the dialog box with the text "Press Ctrl+Alt+Delete to begin"appears over theWelcome screen. This occurs only on a non-domain joined computer configured to use the Friendly UIWelcome screen.To work around this issue, press CTRL+ALT+DELETE and log on by using theWelcome screen as you normally would. This issue will be addressed in a future release.
Applies to scenarios: improving user experience
Server Management
Windows Management Instrumentation
AMD Duron Processors
On computers running Whistler Personal, Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, some AMD Duron processors are reported incorrectly by the System Properties dialog box as Athlon processors. This information is being reported directly as a text string from the AMD processor and is not the result of a problem with the Whistler operating system.
To check whether this is occurring on your operating system
Applies to users: OEMs
Applies to scenarios: improving user experience
Command Line
On computers running Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, the following are guidelines for using the Windows Management Instrumentation (WMI) command line tool.
In interactive mode:
- To start the application tool, at the command prompt, type
wmic
Or, in Windows Explorer, double-click Wmic.exe.
- For help and support, at the WMIC wmic:root\cli> prompt, type
alias name /? or switch name /?
- For list of the syntax and available aliases, at the WMIC wmic:root\cli> prompt, type
/?
- For options available for the Process alias, at the WMIC wmic:root\cli> prompt, type
process /?
- For running a specific command, at the WMIC wmic:root\cli> prompt, type
alias name or switch name
In non-interactive mode:
- For help, at the command prompt, type
wmic /?
- For a brief list of processes running on the current computers (nodes), at the command prompt, type
wmic process list brief
Applies to users: administrators, developers, OEMs
Applies to scenarios: improving user experience
Deprecated Properties and Classes
On computers running Whistler Personal, Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, the following WMI properties and classes are marked as deprecated in this beta release. Several of them were also marked deprecated in Windows 2000. From time to time it is necessary for Microsoft to deprecate certain classes, properties, and methods because the information they provide is no longer available or relevant or has changed in some way. There are also cases where the data was supplied in an incorrect format originally (for example, the data type used should have been an array instead of a scalar value) and it is necessary to deprecate the existing property and create a new one. In these situations, the object in question is marked with a Deprecated qualifier, and its associated Description qualifier is updated to indicate the object is deprecated and, where applicable, what alternative object to use instead. When a particular object is deprecated, you should update your products accordingly to stop using these objects as soon as practical. Please see the Description qualifier for each of these objects or the Platform SDK documentation for further details. The following is a list of deprecated properties and classes in this Whistler version involving Win32� :
- CIM_ProcessExecutable.ModuleInstance Win32_AllocatedResource
- Win32_Battery.ExpectedBatteryLife Win32_Battery.BatteryRechargeTime
- Win32_CDROMDrive.FileSystemFlags Win32_DisplayConfiguration
- Win32_DisplayControllerConfiguration Win32_LogicalMemoryConfiguration
- Win32_NetworkAdapter.Installed
- Win32_NetworkAdapterConfiguration.IPPortSecurityEnabled Win32_PageFile
- Win32_Printer.PrinterState Win32_Printer.SpoolEnabled
- Win32_PrinterConfiguration.BitsPerPel Win32_PrinterConfiguration.DisplayFlags
- Win32_PrinterConfiguration.DisplayFrequency Win32_PrinterConfiguration.LogPixels
- Win32_PrinterConfiguration.PelsHeight Win32_PrinterConfiguration.PelsWidth
- Win32_PrinterConfiguration.XResolution Win32_PrinterConfiguration.Yresolution
- Win32_Product.InstallDate Win32_ProgramGroup Win32_SCSIController.DeviceMap
- Win32_SystemLogicalMemoryConfiguration Win32_VideoConfiguration
These issues will not be addressed in a future release.
Applies to users: developers, OEMs
Applies to scenarios: improving technology
Namespaces Security
If you upgrade your computer from Windows 95, Windows 98, Windows 98 Special Edition, or Windows Millennium Edition to Whistler Personal or Whistler Professional and apply special user security to the WMI namespaces, the namespaces are removed and replaced with system defaults. To work around this issue, add the WMI namespaces by adding the WMI Control snap-in to MMC. This issue will be addressed in a future release.
Applies to scenarios: improving user experience
Notification Query Against Decoupled Event Providers
On computers running Whistler Personal, Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, when an application running at the identity level of impersonation creates a subscription using IWbemServices::ExecNotificationQuery/Async for events generated by a decoupled provider, the first notification query does not function correctly. The message "Access denied" appears unless a permanent subscription for the same event is already registered. The second notification query succeeds and functions correctly.
Applies to users: administrators, developers, OEMs
Provider Hosting and Security
On computers running Whistler Personal, Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, the following issues pertain to provider hosting and provider security.
For provider hosting, in Windows 2000 and Whistler Beta 1, all providers are loaded in-process to Windows Management service, which runs under the LocalSystem account. In Whistler Beta 2, the providers load into a provider subsystem. In general, hosting providers out-of-process guarantees that a faulting provider affects only the providers in the same host and hosting providers out-of-process cannot end the critical Windows Management process. The provider host's lifecycle is fully controlled by Windows Management. The latter automatically restarts the host if it exits for any reason. This effort increases WMI robustness and reliability for applications that rely on the key services that WMI provides.
For provider security, providers should use the NetworkService security account. This account is intended for services that have no need for extensive privileges, but have the need to remotely communicate with other systems. Using this account eliminates the potential risk that a corrupted or compromised provider could remove the entire computer (or domain, in the case of a domain controller). It also ensures that no privileged information is revealed to a user in case the provider does not correctly impersonate the client's context.
To enable this security, make the following changes in the provider registration managed object format (MOF)
Event providers do not perform operations on behalf of individual subscribers; instead, event providers listen for occurrences or changes in event provider data sources and then start events. This means that event providers access their event sources while not impersonating anyone (they rely on the internal event system to perform the appropriate access checks before firing events).
Given these security requirements in Whistler, if you load any instance, class, or method provider into LocalSystemHost (by default or by explicitly setting the hosting mode) the subsystem generates a warning entry in the NTEventLog indicating that this might pose a security risk in the enterprise.
These issues will not be addressed in a future release.
Applies to users: administrators, OEMs
Applies to scenarios: improving technology
Remote Client Security
On computers running Whistler Personal, Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, WMI has tightened security for remote client connection to WMI as part of improving the security and performance for Whistler.
For example, in Whistler, WMI runs Svchost.exe, which requires higher security access to connect to WMI (RPC_C_AUTHN_LEVEL_PACKET). Specific remote access scenarios where programs are affected are as follows:
- Computers running Windows 2000 Service Pack 1 or Whistler Beta 1 cannot remotely connect to a computer running Whistler Beta 2. A workaround is provided in both Windows 2000 Service Pack 2 and Whistler Beta 2 that allows clients to remotely connect to a computer running Whistler Beta 2. For more information about using CoSetProxyBlanket () correctly, see the following section.
- If a program specifically overrides the distributed component object model (DCOM) and sets the authentication level to CONNECT (by using CoSetProxyBlanket), the program cannot remotely connect to WMI on a computer running Whistler Beta 2 (because this overrides DCOM security negotiation). You should avoid using proxy security in the program. To work around this issue, use CoInitializeSecurity() instead.
If the program is required to use CoSetProxyBlanket(), the following changes must be considered
- Programs deployed on Windows 2000 and Whistler can use RPC_C_AUTHN_LEVEL_DEFAULT instead of CONNECT.
- Programs deployed on a broad range of operating systems (for example, Windows 95, Windows 98, Windows Millennium Edition, Windows NT 4.0, Windows 2000, and Whistler operating systems) that require remote access to Whistler can use CoQueryProxyBlanket(). Return DCOM security settings and use these parameters to set the security on the proxy using CoSetProxyBlanket().
These issues will not be addressed in a future release.
Applies to users: developers
Applies to scenarios: improving technology
Reporting Intel Itanium Processor Speed
On computers running Whistler Personal, Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, the Windows Management Instrumentation (WMI) property Win32_Processor.CurrentClockSpeed (and therefore user interface components that make use of it such as the Computer System Properties dialog box) reports incorrect values on Intel Itanium processors. This issue is caused by a problem in a kernel API where the information is being retrieved. This issue will be addressed in the future release.
Applies to users: administrators, OEMs
Applies to scenarios: improving user experience
Time Provider
On computers running Whistler Personal, Whistler Professional, Whistler Server, Whistler Advanced Server, or Whistler Datacenter Server, the system clock class is defined as:
<class Win32_CurrentTime { uint32 Year; uint32 Month; uint32 Day; uint32 DayOfWeek; uint32 WeekInMonth; uint32 Quarter; uint32 Hour; uint32 Minute; uint32 Second; [key] sint32 UTCOffset; };>
Currently, we can form queries for a specific point in time in the future. The basic form of a query is:
<select * from __InstanceModificationEvent>
where:
TargetInstance = class "Win32_CurrentTime"
TargetInstance.Year = 1999
TargetInstance.Month = 10
TargetInstance.Day = 4
TargetInstance.Hour = 11
TargetInstance.Minute = 0
TargetInstance.Second = 0
This query specifies a single point in time, irrespective of the time at which it is to be evaluated, at which an event should be generated. If the time specified is in the past at the time it is evaluated, then no event occurs. Queries are coded assuming universal time (UTC). All times returned in the __InstanceModificationEvent object represent the current system time in UTC at the time the event was generated.
The fundamental unit of time recognized by the time provider is seconds. This means, for example, if a query omits the seconds field, then when all supplied parameters (year, month, day, and so on) match the current time, an event will be generated every second that the current time matches the query. The same is true for minutes, hours, and so on. The field UTCOffset is not recognized for event queries. The event queries must be defined in Greenwich mean time (GMT). For instance queries, it represents the time zone offset from UTC time with UTC time itself in time zone UTCOffset = 0. For instance queries there exists one Win32_CurrentTime object for each time zone -12 far west to far east +13. Thus, a total of 26 instances exist. When queried, each instance represents current system time adjusted for that time zone.
The following issues will be addressed in a future release.
- The class type for Win32_CurrentTime and the classes derived off of Win32_CurrentTime
- The class type for Win32_UTCTime and Win32_LocalTime
In order to be valid, a query must have each of the following properties: