While working on a client's MOSS 2007 Publishing site, we ran into an issue where we simply couldn't create any CMS pages. After clicking Site Actions -> Create Page, the page would act like it was posting back and, after a several minutes, would either time out, or prompt me for my credentials 3 or 4 times in a row only to finally display a "You are not authorized to view this page" error. The same happened when attempting to create a page from clicking "New" in the Pages library, clicking "Create" on the View All Site Content page then clicking Publishing Page, or clicking New on the Mangage Content and Structure page while in the Pages library.
This all started happening after I went into Site Settings -> Page Layouts and Site Templates (under the Look and Feel section) and modified which Page Layouts were available for the user to select when creating a new CMS page. Figuring the issue lied in this change of settings, I tried to go back into the Page Layouts and Site Templates settings page again, only to discover it was acting the same way as the Create Page function.
Having no error information to go against and nothing useful coming from the bumped up logs (except an unknown lockfile error which we can't even be sure was linked to our issue), we took a shot in the dark that our issue was permissions related. The user we used to change the Page Layouts and Site Templates settings was a Farm Administrator, Site Collection Administrator, and had Full Control on the particular site we were on, not to mention the fact that we were able to change the Page Layouts and Site Templates settings with this user in the first place. However, we logged in with the System Account and voila!!, we were able to create a CMS page AND access the Page Layouts and Site Templates page.
Ever go into a meeting where clients have asked you questions that you didn't know the answer to? No, that's never happened to me either. But a friend of mine thought every time he went into a meeting where a client asked him a (sensible) question he didn't know the answer to, he would list it here so that others could ponder the answers.I'll list the answers if I find them - Whoops - I mean if he finds them.
- Can the mysites left hand side nav contain different items by default on creation?
- Can you prevent users from creating subsites under my sites?
- Apparently yes - http://www.sharepointblogs.com/tbaginski/archive/2006/11/14/how-to-prevent-creation-of-sub-sites-within-moss-2007-my-sites.aspx
- Can you change the users display name?
- Yes. - http://www.21apps.com/sharepoint/user-profiles-why-do-my-changes-not-show-in-other-sites/ Basically just need to change or remap the name field in user profile properties in Central Admin.
- Once users are imported from AD, can you clear them all out?
There are many articles on how to do SharePoint development on an XP pc. E.G http://fernandof.wordpress.com/2008/02/11/how-to-install-the-sharepoint-2007-vs-2005-extensions-on-a-workstation/
The question is does this give you the same experience as the recommended method of developing directly on a SharePoint server?
The bottom line is NO. The reason is that these methods still won't allow you to connect to a SharePoint web.
i.e Anything like this won't work
this._Web = SPContext.Current.Web; or
this._Web = new SPSite(http://<IP_ADDRESS>).OpenWeb();
In other words you can compile but to see the results you will have to deploy to a SharePoint server.
The only exception to this rule is with web parts where code doesn't actually interact with the SharePoint object model and is just a standalone web part. Then you can test your web part by creating a web project with web part zones and run your web part from there.
If that hasn't put you off here are a couple of extra steps you may need to get going with SharePoint dev on XP.
1) Copy all the DLLs out of the GAC of SharePoint install.
So, to extract these DLLs (for example in the c:\temp folder), I use a classic XCOPY command in command line from the folder C:\windows\assembly\ :
XCOPY GAC_MSIL c:\temp /
Then use a normal windows search to find all dll in temp folderabd copy out the SharePoint related ones.
Copy the DLLS to your local GAC. i.e to C:\windows\assembly
Do an IISRESET.
2) If you get a personalization web.config error when testing we parts in local web part zone enabled Site
Make sure you set personalization on your web part manager off for testing locally
<asp:WebPartManager ID="uiWPManager" runat="server" Personalization-Enabled="false"></asp:WebPartManager>
By default, you do not have Administrative privileges if you're logged on as a user (other than the built-in Administrator account) even if this user was added to the local Administrators group on the machine (this is a new security feature in Windows Server®2008 with-IIS 7.0, called LUA).
Make sure to either log-on as the built-in Administrator account, or explicitly invoke applications as the built-in Administrator as needed, using the "runas" cmd-line tool. For example, to launch notepad.exe you could run this command: "runas /user:administrator notepad.exe".
You will be prompted for the password of the Administrator account. It is useful to have a cmd-box shell that is already elevated, by running "runas /user:administrator cmd.exe".
Every application you run from that cmd-box will be elevated as well, and you will not need to use the "runas" syntax from that cmd-box.
There are 2 types of Access Denied errors when trying to access Shared Services.
This first solution deals with not being able to access Shared Services at all and No 2 deals with being able to get in but when you click on anything like "User Profiles and Properties" you get Access Denied.
If this happens to you go to Site Collection Administrators in Application Management in Central Admin.
Change both or just the secondary administrators in here to your user for the Shared Service site collection.
I found this solution here:
Assign yourself lot's of permissions. Go on. You know you deserve it!