These are my notes while trying to diagnose and better understnad some issues and oddities with the SharePoint 2010 User Profile Service Application.
If you’re wanting to populate pictures into people’s profiles, you’ll be using the Update-SPProfilePhotoStore powershell cmdlet after a normal sync (full or incremental - or your custom built one). This cmdlet is in the Microsoft.Office.Server.UserProfiles dll, specifically the Microsoft.Office.Server.UserProfiles.PowerShell.SPCmdletUserProfilePhotoStore class. Thanks to the goodness that is Redgate Reflector (a must have for any SP developer), we can get a more clear undertanding of what the cmdlet is doing.
Developing a CustomAction for the Ribbon and SharePoint 2010? If you’re like me - you follow some instructions online, deploy it once to verify it works, then change as needed and redeploy. One catch though - the data needed for the ribbon custom action to work is fetched by the browser and CACHED! So you won’t see your changes…until you clear your cache. Stupid but true. You’re welcome.
If you’re a developer, or an admistrator, or just command your home machine with extreme prejudice - you need to read Scott Hanselman’s 2011 Ultimate Developer and Power Users Tool List for Windows. Lots of good utilities to be found there. Some may even change your life…
What else do you need?
Custom User Profile Properties (and several of the Out of Box ones) depend on a Managed Metadata Service Application being setup and associated with the application you’re working with. This is fairly trivial to setup. Just remember that after you set it up via the UI, you’ll need to start it on the “Manage services on this server” page, and then perform an IIS reset.
In the time I’ve been doing SharePoint development, and SharePoint 2010 development in particular, I’ve tried to blog about the snags or neat stuff I’ve come across. This post is for all those little pieces of knowledge that come from working with the platform that don’t seem large enough for their own post. If you find it useful, let me know in the comments.
|- and so on with the error message. Do these also fit your situation? 1) The error happens when running a console application 2) Using PowerShell works to access the SPSite, SPWeb, or SPWebApplication that you’re accessing in your console application How do you fix this? Change your build platform target to x64 instead of x86. Also keep in mind that this is a per build configuration setting (so you have the setting for Debug and Release compile modes).
This can be useful when you need a file to be right off the root of your Internet facing site - files like robots.txt, sitemap.xml, or the verification file for Google Webmaster tools. We’ll take advantage of PowerShell’s ability to use any .NET methods along with the Files collection on each SPWeb in SharePoint. $fileBytes = [system.io.file]::ReadAllBytes("c:\the\full\path\to\your\file.txt"); $site = Get-SPSite "http://yourdomain:portifneeded"; $site.RootWeb.Files.Add("file.txt", $fileBytes, $true); This will result in a file.txt located at “http://yourdomain:portifneeded/file.
SharePoint 2007 came with a page (storman.aspx) dedicated to showing you how much space each of the lists in your site collection were taking up. SharePoint 2010 removed this page. Luckily, SharePoint 2010 SP1 added it back in. But what if you’re still haven’t updated to SP1 and you’re getting warnings/errors about running out of space?
Obviously - up the space so as to avoid additional noise from your users. Then - figure out which libraries are taking up the most space.