In a domain environment, this ticket lifetime can also be configured using Group Policy. Solicited RA using file transfer This method requires that both the User and Helper have access to a common folder such as a network share on a file server , or that they use some other method for transferring the file for example, by using a USB key to manually transfer the file or by uploading the file to an FTP site.
The user creates a Remote Assistance invitation file and saves it in the shared folder. The User must provide a password that must be communicated to the Helper using an OOB method such as a telephone call. The Helper retrieves the ticket from the shared folder, opens it, enters the password, and the Remote Assistance session starts. Again, the Helper must respond to the invitation within a specified time, or the invitation will expire and a new one will be needed. The expiration time is configurable through Group Policy.
In this approach, the User requests assistance from someone on his buddy list. To establish the initial Remote Assistance session, the User only needs to communicate a password to the Helper using an OOB method such as by telephone. The Helper uses this password to obtain the Remote Assistance invitation from the cloud and initiate the session.
When the initial Remote Assistance connection has been made, a trust relationship is established between the Helper and the User. This trust relationship is established through the exchange of contact and certificate information. Subsequent interactions are simplified because the contact information can be used to pick a Helper who is currently available.
For more information on this method for soliciting assistance, see the section titled "Scenario 1: Soliciting Remote Assistance Using Easy Connect" later in this chapter. Unsolicited RA is a typical corporate Help Desk scenario in which all the users are in a domain.
This method requires that the Helper has been previously authorized as a domain administrator to be able to offer Remote Assistance to the Users. For information on how to authorize Helpers for offering Remote Assistance, see the section titled "Managing Remote Assistance Using Group Policy" later in this chapter.
Microsoft P2P network and collaboration technologies are designed to enable the next generation of peer-to-peer scenarios, including shared workspaces, distributed computing, and even load balancing. These P2P technologies allow users to securely communicate and share information with each other without requiring a central server to be involved.
Because P2P technologies are designed to work in networking environments with transient connectivity—such as an ad hoc wireless network established between several laptops at a coffee shop—they cannot rely on the server-based Domain Name System DNS to perform name resolution between peers. PNRP works by utilizing multiple groupings of computers called clouds.
These clouds correspond to two different scopes of IPv6 addresses:. Global cloud Any given computer will be connected to a single Global cloud. In networks where computers do not have IPv6 Internet connectivity but still have Global IPv6 addresses such as firewalled corporate environments , the Global cloud is network-wide. Link-local clouds One or more clouds, each corresponding to nodes within the same subnet or network link link-local addresses and the link-local address scope.
Note that Remote Assistance only uses the Global Internet-wide cloud; link-local clouds are not used by Remote Assistance. Peer names can be computers, users, devices, groups, services, or anything that can be identified by an IPv6 address and port. When the issuing peer wants to resolve the name of the targeted peer to its published address and port number, it follows these steps:.
The issuing peer first consults its own PNRP cache for this information. If it finds this information, it sends a PNRP Request message to the targeted peer and waits for a response. These Request messages serve the function of enabling peers to communicate to other peers their active involvement within the cloud.
If the issuing peer does not find this information, it sends the Request message to the peer whose ID most closely matches that is, is closest numerically to that of the targeted peer. The peer that receives this message then consults its own cache. If it finds a closer match or the match itself, it returns this information to the requesting peer. The requesting peer then goes to the returned peer and the process continues until the resolution succeeds or fails.
If the peer that receives this message does not find closer information in its cache, it returns the message to the issuing peer, indicating that it does not know the targeted peer. The issuing peer then repeats the previous step by sending a message to the peer whose ID next most closely matches that of the targeted peer. This process continues until the targeted peer is found if present on the network or not found if no longer present within the cloud.
Looping is prevented by including in the Request message the list of peers that have already forwarded requests. The Helper has offered Remote Assistance to the User, but the User has not yet agreed to allow the Helper to connect to his computer. The User has sent the Helper an invitation but the Helper has not yet responded by opening the invitation, or the Helper has opened the invitation and the User has not yet agreed to allow the Helper to connect to his computer. After the Remote Assistance application has been started and is running in the Waiting For Connect state, the application should not be closed until the other party responds and establishes the connection.
Screen Sharing This state occurs when the User has consented to allow the Helper to connect to his computer—either after the User has sent the Helper an invitation or the Helper has offered Remote Assistance to the User.
This warning message is customizable using Group Policy. After a Remote Assistance connection has been established and both computers have entered the Screen Sharing state, the User and Helper are able to perform the tasks listed in Table One challenge this poses is that it can be difficult to establish P2P connections if one or both of the computers involved are behind a gateway or router that uses NAT.
NAT is typically used to map a set of private IP addresses to a single public IP address or to multiple public addresses. Home networks using a wireless or wired router also use NAT technology. To overcome this difficulty, Windows 7 and Windows Vista include built-in support for Teredo, an IPv6 transition technology described in RFC that provides address assignment and automatic tunneling for unicast IPv6 connectivity across the IPv4 Internet.
For most small business and home user environments, Remote Assistance in Windows 7 and Windows Vista will seamlessly traverse a NAT-enabled router with no additional router configuration required. For information on enterprises that need to remotely support users who work from home, see the section titled "Other Possible Remote Assistance Usage Scenarios" later in this chapter.
Beginning with Windows 7, Remote Assistance can also connect across certain types of symmetric NATs, but only if the other computer is not behind a symmetric NAT as well.
Remote Assistance will not work if the NAT-enabled router is configured to block the specific ports used by Remote Assistance. See the section titled "Remote Assistance and Windows Firewall" later in this chapter for more information. To determine the type of NAT a network is using, open an elevated command prompt and type netsh interface teredo show state. For more information on IPv6 support in Windows 7, including built-in client support for Teredo and other IPv6 transition technologies, see Chapter The ports used by a Remote Assistance session depend on which version of Windows is running on the two computers involved in the session.
The Windows Firewall is configured with a group exception for Remote Assistance. This group exception has multiple properties that are grouped together as part of the Remote Assistance exception.
The Remote Assistance exception properties will change depending on the network location of the computer private, public, or domain. For example, the default Remote Assistance exception when the computer is in a public location is stricter than when the computer is in a private location.
Some preconfiguration, as discussed in my prior blog, is essential. NOTE: A novice can accept a remote assistance offer from an expert only if the associated Group Policy is enabled and the helper list is populated in advance. To offer assistance without an invitation via the GUI interface, the expert should click on the Help someone who has invited you option. Then select the Advanced Connection option for help desk at the bottom of the panel. Microsoft Remote Assistance is also available via the command prompt.
The Remote Assistance GUI enables connectivity between standard users, and offering assistance from the command line works from standard permission levels as well.
Once the Easy Connect password has been exchanged between two machines, it should not be necessary to use the password to connect or offer assistance for subsequent sessions, unless the DNS resolution, IP address or other system authentication elements subsequently change.
The command line interface will default to use of Easy Connect if it has been previously established. Note that the switch is not case sensitive, though I have typed it this way to help you avoid the most common syntax error. The most common problem is larger networks and across firewalls, is the establishment of appropriate Ports. NAT is supported, if the appropriate protocols are supported on router and firewall interfaces. Checking remote system visibility via ping, tracert or pathping are obvious tests while in the cmd window.
Sorry this didn't help. Thanks for your feedback. This is my test setup: Windows corporate domain. Helper and target PCs both running Windows 7 Professional bit.
Both PCs on same subnet actually on adjacent desks. Firewalls on both PCs have default Remote Assistance rules enabled. Helper runs MSRA. At this stage Event Viewer on the target PC shows raserver. Nothing else appears on the target PC, i. Check the following: Do you have the correct permissions on the remote computer [I have].
Is the remote computer turned on and is it connected to the network [Yes and Yes]. Is there a network problem [No].
0コメント