Starting today, whenever I try and use security editor on either of two similar roles I get a timeout. If I try again IIS reaches an error threshold of some kind and stops that Application Pool. Then all of our users receive a "Service Unavailable" message from IIS.
I can edit other roles. This error can be recreated.
I assume I have some kind of database corruption, but I can't find an error that helps me in Event Viewer or the Sitecore logs. Where else can I look for more detail?
IIS6, Windows Server 2003, Sitecore 6.2
It sounds to me like you've got a circular reference in your roles.
Are you using the default role provider, ASP.NET membership? If so, try using the default Microsoft security tools (you can get at 'em via Visual Studio). If that doesn't work, you can programmatically modify these roles using the API.
Also, I believe there is a known issue which may be fixed in a 6.2.x update. I would check the change list at SDN. Here: http://sdn.sitecore.net/Products/Sitecore%20V5/Sitecore%20CMS%206/ReleaseNotes/ChangeLog.aspx
Yep... take a look at the 6.2.0 rev 100701 update list.
Related
I'm trying to use Azure AD as a standin for production level ADFS systems during development of an application. Up until today, everything worked fine. I don't know what I touched to break everything, but now I'm getting the following error:
AADSTS700016: Application with identifier 'https://foo.bar.localhost:44300/' was not found in the directory '[[GUID]]'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.
I don't know what's changed, or why this worked last week and not today. I've been trying to change any number of settings - even deleted the app and re-created it, and nothing seems to help. Most of the other articles online keep referring to old versions of the Azure portal, so the clicks/links/menus that they are referring to no longer apply. There's a little popup on my sign in screen that says that I can enable "Advanced Diagnostics", but I don't know where those results show up so that I can see it.
Some things that I've checked:
- Under "App Registrations", the Endpoints for "Federation metadata document" and "WS-Federation sign-on endpoint" match what my application is using (so I'm going to the right place).
- When I click my application, under "Authentication", the Redirect URIs contains "https://foo.bar.localhost:44300/". I've tried with or without the trailing slash (and, sometimes, both).
Those are the biggest two places that other articles imply there may be an issue. Does anyone have any other ideas? Are there specific user-level things that I should be doing? Has something changed (very recently) that would be affecting my ability to use this feature? How are Enterprise Applications related (they're a Premium feature, and my Subscription is not)? I need to get my log-ins working again so that I can get my development process back underway. Thanks!!
Finally found the right setting. Turns out, many of my old applications were created when I was a "personal" user. I've since become a domain/work user, and it puts some things in place differently than before. In this case, I had to change the Application ID URI listed under "Expose an API" for my application. Setting this (where it wasn't set to anything before) allowed my application to be found and my login to succeed.
I am working on a ASP.NET MVC project in Visual Studio.
Since today I see am seeing every now and then
a dialog window "Connect to SQL Server" that uses {0} as user name:
I always click Cancel as the user name is just a place holder. It is read - as the rest of the database configuration - from Web.config.
The documentation just states:
This dialog box appears when specific access permission is required
for the current database process.
I believe I do not need this access. How can I prevent Visual Studio from showing this dialog?
PS: I do not want to remove the configuration from Web.config as it is needed by my project.
After a little debugging, it turned out that it was the awesome Meene VS Tools 2017 extension which caused this problem. Specifically, the Enable tasks provider option. Just disabling it helped to get rid of the nasty dialog. Maybe one could also add the Web.config to the Excluded file name patterns to fix the problem. Since I do not use the tasks, I did not try though.
I finally decided to give Azure a try and the first thing I do - creating a simple web site - fails with: Creation of web site 'null' failed. Details say: Provisioning failed.
I am simply trying to "quick create" a simple website. Researching the Web, I see other people with the same problem, but no real solution.
I do have an active "Visual Studio Ultimate with MSDN" subscription and $150 of unexpired credits.
I must be missing something very fundamental.
Seems to be known issue:
A number of users have experienced “Provisioning Failed” errors when
attempting to deploy Windows Azure Websites. This is a known issue
with the trial version, and there is an active discussion thread on
the MSDN forums here.
It is expected that this is a temporary problem that will be fixed
soon, in the meantime there are a few things you can try: Ensure
database passwords do not contain special characters like ', ", =,
etc. Try creating a website without a database, database creation may
be causing the error. Try deploying the site in a few hours, it may be
a temporary problem in the data center.
So, to put some closure on this, I contacted Microsoft Support and they suggested trying to login to the portal through an anomymous/incognito browser session. Once I did that, I was able to create a website.
Mind you, having cleared all persistent data (cookies, etc.) in the regular browser, I still cannot do anything in Azure, from several different machines. But at least the incognito session is a workable workaround.
Once again another issue
I am trying to delete a site that i have created via a template and i am running in to
No available sandboxed code execution server could be found.
The template only contains a few columns programatically created along with some content types.
The CT's are also added to lists.
Anyone got any ideas?
I will continue to go through the ULS logs and hope someone saves me
Cheers
Truez
If you have empty receivers in your features and your solution is a SANDBOX one you should either switch it to Farm solution or check if your user code host service is running. Go to Services and check the "SharePoint 2010 User Code Host". Also check the "Microsoft SharePoint Foundation Sandboxed Code Service" service in the /_admin/Server.aspx It has to be running to support sandbox solutions.
I thought I'd give SharePoint development a go, to broaden my understanding of Microsoft technologies and ran into a situation I refuse to understand.
I have a new web application created: http://localhost:11523 and set up the site collection as required. I can browse to the web site fine, without any issues, but now I want to start developing against this, using the object model.
Right, so after I struggled with SPSite site = new SPSite("http://localhost:11523"); I figured that I'm not running VS2008 in elevated permissions, so restarting VS I finally got one step further.
Whenever I step into my code, I get:
The Web application at
http://localhost:11523/ could not be
found.
I've Googled this without luck. The application is most definitely there, I can browse it, add web parts and go mad. I just can't seem to connect to it via Visual Studio.
Any ideas would be great.
EDIT
I thought I'd isolate my method, called "GetListFromSharePoint(string name)" into a test method (nUnit Framework) and to my surprise returned 9 entries from the list, as expected. When I dumped the method back into my web application (not SharePoint, trying to test the Composite Control through a normal Web site), and run into the mentioned problem.
This is in SharePoint 2007, and I'm developing on the same machine onto which SharePoint 2007 is installed.
This approach used to work, for some reason, I just can't get it to recognize SharePoint. The test stubs work find, just not the web application.
Edit 2
So there where a couple of things I "missed", which kind of solved the problem by itself.
Firstly, I was developing on a x64 Windows 2008 box, thus SharePoint 2007 was running in x64 mode. Cassini, turns out, is 32bit regardless of the platform you run it on, which caused some compiler bugs (I did not have IA64 compilers installed). After installing this, I figured out that the default web site (localhost:80) had been disabled by SharePoint.
Renabling the default web site, allowed me to create my web application as a virtual directory against it, which allowed my debugger compiler to run in x64.
My next challenge was access permissions. Because any new virtual directory on port 80 is assigned to the default application pool, is it assumed that the user does not have the right permissions, so I had to change my web application to run under my SharePoint web application's application pool.
The last thing I had to do was run my SharePoint code with elevated permissions.
Working like a charm :D
Note! Enable debug on your SharePoint web application....
Thanks,
Eric
(You have not specified version - assuming SharePoint 2010).
You need to decide what object model you want to use:
client (to be able to access the server from any other machine)
server (the one that you are trying now, can only be run locally).
Most likley reasons your code not work:
using "localhost" instead of ""computer name" in the Url. (I believe it is the reason.)
you are running your code not on the same machine as the SharePoint
you are running code under non-admin account
Check out how sites collections are configured in "Central Administration" site - urls associated with each site collection are listed there - make sure you are using correct one.
You can also try enumerating all site collections in SPWebApplication (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebapplication.sites.aspx) to start expiriments.
I dont think the SPSite connect through the IIS, and if SharePoint isn't set up to respond to localhost (done in the Central Administration) you wont be able to connect to that url. IIS works a bit different here since it relays the signals to "localhost" to the "web application instance".
Start by checking in your SharePoint Central Administration. Go to "Configure alternate access mappings" in the "System Settings" section. Here you have your SharePoint instances, there are three properties which you can see directly in the list; 'Internal URL', 'Zone' and 'Public URL for Zone'.
If the Internal URL isn't set to Localhost you wont be able to use that connection you suggested. It bay be improper to change this to another url as well, so simply try to set your SPSite site = new SPSite("http://yourinternalurl:11523"); to whatever's in that box! :)
Cheers