The remote user has access to the exact same resources as the local user. This can be both a benefit and a hazard. The benefit is that the remote user can see exactly what's going on without running into permissions problems. For example, a number of times, I've tried to help a user, but I wasn't initially able to re-create the problem because it was related to insufficient permissions and I had administrative rights. Another benefit of common permissions is that if you've done a good job of implementing a tough group policy, it should be impossible for a remote user to do anything to damage the system, because the remote user won't be able to do anything that the local user doesn't have permission to do. On the other hand, common permissions can also prevent a support tech from being able to correct the problem because the local user may not have the necessary privileges. Other means of managing Remote Assistance
Along with controlling inbound and outbound traffic on port 3389, there are other ways the IT department can control Remote Assistance. For example, administrators can disable Remote Assistance at the individual workstation. If your organisation uses an Active Directory Windows 2000 Server environment, you can use group policies to manage Remote Assistance. These policies can:
So what's the moral of the story? In a word, plan. Before your help desk embraces Windows XP's Remote Assistance, examine your current network structure, consider the time involved in administering Remote Assistance, and evaluate the security implications. As with any IT project, you should consider alternative products, such as pcAnywhere, Virtual Network Computing, and Microsoft's own Systems Management Server (SMS) or Remote Desktop, before making a final decision.
Have your say instantly in the Tech Update forum.
Let the editors know what you think in the Mailroom.
