Sharepoint 2010 microsoft sharepoint foundation web application stuck starting


















Please let me know any workaround to start it again. Go to Run, input "cmd" to open command prompt, navigate to stsadm directory, i. Type : stsadm -o provisionservice -action start -servicetype spwebservice. How many web applications in the SharePoint environment? Otherwise, maybe you can try to stop it first and then start it to try, or use SharePoint Management Shell to see if it works.

Thanks Tina Yi. It's started working now. I think may be because of many web application it took long time to stop and start. I am running SharePoint and had the same problem. It would not automatically fix itself. I did:. You must do the steps below in the correct order, otherwise you will encounter problems with the SyncDB.

Do them in the correct order! If you need this capability, do not install the December CU! This issue is resolved in the February CU. Therefore if we wish to use named instances and UPS we must configure an Alias, and we must do this before we run PSConfig to create the farm. Thus if we are running the June CU or later, we do not need to configure an alias. However, I strongly recommend you use an alias, as it is a best practice for addressing SQL named instances regardless of this issue.

Once we have an alias we can create our farm using it. However there is also another step necessary for reliable start up of the UPS service instance. Basically what happens is that we can provision UPS, but when we restart the machine for example after patching the box the UPS services will fail to start. We should configure this before starting the UPS service instance for the first time to avoid the issue completely. Before we start UPS we must fix this up. When UPS provisioning attempts to install the schema it will fail.

At present this is the ONLY way to get this working. Please note that altering the Database in this fashion is unsupported.

So you have a choice about how to fix this issue. Either run the Windows PowerShell while logged on as the Farm Account, or alter the database user default schema. Of course the logon as Farm Account approach has serious implications for any automated build scripts you may be pursuing. This allows us to avoid the default schema problem without logging on interactively or manually touching the database. If you have already created the User Profile Service Application, you either have to throw it away and start over using the above, or manually fix up the default schema for the farm account.

Note that this is NOT supported. If you are running your SharePoint Central Administration over SSL which you should be in production on the default zone, profile synchronization will fail and you will notice events in your event log.

This is a bug where the core FIM Management Agent is configured with incorrect connection information. Note: this issue is fixed in the October Cumulative Update and later. The following steps are for those who cannot move to the October CU or later. This approach is NOT supported. To fix this we must manually edit the Management Agent Connection Information.

We must do this after UPS provisioning. Note : the use of the Synchronization Service Manager miisclient. Deploy the October CU or later to resolve this issue. When you attempt to Populate Containers or save a Synchronization Connection you may receive a client side timeout error. This can be due to a large number of containers in the domain, or other domain connectivity issues. We can adjust the timeouts used using Windows PowerShell. Firstly, the Populate Containers timeout, which by default is 30 seconds.

Next, the Save Synchronization Connection timeout, which by default is approximately 17 minutes. We can adjust this value in milliseconds this time on the Service Application:. Lastly you may receive timeouts when simply connecting to the domain. By default the maximum time is 30 seconds. To alter this value, we must install the June Cumulative Update or later. Once we have done that we can modify the connection timeout on the Proxy:. I strongly recommend that you slowly increase the timeouts until they work, rather than simply entering a very big number!

This behaviour is by design. Re-provisioning is significantly quicker than the initial provisioning but does require the same rights. You are commenting using your Google account. You are commenting using your Twitter account. You are commenting using your Facebook account.

Notify me of new comments via email. Notify me of new posts via email. In case you do not see any progress in IIS or in the ULS logs then you can start the deployment of this service using this STSADM command: stsadm -o provisionservice -action start -servicetype spwebservice But keep in mind that you have to wait a lot depending on the number of web applications you have.

Work in progress….. Phase two Everything worked fine after the stsadm command was used. Like this: Like Loading Leave a Reply Cancel reply Enter your comment here



0コメント

  • 1000 / 1000