I opened Sharepoint 2010 Central Admin and as per normal, was prompted for my login details. As I did not know the details, I closed after a few guesses/changing the default account.
A few hours later, remembering the password, I try again but get a 503 Service Unavailable.
I check the app pools in IIS7 and see that the SharePoint Central Administration v4 app pool is off. I turn it on, close IIS7, but it turns off again. Its settings look good to me:
Enable 32-bit applications Off
Start Automatically True
Enabled True
However, the application event log tells me that the account I was using to access Central Admin, and used by this app pool, has now expired (it's a local account so I did not know this will happen). This also impacts all other services such as SQL Server etc. How can I change the account of the app pool, but also change all of the other service accounts?
The credentials used for the account [name] expired on 1/9/2010 1:33:39 PM, and need to be updated. If they are not updated, the system may stop working. The account is used by the following:
Farm Account
Microsoft SharePoint Foundation User Code Service
User Profile Synchronization Service
Web Analytics Data Processing Service
Security Token Service Application
Application Discovery and Load Balancer Service Application]
I assume updatefarmcredentials will fix this. I tried the following:
stsadm.exe -o updatefarmcredentials -username sysaccountname -password pwvaluehere -local
This results in a "command line error". What is the proper syntax?
You can also just change the current System Account password in AD or Computer Management, and mark it to not expire.
When it comes to the stsadm command, it is userlogin not username, unless that changed in 2010. (Source)
Related
I'm trying to connect the User Profile Service (UPS) to AD using an account with the proper permissions. When I click the Populate button, the AD forrest immediatly appears, but I cannot expand it. If I select the entire forest the process times out.
The error message on screen says it is a client machine time out. There are no entries in ULS or the server app or system logs.
I've tried upping the default 300 to 3600 in the web.config files which didn't help. I have the exact same setup in my test farm, which makes me wonder if the problem lies with the UPS.
Both UPS services are running, both FIMs are running
Problem solved! Turns out there is a local security policy for LDAP that was set to Negotiate and should have been off.
I am getting error while publishing the 2013 workflow via designer. Also, under sharepoint designer if I try to delete any workflow then the page just refreshes and the workflow does not get deleted.
I checked the services.msc and found that the workflow backend service was stopped. (this happened as the password of the user under which this serivce was running had changed).
So, the network admin changed the service user to LOCAL SYSTEM and started the service.
Now, the workflow backend service is started. We have also ran the iisreset.
However, I am still getting the same error:-
System.IO.InvalidDataException: A response was returned that did not come from the Workflow Manager. Status code = 503: Service Unavailable
Service Unavailable
HTTP Error 503. The service is unavailable.
Client ActivityId : ee94689c-4e08-b055-fe9c-268d7a94
Please find attached snapshot.
Is the error as a result of the change in service user? Can you tell me what priviledges should the account running the workflow backend service must have?
UPDATE 1
We have tried to set the account to farm admin and also tried to set it to site admin. Now, for a new web application, I can delete workflows. However, for existing site, I am not able to delete the existing workflows.. Also, I am not able to publish workflows (present under new and previous sites) and the error is same as described earlier.
Open IIS and make sure identify of the WorkflowMgmtPool is correct, you can re-type the identify. Then make this pool is started.
Check and reenter credentials for:-
Open Services.msc, find Service Bus Message Broker service and Windows Fabric Host Service. Make sure they are running. If not, firstly, start Windows Fabric Host Service, then start Service Bus Message Broker service. If Service Bus Message Broker service is started, stop and re-start it.
Reference- this forum link
This error occur because you have not registered the workflow correctly. Re-register the workflow and it will get solved. Also make sure you have activated the App management Service in your site features.
http://designerworkflow.blogspot.in/
Workflow Manager CU2 to get to 1.0 Refresh in Web Platform installer worked first time for me!
http://support.microsoft.com/kb/2902007/en-us
I had this same issue.
I was able to resolve it by going to IIS on my application server, editing the identity on the Workflow Management Application Pool, saving it and restarting it. I also restarted the server.
I've setup a special user account for MSDeploy connections. The user is a member of the local Administrators group.
MSDeploy fails with ERROR_USER_UNAUTHORIZED when I use this account and yet it works fine with my own account, which is also an administrator, via a domain group.
In the IIS Management settings, this new website is not listed and so my account doesn't receive its rights via config, I believe its implicit via my admin rights. So why doesn't the dedicated account work?
What I'm learning, from day after day and $1000s worth of consultancy time, is that MSDeploy is another Microsoft over-complicated anti-pattern, we should stick to RoboCopy and not cave in to 'right way' BS.
Have you checked event log for MsDeploy? It could contain possible answer :).
I assume you are using Windows 2008 Server, not Windows 2012 Server?
Try specifying explicitly the authType=Basic token for the -dest parameter (or /A:Basic command line switch in case of .cmd deploy script). Though the documentation claims that WMSvc method uses by default basic authentication I've recently found this is not (always) true.
I have a newly configured SharePoint 2013 farm and my application pools continue to crash (stop). I have these accounts added into Local Policies and Domain Policies for "Log on as Batch" and "Log on as Service". The app pools in Windows Logs are coming back with errors about credentials being invalid. I've never changed the app pool account passwords and in AD, they're set to never expire. The accounts are not locked inside AD either. It takes about 30 minutes of inactivity on the servers for an IISReset /noforce to bring them up.
These app pool crashes happen a couple times a day and appear to be desyncing with active directory somehow. Changing the passwords to the unchanged password in IIS and PowerShell does not work because is claims the password is incorrect. Have anyone come across this and have any ideas?
Is it possible you are getting a false error? A common reason for application pool recycles is bad code in optimizations that doesn't clean up after itself.
What user context do SharePoint timer jobs run under? The farm account?
I'm going to be accessing some external resources (network share) via the timer job, so I need to know which SharePoint service account to grant permissions.
Yes, in all documents in Technet, it's "SharePoint farm account".
In fact, it's the user which run the OWSTimer job.
The windows identity will be as described above, i.e. the identity of the OWSTimer service. In accessing SharePoint resources, however, a SPTimerJob will use the SPUser identity of SharePoint\System. You can check this by creating a timer job to modify a list item - the "modified by" user friendly name will be "System Account" not the domain\user windows identity of the OWSTimer service.
I believe so.
According to this blog post, http://meenrajan.blogspot.com/2008/08/sharepoint-timer-job.html you can check the identity of what's running it by doing the following:
"you may go to the Task Manager, and find the w3wp.exe process that is running and see what account it has been using to figure out what was the account used to run the job.update(). Otherwise, you can also, do a SQL Trace on your Sharepoint Configuration Database and find the account used"