July 21, 2011 at 2:00 pm
Here's the deal. I'm in the midst of implementing a sharepoint setup. I ran a test environment (all stand-alone) and got scripted powershell backups working (woohoo!).
Now I'm trying to implement them in a production environment where the environment is a little different.
SharePointServer
- SharePoint Services
SQL Server
- Content Databases
- Local backup location
The script is very simple, it backs up the whole farm locally to the SQL Server C:\. I run it from powershell (as administrator) and it runs fine. I created a batch job that calls the .PS1 and it errors out. The error states that I need to be a local admin to run that command. If I run the batch file as administrator, it works.
Now, I've created a scheduled task to call the batch file. The task runs under the SharePoint service account with the highest privileges checked. The SharePoint service account is a local administrator on both servers. It still fails with an SQL failed login error "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: <SharePointServerIP>"
For some reason it looks like there is a local account from the SharePoint server trying to log into the SQL Server instance. For the life of me, I can't figure it out! I've done everything I can think of or can find on teh intarwebs. Has anyone run into this problem before or might be able to point me in the direction of a solid SSC-esque sharepoint help forum?
July 21, 2011 at 2:01 pm
July 26, 2011 at 11:22 am
Have you checked the usual culprits?
Disable UAC and make sure that Kerberos is working correctly. I know I've had issues with both of those at various times with scheduled tasks.
Other than that I know that PowerShell has a bit of a funky permissions model, you may just be missing a "grant permissions to execute on the third Tuesday of Lent unless it's a leap year" kind of permissions grant on the PowerShell script.
-Darren Wallace
August 3, 2011 at 10:23 am
2 minutes into the 12th and final round, calvo was beaten and bloody. His manager about to throw in the towel when Calvo suddenly showed a little spark! SharePoint had beating on Calvo for twelve rounds now. Calvo suffered a broken nose, some bruised ribs, and his confidence had been smashed.
All of a sudden out of nowhere, Calvo throws a looping hay-maker to SharePoint's backup job and to everyone's surprise, SharePoint was down!
1..2..3 .... .... 9.......10!
SharePoint was knocked out in the last minute of the championship fight leaving Calvo standing in victory!!!
I think Ninja will get a good chuckle at this if he ever reads it. The problem was staring me in the face the whole time. For almost 2 weeks I had been researching this trying to figure it out. I ended up deleting the task scheduler job and recreating it. I get through the pages and I see on the general tab where it says "Run whether user is logged on or not." (which I always checked). Just below it is a check box that says "Do not store password...". Forever I was checking that thinking it is safer to not store the user's password on the server. Only today did I notice the rest of the sentence "...The task will only have access to local resources."
d'oh!!!
I was copying the task from the original (standalone) server. Of course it would work fine on the standalone, it's all local!!!
August 4, 2011 at 9:09 am
I got a chuckle...nice.
Been there done that...struggle all day, come in the next day and, D'oh, I should have thought of that. 😀
August 4, 2011 at 10:06 am
Yup, nice chuckle :w00t:.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply