July 2009 - Posts
(apologies to Clive Lewis)
It's a simple concept, really. Create your SharePoint site structure to accommodate permission inheritance, not navigation. You can always alter the content and appearance of Global Nav or Quick Launch, so why constrain your hierarchy to something that will probably change?
Have you ever needed to back up a VHD with a script? If you have, then you've probably wanted to make sure it copied successfully.
One simple test is to check the size of both the source file and the destination file; this sounds great until you bang your head against the wall in frustration when, two hours later, you can't figure out why the file sizes still don't match.
Allow me to explain.
When you back up a Hyper-V machine, the first thing you do is to stop the VM for the duration. Essentially, this just tells the virtual machine manager to stop writing to the VHD, giving you a static target... but in the process, it marks the file which changes the size. Ergo, you have a 4KB difference in your VHD size between "started" and "stopped" states.
The solution? Make sure your VM is off for another second while you get that all-important file size. Then start it up again, and off you go.
Rebooting cures a multitude of ills.
Over the past two years I've come to realize that the SharePoint server equivalent is to run the SharePoint Products and Technologies Configuration Wizard (what a mouthful that is). However, my latest discovery is that there is a client equivalent as well.
1. Open Word 2007 (or Excel 2007).
2. Click the Office button.
3. Click the Word Options (or Excel Options) button on the resulting menu.
4. Select the Resources tab on the left.
5. Click the Diagnose button.
6. Start the diagnostic tests and follow the prompts.
The tests will take a few minutes to run, after which the results will be displayed (e.g. 1 defect fixed). At this point you can go back and try the offending procedure again... and most likely, the error will be gone.
Additional info: the relevant executable is located at C:\Program Files\Common Files\microsoft shared\OFFDIAG.EXE. Administrators may find this useful for remote execution at login, etc. for curative or preventative purposes. There's no official way to launch it without user intervention, but you could easily run the file with VBScript or .NET code and then use SendKeys to kick it off.
Feel free to contact me with additional problems that this solves; I'd like to keep an updated list here.
The SharePoint Recycle Bin is a very useful feature, but due to the lack of a separate permission structure, sometimes product owners want to hide it from their users. This can be done in a variety of ways, but I've found that the simplest is to create a new master page (usually from a downloaded copy of the one you currently use on your site) and find the following tag:
<SharePoint:SPLinkButton runat="server" NavigateUrl="~site/layouts/recyclebin.aspx" id=idNavLinkRecycleBin" ...
(there's a lot more)
Simply add the Visible="False" attribute to the tag. This will hide the Recycle Bin link on the Quick Launch and allow you to retrieve it at any time. You won't need SharePoint Designer or Visual Studio -- you can do this with Notepad once you've downloaded the file -- and the whole thing, from when you download a copy to when you Publish/Approve the new master page, takes less than a minute.
We still don't have good SharePoint debugging, but today I came across a tool that gets us closer. Essentially it works off of the SP logging mechanism, and alerts you when messages come up that meet your predefined filters. This has the advantage of (a) keeping you from having to go through the log files line by line, and (b) filtering at a higher level, allowing you to keep all that log information rather than excluding some events from being logged.
Give it a shot at http://sptraceview.codeplex.com/ .