I'm unable to start user profile synchronization service on sharepoint 2013 on premise.When I start the the service,under service account name and password section,account name shown as (NT AUTHORITY\NETWORK SERVICE) and unable to change the value.How to resolve this problem?
This might be the issue due to "Forefront Identity Manager" stopped. To start this service please follow below steps:
Go to Central Administration. Click on "Manage services on server" under "System Settings".
Now you can see the configured service list. Go to User Profile service and start it.
When it start, check in services "Forefront Identity Manager". It will be started.
But you can't change User Profile Manage account once its configured. you need to delete it and create it once again. Please see below links for reference:
MSDN link - User profile create
setup user profile service
Related
I was follwing the steps in the title "Add an allow list" in https://learn.microsoft.com/en-us/azure/active-directory/external-identities/allow-deny-list
As listed in steps
1.Sign in to the Azure portal.
2.Select Azure Active Directory > Users > User settings.
3.Under External users, select Manage external collaboration settings.
I cannot perform the 3rd step, An error pops up like this
what to do?
Highly likely that this is a network issue, please try on another network or browser. If the issue persists please share the console log output.
I get the below error when I try to publish my website from VS2017 to Azure. P.S : I already have an Azure account and url created for my website. Error description:
Web deployment task failed. (Connected to the remote computer
("rdproduct1.scm.azurewebsites.net") using the Web Management Service,
but could not authorize. Make sure that you are using the correct user
name and password, that the site you are connecting to exists, and
that the credentials represent a user who has permissions to access
the site. Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_UNAUTHORIZED.)
There are 2 areas that have to be setup to allow this to happen.
1). Azure portal - Locate the AppSvc Resource you're trying to deploy to. Under the action selection blade, select deployment credentials. Enter a username & pw. It has to be unique and doesn't need to tie to your email or login 2) Within Visual Studio. Right click on the project to deploy and select publish. When the publish page shows up, in the 'Summary' section to the right of the site URL you will see a hyperlink for "Settings" select it. In the page that comes up now, enter your user name and pw in the areas identified. Select Save. Once back on the previous page now hit the "Publish" button. Assuming your build is successful the app should publish with your "authentication" to the app service in Azure.
I have configured and run sample code taken from the MSDN website for a custom BCS indexing connector sample for Sharepoint 2013:
http://code.msdn.microsoft.com/SharePoint-2013-MyFileConne-79d2ea26
During it's intent to crawl, the crawler shows this error in the crawl log:
myfile://servername/CustomConnectorTest
Error while crawling LOB contents. ( Error caused by exception: System.UnauthorizedAccessException Access to the path '\servername\CustomConnectorTest\MyFileModel.xml' is denied. )
Any ideas on why I'm getting this error? I covered all of the obvious (fileshare/folder has the correct permissions, default content access account has the correct permissions, etc).
Figured it out:
You have to make sure that the account running the Sharepoint (Search) Web Service in IIS has access to the repository. OR you can change the service accounts that manage the security components. You need to go to: Central Administration>Security>Configure Service Accounts. From there select an account for "Windows Service - SharePoint Server Search" and "Windows Service - Search Host Controller Service" that has access to the repository. If you don't have one set up then click register new managed account.
Basically it.
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)
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"