Network DDE Fails with Floating Profile from Other ComputerLast reviewed: May 8, 1997Article ID: Q103055 |
The information in this article applies to:
WARNING: Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk. SYMPTOMSUsers who have floating or mandatory user profiles cannot receive Chat conversations on computers other than the one on which their original profile was created. Similarly, they will not be able to successfully create Clipbook Viewer pages or play Hearts. If a profile is created on the computer they will use, these applications will function on their own computer, but not on other computers. If their initial profile is created on an administrator's computer, these applications will not work on any computer.
CAUSEWhen Network DDE validates a conversation, it first checks to see if the DDE share is listed as a trusted share for the user logged on to the computer sharing the conversation. It does this by opening the following Registry subkey
HKEY_CURRENT_USER\Software\Microsoft\NetDDE \DDE Trusted Shares\DDEDBi<xxxxxxx>where <xxxxxxx> is a serial number found in the SharesDBInstance value of the following subkey:
HKEY_LOCAL_MACHINE\Software\Microsoft\NetDDE\DDE SharesThis serial number is statistically unique on each computer and serves to tie the Trusted Shares list to the computer on which the shares are trusted. These keys are created during setup. For floating and mandatory profiles, the DDEDBi<xxxxxxx> subkey will contain only the entry for the computer on which the profile was created. When Network DDE attempts to open the DDEDBi<xxxxxxx> subkey on other computers, the attempt fails since other computers do not have the same serial numbers. This behavior disallows Network DDE conversations from being established. NOTE: You must be a member of the Users, Power Users, Server Operators, or Administrators group in order to create Clipbook pages.
WORKAROUNDTo work around this problem, create floating profiles on the workstation that the user is likely to work on. You can also enable Network DDE applications to work on a particular computer by manipulating values in the Registry. You need to copy the DDE trusted shares information from the target computer's default profile into the user's online profile. You must have administrative privileges on the target computer in order to perform these actions:
BACKGROUNDClipbook, Chat, and Hearts rely upon Network DDE to operate. Network DDE is a protocol for sending DDE messages across a network. Similar to the way in which directories may be shared across the network, a DDE conversation can be "shared" on the network. The Network DDE DSDM service maintains a database of shared conversations on each computer. When you share a page in Clipbook, a Network DDE share is created in this database. Similarly, in order for Chat to operate, Setup creates a Network DDE share for Chat. When a Network DDE share is accessed over a network, the shared conversation is referenced, and appropriate security checks are made to make sure the requester can be granted access. For some shared conversations, an application must be running on the computer sharing the conversation--for example, any time a linked item needs to be updated, or when a Chat conversation is started with someone. In either case, the application that placed the information in Clipbook (Microsoft Excel for example) or Chat must be running in order to service the request. All applications on a computer are running in the "security context" of the user who is interactively logged on to the computer. Therefore, when a remote request is serviced by a running application on a computer sharing a Network DDE conversation, the application handling the request is running in the security context of the person logged on to the sharing computer, not in the remote user's security context. With this design, there is the potential for security violations. Conceivably, a user could share a Network DDE conversation and remotely connect to it while someone else was logged on, thus enabling the user to access the sharing computer as if he or she were the other logged on user. To avoid this situation, in order for a shared conversation to be used, the logged on user at the time of use must have this shared conversation in its list of trusted shares. When Windows NT is installed, the following Registry value
HKEY_LOCAL_MACHINE\Software\Microsoft\NetDDE \DDE Shares\SharesDBInstanceis set to a random number in order to uniquely identify the computer. The Chat$, CLPBK$, and Hearts$ keys are also created under the following subkey:
HKEY_USERS\Default\Software\Microsoft\NetDDE \DDE Trusted Shares\DDEDBi<xxxxxxxx>The <xxxxxxxx> value in this key name is obtained from the random number entered in the SharesDBInstance value, as mentioned above. When a new user logs on or a floating or mandatory profile is created on a computer, these keys and values are copied into the user's profile. This means that the user's profile has all the Network DDE keys the user will need for the computer that he or she first logs on to or that the profile is created on. However, the user does not have similar entries for other computers that the user may log on to. When Network DDE is asked to add a trusted share for a user, a new DDEDBi<xxxxxxxx> key should be created. Instead, Network DDE attempts to open this key and the attempt fails because the key does not exist. The Trusted Shares list and the list of Network DDE shares are kept in the Registry and in general should not be directly modified. However, to work around this problem, it is easiest to manually patch the Registry as described in the "Workaround" section above.
|
Additional query words: prodnt
© 1998 Microsoft Corporation. All rights reserved. Terms of Use. |