|
I'm not super savvy with Windows Server, but I'm working in a place that has Server 208 R2 and about 8 client workstations. On a workstation (I believe all behave the same), if I try to do something that raises a UAC prompt, like Task Manager's "full" view, I use the server's Administrator username and corresponding password. I can get in via RDC with the same creds. BUT, when I try to install software that I've downloaded to the workstation desktop, like a Flash update, I get the UAC prompt... BUT the exact same creds don't work. IF I run the same exe from the C: root or elsewhere, it works fine. Edit: Ah, I've just now realized that this related to the fact that this user's cardinal folders (Desktop, Docs, etc) are redirected to \\server\du\<username> so that's got to be a factor. What am I doing wrong, or how can I fix this? Is it just a matter of using that User's creds at the UAC prompt when running exes from the Desktop?
|
#
?
Jul 8, 2015 22:17
|
|
|
|
| # ? May 5, 2024 18:03 |
|
|
Wherever you are storing the executable is either not accessible to your admin account, or the way it's location is presented doesn't carry across accounts (like a mapped drive). Find a better location than the desktop to save these things, or better yet look into something like PDQ Deploy for things like Flash updates.
|
|
#
?
Jul 8, 2015 22:53
|
|
|
Thank you for your reply. I figured the workaround is to run the exes from C: root or anywhere other than a redirected cardinal folder (actually, it looks like only Docs and Desktop are directed to the sever). Is this common? Is it supposed to be this way? I've worked on SBS2k3 environments where the clients couldn't install stuff unless then had the Administrator creds (by design, of course), but I've never come across a situation where the Server's main/master Administrator account creds wouldn't fulfill UAC...
|
|
#
?
Jul 8, 2015 23:08
|
|
|
Is this an admin account local to the machine or a domain admin? I put this sort of junk in \\server\departments\department or \\server\appdeploy$ depending on what it is and what installs it
|
|
#
?
Jul 8, 2015 23:28
|
|
|
Domain admin. That is, when I run an installer and get the UAC prompt, I use the same username and password as I would RDC-ing into server or logging on to the server itself with keyboard and mouse. Given the above, it will run if I have the .exe anywhere but the redirected Desktop and Documents (which go to / are \\server\du\<username>\<folder> Otherwise, the UAC prompt just returns. Thinking out loud, could group policy be causing this? Thanks for answering the questions of a not-so-server-savvy goon. Tapedump fucked around with this message at 04:21 on Jul 9, 2015 |
|
#
?
Jul 9, 2015 04:17
|
|
|
Check the profile tab in AD UC to see if a path is specified for a roaming profile. Do a gpresult to see what group policy objects are being applied, then go in and see if folder redirection is something any of those GPO's are pushing down. That or maybe redirected profile folders to a server with incorrectly ordered permissions or something? If either are enabled, I'd start looking at the paths and permissions to make sure everything looks right.
|
|
#
?
Jul 9, 2015 15:34
|
|
|
|
| # ? May 5, 2024 18:03 |
|
|
Thank you very much. I won't be back there for another week or so, so my follow up may take time.
|
|
#
?
Jul 9, 2015 17:08
|
|