1) About UAC, I agree with your statement about the Administrator Account. However, I don't necassarily agree with your statement about Domain Accounts that are local administrator. They, like all other accounts, (minus the Administrator Account) are subject to UAC. When you are a Domain Admin or any other sort of Administrator on a machine you will be prompted for Consent to install an application.
2) Your find is interesting. In my scenario (at first) I couldn't get the push working so I installed the LANDesk Agent manually by running it from the the core share. Because of this, it had the agent on it at one point or another. Afterwards I believe I uninstalled it then just deleted it from inventory and tried again with the push. What I'm interested in attempting is trying another machine with Windows 7 that has not had any mention of the LANDesk Agent on it. Then I will try to just push the agent out without changing any of the GPO settings for UAC.
Thank you for working with me on this!
Okay, I've tested your theory and I believe you're on to something.
I've taken a newly installed Windows 7 machine and pushed the Agent on it. The only thing that is configured is the Scheduler Service has a Domain Admin account in it. The installation works fine.
However, when it's a machine that HAS had the Agent on it, you can only get the push to work if UAC is configured not to prompt for consent.
Interesting........ Will you work with your team to look into that issue?
I will try to replicate this, but I am still of the belief that the problem is one of recognition of the computer with either outdated information or a duplicate device. Can you take that device that you just pushed an agent to and then either uninstall the agent or simply push a new one over the top (following whatever caused the issue before) and let me know the results?
If you include the steps to follow I'll also do the same thing and let you know what I find out.
Okay, here's what I've got.
Go to LDMAIN Directory, run UninstallWinClient.EXE
Go to the Core, Delete the machine in the pending umanaged device discovery and in the previous Agent Deploy Scheduled Task
Run Unmanaged Device Discovery, found the machine.
Dragged machine to the Scheduled Agent Deploy task.
Agent Failed: Unable to contact the specified machine. THe machine may be off or unreachable
What annoys me off about this.... this is not the result I anticipated receiving. I expected to see Agent could not be copied.
so, what is odd about this is two things. One I can get to the admin$ share on the client machine yet it's saying it's off or unreachable.
The 2nd thing is that when I deleted the item from pending unmanaged device discovery and the scheduled task itself, then run a scan for that computer, the scan updated the device rather than adding it. However it appeared in the Computers section in UDD.
Any reason you could think the core is not seeing my machine we were testing? I'm using wireshark and I see the ARP request go out: Who has 192.168.0.7?
It appears that 192.168.0.7 just isn't responding back.
it seems something related to the GPO or local security policy applied to your core.
1-Verify that the Scheduler service is not running as LocalSystem but impersonates a domain administrator that has rights on the devices
2-In the installation folder (not where you installed LANDesk but from where you installed it) you'd find a DOCS folder.
There you'd find a file called LDMSDeploy.pdf.
In this file look for gpedit.msc: you will find a list of local security settings that you need to set on the core server and make sure the core server is not inheriting
GPOs from the domain.
After reading this thread, a couple other things I noticed weren't mentioned.
Does your antivirus/spyware/etc solution block applications or file/folder characteristics? For the folder to appear and then disappear, it sounds like it might have been blocked or quaranteened.
Is there a vpn solution installed that might include a firewall or something alike?
If it works on 1 machine and not another, go in to gpedit and compare the security configurations, especially for the network access area. There is one for "sharing and security model" that has caused problems for me in the past. If its set to "classic" everything works as it should.
Are there any messages in the event logs that would indicate a hardware problem, specifically the hard drive or memory? Also, in the security logs, you might see account logon/off failures that might indicate a blocked account or a problem with the account (bad password, etc).
Sooner or later I will get a project to deploy 3000+ nodes with 50% of them are using Windows Vista & 7 with no domain/AD environment. Turn off/disable simple file sharing, UAC, firewall or etc is not feasible for this enviroment unless we have so many man power to install agent package manually without turn it off all the built in security functions from Windows Vista & 7.
Is any of one you have an idea, suggestion or good advise for this implementation?
Well, without intentionally sounding sarcastic, 3000+ nodes in a work group with the intended security settings in place is going to be difficult to manage in the extreme. You will have no idea how the end user has modified their machine and no means to reconfigure it back. You will also have no means to enforce the agent remain on the machine even if there has been a successful install.
You could try adding the target machine's local administrator account to the alternate credientials in the scheduler tab and then try pushing the agent with UDD. Be sure to update the agent config with the IP of the LANDesk server so that once installed the machines can communicate back (the computer name or FQDN probably won't do). About the only other thing I could think of is that if you know the local administrator account for each of the machines, you could use a script to map a drive to the machine and execute a remote install from there. Other than that, e-mail the end user with a URL to the installer and just continually pester them until they do it.
Any more info on this guys? I'm having a very similar issue with agents. Agents that previously installed during OSD on Windows 7 machines are not responding and when I try to push out new agents, they fail. The same mkdir command is failing.
Anything else you have discovered would be useful.