I recently had to change my active directory account password.
Ever since then I am unable to deploy BizTalk projects or put my Receive Locations in the stop state (Sendports & orchestrations is fine).
I noticed that my Enterprise Single Sign-On Service isn't running, if I try to start the service it complains about a login failure.
The thing is, you would think that it used my account to start this service and that it can't login anymore because of some old password or something. However I run the service with another user, namely: BiztalkUser. This user is set on the service and u can also see him in the biztalk server configuration.
Anyone have any ideas what I have to do? Cuz I can't do much anymore now.
The procedures for changing service accounts and password is clearly documented by Microsoft http://msdn.microsoft.com/en-us/library/aa561505(BTS.10).aspx please follow the steps outlined under "Enterprise Single Sign-On Service on Master Secret Server" to correct your issue.
I agreed with the first paragraph of answer 1. That would be the first option I would look to correct the problem. The second option would be, restoring the master secret server.
See below;
Open a command prompt - Navigate to C:\Program Files\Common Files\Enterprise Single Sign-On\
Type in command - ssoconfig -restoresecret SSOXXXX.bak
(Where XXXX is a randomly generated name created with SSO was installed. This is the SSO back-up file)
Enter the password - (Again you entered/created/accepted this when configuring SSO in the BizTalk configuration.)
Additionally you should create a new backup file if you have changed the account the SSO service runs under.
To create a new back-up file - ssoconfig -backupsecret latestbackup.dat
If SSO is running under your account and it stopped working when you changed the password, you need to update your password on the service's credentials. You can do this in the serivces control panel. If you have other BizTalk items running under your account, you will need to update them as well... host instances, application pools, etc.
BizTalk User may not not have the necessary permission to run SSO. I'd suggest put the account back in that worked. Comb the error log for other messages to help you diagnose th eproblem. For furtherhelp, I'd suggest posting more specific details of your current problem here (ie. Error Messages, Log Files, etc.).
Related
Hi I am trying to deploy a website on an Azure VM and I already set all the configuration for make a deployment but this error appears when I tried to publish:
Error Web deployment task failed. (You connected to the remote computer ("saveci1.westus.cloudapp.azure.com") using the Web Administration Service, but it could not be authorized. Make sure you are using the correct username and password, that the site the one you are connecting to exists and that the credentials represent a user who has permissions to access this site.Get more information at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_UNAUTHORIZED.)
Make sure the site name, user name, and password are correct. If the issue is not resolved, please contact your local or server administrator.
Error details:
You connected to the remote computer ("saveci1.westus.cloudapp.azure.com") through the Web Administration Service, but could not be authorized. Make sure you are using the correct username and password, that the site you are connecting to exists, and that the credentials represent a user who has permissions to access this site. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_UNAUTHORIZED.
Remote server error: (401) Not authorized. PoC 0
I follow all the steps from here https://github.com/aspnet/Tooling/blob/AspNetVMs/docs/create-asp-net-vm-with-webdeploy.md
Could you please check if is there any IP restriction configured for the resource group in Azure portal as it could be the reason.
Also i would suggest you to put a fiddler and trace the request which is causing the failure.
please check if you are behind any proxy, if yest then try to connect to a network that does not require this SSO through the proxy or use one of the many other ways to publish that do not require an SSO connection from your machine such as, FTP, VSTS, Git etc… and try to deploy it. Most of the time proxies are the reason which could cause failure in deployment.
As a workaround you could ftp to the site & do deployment via that method .
Hope it helps.
Ive created a app in asp.net using c# that needs to create folders on a number of network shares. Ive configured the app pool account to use a domain account and given that domain account the correct permissions to the network share folder. When i run my code im getting the following exception. Any ideas?
Exception: System.ComponentModel.Win32Exception
Message: Logon failure: unknown user name or bad password
You should create an account on the network that has the relevant access to that share and then set your application pool to use that identity.
This way, all requests from your application will appear to be that user.
Take care with this approach, however, as if anyone changes the password to that account, you will need to update it within your IIS
OK seems I've been a bit of a chump. Seems there was some code I wrote (cant remember doing it) that impersonated the account I had set for the custom app pool but with the old password. Simply commented out the code and it now works as expected. Note to self!!!!!! Must read stack trace more carefully in future.
Apologies for wasting your time
My ASP.NET MVC 2 application runs under built-in local NETWORK SERVICE account. I want to set up access permissions for the folder which resides in another computer, but in the same domain. I located that folder right-clicked to open its properties form, clicked to Security tab and pressed Add button which displayed Add user form with correct domain name in the location field. I referred to the account with following syntax:
<domain name>\<server name>$
because I learned that NETWORK SERVICE account uses machine account when connected to other computers in the domain.
However, the system couldn't find the account, so refuses to add the account. Without the domain name it adds a user, but that user seems to be local user, not web server's NETWORK SERVICE account. What am I doing wrong?
By the way, the above syntax worked when I created login for the sql server which is different computer from the web server.
OK, I will answer my own question. The above syntax \$ was correct. Just make sure to select computers checkbox in the object type, when adding user permissions.
I have been in this same situation before. I don't think I got it to work with the Server/Network Service but this might be worth a try.
Figure out the account network service is using to access the network resource.
Configure windows auditing (on the server the folder is located) to log the failed security events of the folder.
or monitor the folder with something like filemon.exe
.. from here you can try and add the account to the security settings of the forlder. (IIRC I did'nt ever get this to work)
Alternatively you can ensure the action is performed under the context of a domain user. Either by:
Impersonating the user in code and performing the action (my preference)
Setting the impersonation settings in web.config to a named user
setting the application pool to run as a domain user.
I'm getting the following error on my dev machine when attempting to manage SSO settings:
ERROR: 0xC0002A0F : Could not contact the SSO server 'SSODB'. Check that SSO is
configured and that the SSO service is running on that server.
The Enterprise Single Sign-On Service, RPC service, and COM+ System Application service were all started when I checked, but I gave them a restart anyway and it didn't fix the problem. I can access the SSODB through SSMS.
I unconfigured SSO through BizTalk and reconfigured it (successfully). Alas, this also did not help.
SSO was previously working fine. I did notice this morning upon reboot that my browser home page was reset back to our corporate site (meaning something may have been pushed to machine this morning when I signed on) but no one else on my team is experiencing the same issues.
I'm not sure what to try next. Anyone have any ideas?
So, is SSO still working for BizTalk? If so, this might just be a simple user level config issue for SSO. based on the browser info, some user local settings may have been messed up. Try this:
CD to "C:\Program Files\Common Files\Enterprise Single Sign-On" Use administrator privileges
Type: ssomanage -server [SSO Server Name Here]
This will reset the SSO Server name for your user account.
I have written a web service that reads from a message queue.
This works fine under Cassini.
Now that I have deployed the service under IIS, I receive an error message when the service tries to access the queue:
The queue does not exist or you do not have sufficient permissions to perform the operation.
I have set the anonymous access user on the IIS virtual directory to be my own domain account, which is a member of the administrators group on the local machine. I have granted this same user full permissions on the queue, as well as NETWORK SERVICE and ASPNET.
I still get the same error message.
I have also tried disabling anonymous access on the virtual directory and connecting to the service using my own login details - to no avail.
Any help with this problem will be greatly appreciated!
I have also tried various combinations of:
and
With testUsr having full permissions on the queue. I have added permissions for the user and ASPNET on the MSMQ store folders on C:\
My understanding of the problem is that the process trying to execute the code is running as a different account under IIS than it does under Cassini.
The problem was that regardless of which user I impersonated - I always got the same error message - even when the user was a member of the local and domain administrator groups, and this user had full permissions on the queue. i.e. It is barely possible to assign more rights to a user.
It turns out, that using a FormatName for the queue, rather than a path name (myMachine\queueName) has solved the problem...
FormatName:DIRECT=OS:myMachine\myQueue
I am uncertain as to exactly why this is the case. Reading up has showed that when a path name is used, there is a necessity for an AD lookup, and although I think that the users that I have been testing with should have rights to do this, perhaps there is something missing.
However the immediate problem is solved and that's good enough for me.