Skip navigation
1 2 3 Previous Next 24923 Views 35 Replies Latest reply: Dec 9, 2010 2:07 AM by skopylov RSS
Apprentice 250 posts since
Sep 4, 2008

Has received 1 of 9 achievements.
Currently Being Moderated

Feb 24, 2010 9:00 AM

LDMS 9 - Agent Failing when Pushed

I have a question regarding my LDMS9 Test Environment. I've successfully discovered a device using Unmanaged Device Discovery within my small 2 PC / 1 Core test environment. After I discovered PC1 I wanted to push the Agent I created out to it. When I do so the Scheduled Task fails. It states Unable to contact the specified machine. The machine may be off or unreachable. Well, the machine is on and is pingable from the core. Anyone have any suggestions to why this may be failing?

 

Other notes: PC1 is a Windows 7 Machine and these computers are in a a WORKGROUP.

  • Mach6 Employee 637 posts since
    May 23, 2008

    Has received 6 of 9 achievements.
    Currently Being Moderated
    1. Feb 24, 2010 11:55 AM (in response to Stoj)
    Re: LDMS 9 - Agent Failing when Pushed

    There's an article that was written about this, but it looks like it's not been made public yet.  The information isn't secret, so I'll bring it over here:

     

    Problem:

    Windows Vista and Windows 7 implement security options that are enabled by default that make pushing the agent to a machine straight out of the box nearly impossible.  The security options are in addition to the Windows firewall that was introduced in Windows XP SP2, and include User Account Control (UAC) and particularly how UAC interacts with authentication from a network source.  Understanding how UAC works can allow us to determine the best method of installing the agent to devices with UAC enabled.

    Cause:

     

    User Account Control (UAC) is a new security feature in Windows Vista and Windows 7.  It allows accounts with administrative rights to be able to run under limited rights, while allowing them to elevate the rights to a higher level on an as needed basis.  The limited set of rights is not able to install the LANDesk agent.

     

    There is a number potential problem when dealing with UAC while attempting to install the LANDesk agent.  It is that when you attempt to run a task on a device with UAC enabled and that task is initiated from another machine (such as the core server attempting to run an agent install on an unmanaged client machine) the default behavior is to always authenticate the user in the limited context, rather than the administrative context.  In this scenario there is no UAC prompt to elevate credentials, so the task does not have a chance to succeed.

     

    Resolution:

     

    There are four known methods to successfully push an agent install to a Windows Vista or Windows 7 workstation.

     

    1 - Use a domain account with administrator rights to the local machine.

     

    Domain accounts do not have a limited local context on the client machines, so a domain account with administrative rights will always connect as a local administrator and will have the ability to install the agent.

     

    Note:

         This does not need to be a domain administrator, just a domain account with local administrative rights.

         This is the preferred method, because it is the only one that will not require modifying settings on each individual machine prior to pushing the agent.

         This option requires an Active Directory environment

     

    2 - Modify the registry to make network authentication attempts authenticate with the administrative rights, rather than the limited user rights.

     

    To make this change you need to create the following DWORD value in the registry, because it is not there by default:

     

    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy

     

    Setting the value to 1 allows local administrative accounts to authenticate over the network in the administrative context.  A setting of 0 reverts to the default behavior of only allowing local administrator accounts to connect over the network as a limited user.

     

    3 - Enable the default Administrator account and use its credentials

     

    The default Administrator account has UAC disabled by default, and will always authenticate with administrative rights, because it does not have a limited context. Note: This setting can be changed in a group policy making the default Administrator account have the same limitations as all other local Administrator accounts, so if that setting is changed then this option will no longer work.

     

    4 - Disable UAC

     

    Disabling UAC will make it so there is no limited context for any administrative account, so any account with administrative rights (whether domain or local) will function as an administrator.

    Conclusion

    Due to the newly added security feature called UAC, which is found in Windows Vista and Windows 7, it is more difficult to push the LANDesk agent to unmanaged devices.  Other than the 4 options listed above there is no known method to push a LANDesk agent to an unmanaged Windows Vista or Windows 7 workstation.

  • Mach6 Employee 637 posts since
    May 23, 2008

    Has received 6 of 9 achievements.
    Currently Being Moderated
    3. Mar 5, 2010 3:25 PM (in response to Stoj)
    Re: LDMS 9 - Agent Failing when Pushed

    Scheduler service.  It would need to be a domain account that has local admin rights.

  • Expert 137 posts since
    Jan 21, 2009

    Has received 6 of 9 achievements.
    Currently Being Moderated
    5. Mar 5, 2010 4:19 PM (in response to Stoj)
    Re: LDMS 9 - Agent Failing when Pushed

    Login to a computer with the credeintials you used for the Landesk Scheduler Service. Then try to get to the C$ and Admin$ share on the windows 7 machine you are trying to deploy the agent to.

     

    You might also look at using the advanced agent. http://community.landesk.com/support/docs/DOC-1100

    I have seen sucess on windows 7 clients with the advanced agent where the normal agent fails.

  • Currently Being Moderated
    6. Mar 7, 2010 1:48 AM (in response to Stoj)
    Re: LDMS 9 - Agent Failing when Pushed

    Is the Simple File Sharing set to disable?

  • Currently Being Moderated
    11. Mar 9, 2010 6:38 PM (in response to Stoj)
    Re: LDMS 9 - Agent Failing when Pushed

    How about the account that have administrator rights inside Service -> Scheduler?

  • Mach6 Employee 637 posts since
    May 23, 2008

    Has received 6 of 9 achievements.
    Currently Being Moderated
    14. Mar 11, 2010 12:51 PM (in response to Stoj)
    Re: LDMS 9 - Agent Failing when Pushed

    Hi Paul,

     

    There are a few accounts that act differently than others according to the UAC model.  One is the built in Administrator account (that is disabled by default).  Out of the box with no customizations that account is set to not have UAC running for it.  It is (in essence) a super-Administrator account.  The other kind is domain accounts.  A domain account should not have any UAC limitations on it because it does not have the concept of a limited user context.  In my lab I've been able to successfully deploy to domain machines by using a domain administrator account.  Local administrator accounts are different.  Any local account is (by default) granted its limited user rights, with no option for a UAC prompt to show up.  This is obviously done as a security measure.

     

    Here's what's interesting: The folder is showing up on the C: drive, which requires elevated priveleges.  That indicates that we do have the necessary rights.  I had this situation happen in my lab if I either had a duplicate of the device in question, or if my device was listed in the inventory (either bare metal import, or a device that used to have an agent that had been reimaged), but the device name or IP Address didn't match.  In that case the $ldcfg$ folder would appear for a few seconds and then disappear.  I believe we run a check from the device to make sure we are talking to the device we think we should be talking to.  Since the name and/or IP Address and/or MAC Address didn't match up the executable thinks it's in the wrong place, the folder gets cleaned up, and the console reports that it can't find the device.  Is this scenario a possibility for you?

1 2 3 Previous Next

More Like This

  • Retrieving data ...

Bookmarked By (1)

Legend

  • Correct Answers - 20 points
  • Helpful Answers - 10 points
LANDESK Community powered by Jive SBS® 4.5.7.1  |  Legal Notices  |  Privacy Policy  |  Icon 

TweeterOn Twitter  |  Icon FacebookOn Facebook © 2007 LANDESK Software