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.
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:
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.
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.
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.
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:
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.
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.
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.
Okay, so after playing with the group policy settings for the windows firewall, I was able to shut it off completely. With that said, I have the Windows Firewall Off and Simple File Sharing turned off. Still I'm receiving: An error occured while copying the agent software"
One thing I noticed if you don't have Group Policy shutting off your firewall. If you turn the Firewall off locally, then turn Simple File Sharing off, the Firewall comes back on.
So I may have discovered something here but I'm waiting ot get word from LANDesk on another issue to test this once more.
The reason this Agent is failling is because of UAC.
If you're not familiar with UAC, it has two different options in terms of elevation. If you're logged in as a basic user and are trying to perform an administative task you will be prompted with a credentials box. The credentials prompt/box is where you would enter Administrative credentials to "Elevate" yourself. Now, on the otherhand, when you are an administrator and you try to perform an administrative task you are prompted with a consent box. The consent prompt/box basically just asks you, do you want to run this, yes or no. Both of these features are default in UAC.
Okay, now that UAC is briefly explained the question is how does this relate to LANDesk. When you run the Scheduler Service as a Domain Administrator what is happening is the LANDesk Agent is trying to install as an Administrator. By default, you are then prompted for consent. Well, in actuality, the consent box doesn't appear the Agent just decides to fail.
What needs to be done:
I've discovered in GPO there is a setting for UAC called: Behavior of the leveation prompt for administrators in Admin Approval Mode. By default this setting is Prompt for Consent. If you choose the option Elevate without prompting the Agent will install just fine.
Does this pose a security risk? Yes. Should you be running your machine as an Administrator? No. So as of right now I believe this is the best solution I have found.
Let me know what you guys think
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?