August 24, 2012 at 9:40 am
OPC.Three..
The difference I see between your setup and mine from this is that I'm using a Domain account, rather than a local machine account.
Do you get the same behaviour with a Local account as with a Domain one?
I've set the perms on the root of the WMI tree, and so far nada. All the changes in the scripts that have been linked to are stages that I've followed to date, but it's still not happy. If it's not repeatable elsewhere with a domain account as a proxy (2008 functional level), then I'll spawn more text boxen here and see if there's a flaw in domain or local config.
But, again, perplexed on the running on this; the SQL Server Agent is running as a domain account, and the proxy is a domain account.
The last error I got from this was the system telling me that it wasn't happy with the way that the PnP subsystem was being accessed, which is a remote symptom of 2003+ trying to access as an unprivileged user.
I don't get this when running as the SQL Agent account itself, which has less privileges generally now than the proxy account..
August 24, 2012 at 10:14 am
Rich James (8/24/2012)
OPC.Three..The difference I see between your setup and mine from this is that I'm using a Domain account, rather than a local machine account.
Do you get the same behaviour with a Local account as with a Domain one?
That is a valid point so I just tried this with a Domain Account and it did work. Here is what I did:
- Drop the test Agent Job
- Drop the test Proxy
- Drop the test Credential
- Create the Credential with the Domain Account (only has access to server based on MyServer\Users Local Group containing MyDomain\Domain Users Domain Group)
- Create Proxy using Credential
- Create Agent Job with PowerShell Step that uses Proxy
- Ran the job -> step output contained 'Access Denied'
- Granted WMI Control Remote Enable permission on ROOT\CIMV2 namespace to my domain user
- Ran the job -> step output contained volume info as expected
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
August 24, 2012 at 10:47 pm
Thanks OPC.Three.. That points to the problem being local to us.. Much appreciated you spending the time to replicate this and provide proof that it should work..
August 26, 2012 at 8:53 am
No problem. Happy to help. I am learning from this too.
Maybe you could try it with a local login just to see if you can isolate it to being a domain login issue. I am no expert on Domain Policy but maybe it affects a domain login different than a local one.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
September 3, 2012 at 9:16 am
Hi OPC.. I've tried the code from your earlier posting. While it registers a success (in the SQL Server Agent result), I added my usual logging to the process (always send to a text file), and got the following text within the log file:
The job script encountered the following errors. These errors did not stop the script:
A job step received an error at line 1 in a PowerShell script. The corresponding line is '$Volumes = get-WMIObject WIN32_Volume |where-object {$_.FreeSpace -ne $null};'. Correct the script and reschedule the job. The error information returned by PowerShell is: 'Access denied
Do you get a clean process log file too?
September 5, 2012 at 10:05 pm
Sorry for the delay. This one was covered by new emails in my inbox and I am just getting to it. I did not try piping the output to a log file however the 'step output' captured in the job history showed the expected output. Essentially I captured the wmi object to a variable same as what you have then I simply dumped the variable on the next line as:
$Volumes
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply