I've got a SharePoint MOSS 2007 development setup on to which I installed the WSS infrastructure update. Now, whenever I try to access any site collection in my SharePoint farm using IE7 I get a username and password prompt. I enter valid credentials for my Site Collection admin account and I see the box again. This happens three times then after the third time I just see a blank page.
When I access the system through FireFox 3.0 I get the username and password screen but after putting the credentials in the first time, the site runs as normal.
I presume this is because IE is using NTLM whereas Firefox is using basic authentication, but I'm not sure how to resolve the issue.
Has anyone else experienced this or can anyone point me in the right direction?
Thanks in advance
- Russell
I've found the answer to this now. It was all to do with this issue...
http://support.microsoft.com/kb/896861
Before the infrastructure update just entering the FQDN (e.g. intranet.domain.local) for BackConnectionHostNames entry in Method one worked fine. After the infrastructure update I added just the hostname (e.g. intranet) to the BackConnectionHostNames entry and this fixed the issue! :-)
I had to turn off IE ESC to get this to stop. For some reason, it worked on all servers except one in our farm. Who knows. Hope this helps you get started.
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 have an intranet web page.When I entered to the web page,it ask me to log in. When I put my credentials he lets me in but when inside he asks me again and again and again. If I click another section it will ask me again too.
I have tried adding the web page to trusted sites,credential manager on windows. I think this is not case since I have a qa site and doesn,t happens.
This only happens to this site because I have more sites on the server and they work as expected.
I have multiple sub sites on the page I don't know if this maybe related.
How can I solve this?
Thank you in advance.
Refresh your browser cache/ passwords..
If the page you are trying to access has some code/webpart which tries to access a resource to which you dont have access, then it can give this issue.
I have a problem with my sharepoint site, when I go to the home page the log in box keeps popping up, I have to click about 3 to 4 times before it goes away, and it does that everytime I go to the home page, all the other pages does not do that.
Can any one please help me out here.
Thank you.
Is there anything on your homepage you do not have rights to? Like un-approved images?
Use a tool like Fiddler to see what is causing the authentication requests.
Add the sharepoint url to the Trusted Sites also try enabling "Automatic Logon" under the Local Intranet Zone security settings
cheers,
NK
We'll be upgrading a client's MOSS public internet site soon from a Cumulative Update to SP2 and are conscious that there will be downtime (to perform the upgrade and possibly troubleshooting!). We would like to add a holding page so that visitors still get access to key contact details and a message that the site is under maintenance.
Does anyone have any tips for doing this type of thing with SharePoint? I know of the app_offline.htm file that when dropped into the web root, will automatically prevent access to the rest of the site but wasn't sure if this was standard practice in the SharePoint world?
Any tips?
Cheers, James.
If the app_offline.htm works for you, then by all means, use it.
I think that it will the best option for you, and to the best of my knowledge SharePoint doesn't have any other means of putting itself offline.
As this is a public intranet site you are updating, presumably there is already a test environment for it that is close or the same in configuration. It is important to follow exactly the same steps for updating the test environment as you would for production. These should be documented as well and followed to the letter to reduce the likelihood of mistakes. This way you are much less likely to run into problems.
I would try app_offline.htm as you suggest (like Magnus I don't believe there is another way to take SharePoint offline). If your test environment updates with this in place you should be fine.
I am getting a random web part error, it works one refresh and then not the next:
Web Part Error: One of the properties of the web part has an
incorrect format. Windows SharePoint
services cannot deserialize the Web
Part. Check the format of the
properties and try again.
The web parts have been on the site for a long time, and I have checked Micorsoft Support, http://support.microsoft.com/kb/826786 . And it is not a permision error becuase it has been this way for a long time. The only thing changed in regards to webparts was going into Site settings > Web Parts > New and selected some webparts that were not in the list and I think I also Checked the ones that are having this random error and clicked "Populae Gallery". Any body have a clue?
This could also be because of insufficient disk space on the server where SharePoint is hosted. http://www.sharepointblogs.com/vipul/archive/2006/09/25/webpart-error-due-to-space-crunch.aspx Check the available disk space.
Hope this helps.
Have you tried rebooting your server. I have just recovered from this exact problem. One of my frontend servers ran out of disk space yesterday and I recovered 10Gb of it, however this didn't rectify the error I was receiving when trying to view or add page viewer webparts until I rebooted it. All is perfectly fine now.
but try doing this:
Go the central administration
operations
service accounts
Web application pool (radio button)
webservice (drop down); select windows sharepoint services web app
application pool (second drop down); select the site that the problems occurs on e.g. home_port_80
user name (text field): type in the account info you have used during sharepoint post installation configuration
password: at last type in the password.
hope it helps
Another thing that can cause this is an "undocumented feature" in SPD that splits the Web Part properties across two lines, like this:
<FrameType>
None</FrameType>
Just removed the line break, like this:
<FrameType>None</FrameType>
and everything started working again ...