12/14/2009I was having a neat little problem where I was unable to login to WSS sites on my development virtual machine. I would keep getting prompted and prompted for credentials even though the credentials belonged to the admins group. This was a particularly painful issue given that some of the web parts were failing with the wonderful “non-specific error.” After a little scouring I found this little registry hack (Method 1) which fixed the problem: -
Set the DisableStrictNameChecking registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base: 281308 Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name - Click Start, click Run, type regedit, and then click OK.
- In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa - Right-click Lsa, point to New, and then click DWORD Value.
- Type DisableLoopbackCheck, and then press ENTER.
- Right-click DisableLoopbackCheck, and then click Modify.
- In the Value data box, type 1, and then click OK.
- Quit Registry Editor, and then restart your computer.
Curiously the login problem didn’t exist with the Central Admin site. 7/16/2009If you've ever done a fresh install of Win2k3, then the service packs, then installed IIS, then installed WSS 3.0, then fired up Central Admin, get barraged by security challenges and finally end up pretty much with a worthless Central Admin... Try re-applying the service packs, especially if you installed IIS from media that pre-dated the service packs you just installed. I don't know what the exact problem is, but the symptoms probably aren't limited to WSS. One of the files that will fail to authenticate is WebResources.axd, which can be utilized by any ASP.Net application. I can imagine a few people have run into this but I only found one page which described the symptoms and solution. 4/21/2009And by berserk I mean something along the lines of pegging a CPU core out at 100% and not coming back... generally accomplished when switching from code to design view, or alt-tabbing back from another application to SPD when it's in design view. - Having a DataView on the page. Your chances of SPD going into berserk mode increase if a) you have more than one DataView, b) the DataView has information joined from multiple lists, and c) you are previewing with sample data rather than "faked" data.
- Having script blocks with code inside them (rather than using the src attribute). It doesn't matter if they are run on the server or the client.
In instance 1 I can go a fairly long time between crashes, especially if I try to make sure I use faked data. In instance 2, if I'm working on the same page and alt-tabbing back and forth between the browser and SPD, I can crash SPD pretty much at-will in a few minutes. |
|
|
|
|