PurchReqApproval workflow stopped working, that is all the workflow's messages are in pending state. There were no modifications made to objects related to that workflow (maybe except EDTs).
I am thinking this issue might be consequence of changing server admin password. Any hints how and where can I check/fix outdated password in IIS/AX/Services?
Go to your IIS manager and then click on application pools. Find the relevant one and right click on it and do advanced settings, then look at its identity (username) and click the ellipse .... Try setting the password again and recycling the app pool and/or doing an iisreset.
Related
When attempting to add a web reference to my MVC 4 project I do the following:
-Right click on project name and select "Add Service Reference..."
-Click on "Advanced..." button
-Click on "Add Web Reference..." button
-Enter the Web Services API WSDL address in the URL field
At this point it will search and then find the web service and ask me to authenticate the request, after agreeing to continue I am prompted with a login dialog, after entering the correct username and password it will often lock up. Sometimes it will re-display the login dialog and/or pop up some security confirmation boxes that read "Do you want to view only the webpage content that was delivered securely?" (Haven't been able to select Yes or No yet due to application hang around this time).
At this point I have to close the IDE and start the process over. I've tried 5+ times and have updated my system and rebooted.
Any ideas what could be causing this?
Thanks.
Turns out it just took a very very long time. When clicking on pop ups it would stop responding, I found if I waited long enough it would eventually let me make a selection, then the next box would hang. Whole process took well over 20min but eventually went through.
Not sure if this question should be deleted since technically there was no error, I'll leave it up to the mods.
Thanks.
Firstly, I am aware this problem has been dealt with before here, and the solutions are always corrections to the connection string.
However, in our case, the connection string is correct, because most of the time it works fine. What happens is at some point the site 'stops' and starts logging this error. Simply recycling the app pool clears it, and everything is good again until the next time. A site might run fine for hours or days, but then it falls over and every request logs this error.
Since it is a transient error, I suspect it is somehow memory or service related? Either some kind of service that handles the connection from the ASP.NET site fails within the app pool, or there is some shortage of memory so whatever process is required to handle the connection fails.
It is not just a single server, I have seen this issue occur on various customers' servers, so I don't think it is some obscure glitch with a particular server. I have also seen sites that were running fine for a long time start to experience this issue (which suggests to me it is related to resource availability).
For the sake of completeness, this is the connection string from a site that exhibits this problem:
<add name="SQLConnection" connectionString="Data Source=localhost\sqlexpress;
Integrated Security=True;Initial Catalog=databasename"
providerName="System.Data.SqlClient" />
But like I said, this works absolutely fine for hours/days, until the problem occurs.
Just surfing with error message and got one link from Microsoft.
Seems to me like your problem.
Can have a look on this.
http://social.msdn.microsoft.com/Forums/en-US/9f191038-dbf6-4306-8f66-ec211a1e933a/format-of-the-initialization-string-does-not-conform-to-specification-starting-at-index-0?forum=adodotnetdataproviders
Thanks
Can you please check following points:
Make sure the account has full permission (both read and write) on folder:
"C:\INETPUB\WWWROOT\BE SITE WORK(FINAL)\4SIGHT\WEBSITE\BARAMATIESTATES\BARAMATIESTATES\”
I recommend that set “C:\INETPUB” folder allow all user access and edit, at least give full administrator right to IIS account.
2 Make sure IIS account is sysadmin of SQL Server.
Setting IIS Permissions for an Object
You can set permissions for any object in IIS, including Web sites, folders, files, and scripts. To set the permissions for an object in IIS:
Log on to the Web server computer as an administrator.
Click Start, point to Settings, and then click Control Panel.
Double-click Administrative Tools, and then double-click Internet Services Manager.
Right-click the Web site that you want to configure in the left pane, and then click Properties.
If you want to set the permissions for a Web site's home folder, click the Home Directory tab.
If you want to set the permissions for a folder in a Web site, click the Directory tab.
If you want to set the permissions for a file or a script in a folder, click the File tab.
Click the corresponding permissions that you want to set for the object.
To turn on script processing for a Web site or folder, click Scripts Only from the Execute permissions list.To turn off script processing, click None.
Click OK.
if the issue still persist let me know :)
I have a Lightswitch 3-tier web deployment and I'm stuck on the auth piece. I've played with IIS and tried every config I can think of, but after I publish to the web, it always shows the app pool identity as the user in the top/right side of the browser. The only way I can get the ID to "pass through" is to enable impersonation which I know isn't correct. Even with impersonation enabled, the Administration tab doesn't show with the ID I assigned as the administrator after the initial publish.
Have you seen this? I've tried this on multiple deployments, re-read the guides, re-read the LightSwitch book auth chapter, still to no avail.
Also, I find it curious that when I drop this code in a test.aspx it shows that my ID is indeed getting passed:
<%= User.Identity.Name %>
But when I put this in, it shows the app pool ID:
<%= Environment.UserName %>
It's like Lightswitch is reading the Environment.Username (which will always be the app pool) instead of the user being passed by IWA.
What do you think is going on here? I've relegated to NTLM at this point to make it "easy" (abandoning Kerberos for now) and it still doesn't work.
I have a great app that I'm ready to deploy, but I need to get security setup for it.
I figured it out. I had earlier tested the website by simply copying the release from my visual studio project folder to the web server. I decided to wipe the whole folder and publish "from scratch" and what do you know...it worked.
This is obviously my first experience with web development so just a noob mistake. I'm still curious what was in the config that was over-riding what I was telling IIS to do, but for now I'm off an running.
You can close this issue.
I had to relocate to another office due to weather related issues. In our old office, when we started an IIS application using windows authentication the application would pull your windows info and immediately sign in using your credentials. At our new location I have the same app and same settings, or so I thought and when a user starts the application a windows username/pass box opens. The correct information is stored there and the user can just hit enter and move on but I was wondering why it doesn't just auto-log in like at my other location? Does something need to be set in web.config?
The cached credentials on Windows will impact this. If the IP changes or machine name changes, you can easily fix by going into CredentialManager in the control panel and deleting the old ones, then when you tell it to save credentials next time, it takes you right in.
https://security.stackexchange.com/questions/15574/how-do-i-clear-cached-credentials-from-my-windows-profile
Following recent hardware problems, I attempted to switch a couple of our websites to use new, individual application pools. A test run on our staging server worked fine, and has had no visible negative consequences.
Unfortunately, trying the same operation on our live machine left one of our key applications struggling - my best guess is with some kind of mismatch in Session state. I could log in fine, but a few clicks later would be presented with a screen that was part login screen, but with all menus visible. This indicates to me that part of the system thinks the session had been lost (redirect to login page), but IIS itself had not lost the session (hence the menus showing on the master page).
I tried recycling all the Application Pools (new and old), and each website using IIS Manager. I also tried a single-space change to the web.config file, and a full release of the dll's. Still, I could intermittently use the system for a few clicks, do some useful stuff, then maybe find myself at a login screen again or similar. We have some logging and on some occasions I could see that the session was being timed-out after a couple of seconds, substantially less than the settings on the App-pool (default 20mins).
As soon as I switched the web site's app-pool back to the default, everything was ok again.
What have I missed? Any suggestions gratefully received!
EDIT:
Just thought... on the staging environment I did name the App-pool differently from the website name (e.g. Xxxx_Dev, Xxx_Test etc) but on live I just called it the same name as the website. Could this cause an issue?
do your various applications all use Forms Authentication? Have you specified unique path attributes in each form tag in the web.config under the Authentication tag?
OK. I think I've found the problem.
I was actually using an Application Pool that had been set up by someone else - of the expected name - but they had set it up with the Properties, Performance tab | Web Garden option to use 4 worker processes. I have now changed that to 1.
As the session state was being stored 'In Process' (the default), each time the connection hit a new thread it also essentially lost any stored session variables, as I now understand things.
Its early days, but a simple switch to the newly altered Application Pool (no restarts or web.config saves necessary thus far) and everything appears to be behaving normally.