Remote to a user PC I do not see active users desktop

If you have LAG rights from AD, you should see what you need to see. I'm not certain why you're having problems with that, but some things you can check on are:

• Do basic network troubleshooting and follow the OSI model up from the bottom.  Some basic ideas:
  • Confirm the MAC address of the target PC matches the MAC and IP address and DNS entry you're attempting to reach.  If any one of those three are incorrect or stale (DNS and DHCP records are notorious for becoming out of sync if the DHCP/DNS server relationship is passive instead of active).  If this is the cause, you'll may be reaching out for
    • The PC's DNS entry, but it will be associated a different address, meaning you're trying to get to a different computer than you expect.
    • The PC's MAC address is associated with a different IP address (DHCP/DNS is stale), meaning that, once again, you may be trying to reach one computer and the network is redirecting you to a different one.
  • Look into your DHCP server after talking with the end user on the problem PC and learning their MAC address of the NIC they are using (wired vs. wireless).  Confirm that MAC address is using the IP address you expect.  Update it if it's stale.
  • Look into your DNS server to verify it has the right IP address associated to the device name.  Delete bad entries and update/correct/create the right ones so this doesn't bite you again in the future.

Tracking the MAC address from the actual target PC (making sure you're trying to connect to the correct NIC--wired, preferably, but wireless if that's how it's connected to your network) may reveal the problem.  If the MAC/DNS entry/DHCP entry belongs to the wired NIC, but the target computer is using its wireless NIC, you'll need to get the records updated, or manually discover the MAC and DHCP IP address leased to that NIC.

I've fought that problem for going on 30 years.  A well-designed and properly deployed IP address scheme and great training for Desktop Support people and end users can help reduce it.  If your Desktop Deployment people are working hand-in-hand with your IT Security and Network Admins and Sysadmins, your company should have a great "onboarding" process to ensure every NIC's MAC addressES (note there may be more than one MAC address on a NIC or in a laptop or PC) are recorded and entered into your NAC.  I've used Cisco ISE with great success to ensure the right devices and people have the appropriate access, and ISE can tie into Splunk and PRIME and Infoblox to ensure you have accurate information in DNS and DHCP. 

It's not easy until your organization has it all set up and documented, and all the right people have been trained and are up to speed with the process.  It just gets harder as you add more people and computers and support staff to your network if the people have the right training & documentation.

Here's hoping these ideas will get you on the right track.

Once you discover the actual cause of the problem, and you've overcome or fixed it, please post your discovery here so we all can learn from your adventure.

Swift Packets!

Rick Schroeder

If you have LAG rights from AD, you should see what you need to see. I'm not certain why you're having problems with that, but some things you can check on are:

• Do basic network troubleshooting and follow the OSI model up from the bottom.  Some basic ideas:
  • Confirm the MAC address of the target PC matches the MAC and IP address and DNS entry you're attempting to reach.  If any one of those three are incorrect or stale (DNS and DHCP records are notorious for becoming out of sync if the DHCP/DNS server relationship is passive instead of active).  If this is the cause, you'll may be reaching out for
    • The PC's DNS entry, but it will be associated a different address, meaning you're trying to get to a different computer than you expect.
    • The PC's MAC address is associated with a different IP address (DHCP/DNS is stale), meaning that, once again, you may be trying to reach one computer and the network is redirecting you to a different one.
  • Look into your DHCP server after talking with the end user on the problem PC and learning their MAC address of the NIC they are using (wired vs. wireless).  Confirm that MAC address is using the IP address you expect.  Update it if it's stale.
  • Look into your DNS server to verify it has the right IP address associated to the device name.  Delete bad entries and update/correct/create the right ones so this doesn't bite you again in the future.

Tracking the MAC address from the actual target PC (making sure you're trying to connect to the correct NIC--wired, preferably, but wireless if that's how it's connected to your network) may reveal the problem.  If the MAC/DNS entry/DHCP entry belongs to the wired NIC, but the target computer is using its wireless NIC, you'll need to get the records updated, or manually discover the MAC and DHCP IP address leased to that NIC.

I've fought that problem for going on 30 years.  A well-designed and properly deployed IP address scheme and great training for Desktop Support people and end users can help reduce it.  If your Desktop Deployment people are working hand-in-hand with your IT Security and Network Admins and Sysadmins, your company should have a great "onboarding" process to ensure every NIC's MAC addressES (note there may be more than one MAC address on a NIC or in a laptop or PC) are recorded and entered into your NAC.  I've used Cisco ISE with great success to ensure the right devices and people have the appropriate access, and ISE can tie into Splunk and PRIME and Infoblox to ensure you have accurate information in DNS and DHCP. 

It's not easy until your organization has it all set up and documented, and all the right people have been trained and are up to speed with the process.  It just gets harder as you add more people and computers and support staff to your network if the people have the right training & documentation.

Here's hoping these ideas will get you on the right track.

Once you discover the actual cause of the problem, and you've overcome or fixed it, please post your discovery here so we all can learn from your adventure.

Swift Packets!

Rick Schroeder

Thanks Rick, I clarified my issue.

Excellent!   Now that you know you're connecting to the right PC, you've identified the problem:  The tool you're using to remote to it is not doing a screen share between the user's desktop and you.  It's doing a much more basic action of letting you log on to that computer--not share it with the user.

Your tool should pop up a window on the user's desktop that asks them to provide permission for you to share your screen.  It's not.

Identify your tool, Google the symptoms, see if something needs to be installed on the destination PC, or perhaps a Registry or Group Policy / AD function needs to be modified to allow sharing instead of remotely logging into the computer.

I'm confident you'll find the problem is with your screen share application, either on your computer or on the target computer.  Or it's a security issue that needs to be adjusted.

Let us know what you discover.  I'm betting it's something basic, and you'll have a private face palm moment (if you're anything like me).

Swift Packets!

Rick Schroeder

Lets back way up. I have been using the  DameWare platform for at least 15 years. Way before SolarWinds owned it.

At a previous company we could remote directly onto a users PC in the domain without them giving permission and we saw their desktop and we corrected issues they where seeing.

Different company now but same scenario, just looking for the correct security settings. As I have no contacts at the previous place.

Apart from admin rights, no other rights are needed to view active users on remote desktops. Tools like on premise R-HUB remote support servers or Logmein etc. help in monitoring the users remotely.