You’ve got the ‘mettle’, now it’s time to find out how you stack up against the best Dynamics CRM resources on the planet.
Sign Up Here for your backstage pass. Follow CRM Rock Star to stay informed.
You’ve got the ‘mettle’, now it’s time to find out how you stack up against the best Dynamics CRM resources on the planet.
Sign Up Here for your backstage pass. Follow CRM Rock Star to stay informed.
So I upgraded to Windows 8 the other day (which I’m really loving so far) but the upgrade broke SharePoint’s user profile service application. I have SharePoint 2010 installed locally on my Windows-7-now-Windows-8-PC for development purposes.
There were a variety of symptoms that I won’t list in detail here but basically I couldn’t get into my user profile service application in central admin. ‘An unexpected error occurred’ it told me.
The ULS logs were full of the typical generic user profile service errors (e.g. ‘No User Profile Application available to service the request’) and the event viewer was complaining so fast I couldn’t keep up.
The main errors being reported in the event log were:
The service ‘/SecurityTokenServiceApplication/securitytoken.svc’ cannot be activated due to an exception during compilation. (event ID 3)
and
An exception occurred when trying to issue security token: The requested service, ‘http://localhost:32843/SecurityTokenServiceApplication/securitytoken.svc/actas’ could not be activated. (event id 8306)
So it seemed to be a problem with the Security Token Service. Navigating to the URL listed in the error message above (http://localhost:32843/SecurityTokenServiceApplication/securitytoken.svc) showed me an error page.
Like any SharePoint administrator worth his salt, I immediately hit Google.
Many opened tabs later I stumbled across this post, which offered a solution that worked: re-provision all the SharePoint Web Services. The author says that this is, “one of the safest ways” to get the Security Token Service working.
Near the bottom of the post is a list of commands to enter into SharePoint PowerShell, which I did:
$h = Get-SPServiceHostconfig
$h.Provision()
$services = Get-SPServiceApplication
foreach ($service in $services) { $service.provision();
write-host $service.name}
Once the commands were run I did an IISRESET then tried to access my user profile service application. Success!
Thanks Syed and Abhishek
I recently updated my list of SharePoint web part providers on Quora and thought I’d repost that list here in case you’re looking for some new web parts or add-ons:
www.amrein.com
www.avepoint.com
www.axceler.com
www.bamboosolutions.com
www.contentandcode.com
www.firearrowsoft.com
www.idera.com
www.infowisesolutions.com
www.intranetfactory.com
www.kaldeera.com
www.kwizcom.com
www.layer2.de
www.lightningtools.com
www.nintex.com
www.pentalogic.net
www.roxority.com
www.sharepointboost.com
www.teamimprover.com
www.virtosoftware.com
www.vinewave.com
Or you can find numerous web parts or web part providers on these sites:
www.sharepointreviews.com
pinpoint.microsoft.com
www.sharepointvillage.com
www.sharepointappmarket.com
www.componentsource.com/features/sharepoint/index.html
www.thesharepointmarket.com
After installing SharePoint Server 2010 on my fresh copy of Windows 7 I was seeing a completely blank page when hitting the site. Central admin was showing an empty page too. The blank page showed up almost immediately after navigating to the url, so it appeared to not even be trying to load.
After much digging and prodding I stumbled across the answer: I had forgotten to tick the Windows Authentication box when installing the IIS7 features.
So I enabled it like this: Control Panel > Programs and Features > Turn Windows features on or off >Internet Information Services > World Wide Web Services > Security >tick ‘Windows Authentication’, did an iisreset for good measure, and smiled as SharePoint loaded up.
There are probably many other reasons why one might get a blank page when hitting their SharePoint site, but if you run into this one, remember to check if all the relevant IIS features are installed. You never know.
In doing some recent updates to the Vinewave Staff Directory Web Part, I needed to hide a link called ‘Manage people’, which directed users to SharePoint’s built-in User Information List (the Staff Directory reads from this list).
I had to hide this link for users that did not have Full Control permissions on the site, because they were getting an access denied error when clicking on the link; the User Information list is only available to administrators.
SPSecurityTrimmedControl was the man for the job, but I couldn’t figure out what setting to use for the PermissionsString property to get it to only show content for users with Full Control permissions.
After some clever investigation on my part Googling, I eventually figured out that the property to use for this is ’FullMask’.
So, the following snippet shows how to display content only to users with Full Control permissions on the site:
<Sharepoint:SPSecurityTrimmedControl runat="server" PermissionsString="FullMask">
Content goes here…
</Sharepoint:SPSecurityTrimmedControl>
For some reason I was unable to delete a site in my SharePoint 2010 environment. This time, I wasn’t really interested in figuring out why, I just wanted the site to go away.
Side note: I admit that I didn’t like this site. Let’s call it “SharePoint_DevEnv_01-Oct-2011_000004″ for brevity sake. It had done nothing wrong to me, it hadn’t insulted my family, but it just rubbed me the wrong way and had to go. You know how sometimes an SPWeb just gives you the willys? Well this one did, and I’m glad it got the axe.
The site had no sub-sites, no custom features or code – it was basically an empty team site with one or two documents in it.
Attempting to delete it by going Site Settings > Delete this site failed, as did trying to remove it via the Sites and workspaces list.
What did work however was PowerShell (cue Superman theme). I’m not sure why PowerShell managed to delete the site when SharePoint’s front-end wouldn’t allow me to, but I was happy with the result nonetheless. This being a dev environment, I wasn’t really concerned if a larger issue was at play – the environment gets reinstalled every so often anyway.
To delete a site via PowerShell, simply go Remove-SPWeb “http://server/sitename”, then press Y to confirm.
With all the Steve Jobs news going around these days (resigning as Apple CEO), one invariably comes across many of his famously enduring quotes.
Yes I know this is a SharePoint blog and Steve Jobs probably hates SharePoint, but one cannot deny that his vision and work ethic is amazing, and his ability to facilitate the building of great products is absolutely inspiring. Steve’s focus on quality is something that every person should strive for when creating software, or anything really.
This quote of his is something that really resonates with me:
"When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”
Are you applying this principle to your SharePoint implementations?
With most SharePoint migration projects, content is often copied/pasted from the original system into the new one as-is.
Maybe some categorizing, tagging and styling is applied to freshen up the content a little and make it comfortable in its new home.
But how often do you help your customers define a sustainable strategy for creating content? Yes, you train them on how to add and edit pages, use content editor web parts and rich text editors, but that’s not enough.
If the entire point of implementing SharePoint is to provide a platform for individuals to create and collaborate, then above all we owe it to our customers to help them define a proper content strategy.
Because content is, as always, the real champion. The particular system that delivers that content – the flavor of the year – is irrelevant.
UPDATE: I just came across a post that I blogged in 2008, which offers a different method of displaying file size.
SPUtility is a wonderful class.
The other day I needed to display the file size of a document in SharePoint via C#. I had a hunch that SPUtility would be the man for the job, so after some reflector madness and Visual Studio intellisensing, I located SPUtility.FormatSize.
My search would have been made easier if Microsoft had provided a method summary on FormatSize() (wtf?), but a quick test of this bad boy revealed the perfect solution for my requirement, which was to convert a long value representing the file size in bytes, into a user friendly file size display (e.g. 430 KB).
The long value was retrieved from the FileSizeDisplay field of my SPListItem, and converted into a user friendly file size display with the following code:
if (listItem.Fields.ContainsField("FileSizeDisplay") && listItem["FileSizeDisplay"].ToString().Length > 0) fileSizeDisplay = SPUtility.FormatSize(Convert.ToInt32(listItem["FileSizeDisplay"]));
Be sure to check out some of the other cool things you can do with the SPUtility class, like redirecting users to SharePoint’s built-in error page, or sending emails from SharePoint programmatically.
Happy coding!
In my previous post I wrote about some of the stuff I’ve learned about SPAuditEventType.SecRoleBindUpdate so far. Since then I’ve gained a few more tidbits of info, so I thought I’d share them with you.
I’ve discovered that the following line I provided last time will sometimes throw an SPException:
SPUser eventUser = web.SiteUsers.GetByID(principalId);
This seems to occur when the audit operation happened on a group and not a user, which means the principalId is the ID of an SPGroup in the web.
To handle that problem in your code, simply put a try/catch around the above line and call the following code if it fails:
SPGroup eventGroup = web.Groups.GetByID(principalId);
NOTE: I haven’t yet figured out if the principalId could be something other than a user or a group, but I’ll pass on the info if I find out anything else.
I also learned a bit more about the roleId and how it relates to the principalId…
From what I can tell, the following rules apply:
But, strangely…
That last rule doesn’t make sense. I’m not sure if it’s just something on my local environment (this was tested on SharePoint Foundation) which is causing the roleId to be -1 if permissions were removed from a user. All I know is that it makes it a little trickier when writing code to display this audit stuff on a page, because you won’t be able to display the permissions removed from a user, but you can display the permissions for every other operation.
Well, that’s all the new info I’ve gained about SPAuditEventType.SecRoleBindUpdate. Who would have thought so much could be said about this little gem?
PS: This is some of the stuff I learned while working on my document auditing add-on for SharePoint 2010. DM me on twitter (@lawrencecawood) if you’d like more details. It will be for sale via Vinewave.