Tuesday, September 30, 2014

SharePoint 2013: Update User Information without User Profile Synchronization Service

I had to update user information in SharePoint 2013 without using the User Profile Synchronization Service. I used a PowerShell script to do so. The user, who need an update need be entered in a XML. Here's the script:
Add-PSSnapin Microsoft.SharePoint.PowerShell
Import-Module ActiveDirectory

# Load XML file
$configFile = "PATHtoXML\XMLNAME.xml"
$config = [xml](Get-Content $configFile)

foreach($userName in $config.Users.User)
  Get-SPSite -Limit All | foreach
    $web = $_.RootWeb
    if ($_.WebApplication.UseClaimsAuthentication)
      $claim = New-SPClaimsPrincipal $userName -IdentityType WindowsSamAccountName
      $user = $web | Get-SPUser -Identity $claim -ErrorAction SilentlyContinue
      $user = $web | Get-SPUser -Identity $userName -ErrorAction SilentlyContinue

  if ($user -ne $null)
      #Cut off domain information [AD]
      $parts = $user.toString().Split("\");
      $cutUser = $parts[1]
      # Get all user properties from [AD]
      $adUser = Get-ADUser -Identity $cutUser -Properties *
      $web | Set-SPUser -Identity $user -SyncFromAD
      # Get User Information List [SP]
      $list = $web.SiteUserInfoList
      #Query for user [SP]
      $query = New-Object Microsoft.SharePoint.SPQuery
      $query.Query = "$user"

      foreach($item in $list.GetItems($query))
        #Update the User Information in SharePoint
        $item["WorkPhone"] = $adUser.OfficePhone

And here's the XML:

Thursday, September 25, 2014

SharePoint 2013: Geolocation Field

Back in 2007 I needed to implement a map in SharePoint 2003 / 2007 to show locations like HQs. I decided to go with Virtual Earth, now Bing Maps, and use a xml to provide the actual locations I want to show on the map. It worked, but lets just keep at that. Now, with SharePoint 2013, I heard of this field "Geolocation", but I wasn't able to find it anywhere. Of course I searched the Interwebz and found a couple of blogs and possible solutions, but sadly none of the worked 100% for me. So this is how I finally got the Geolocation field.

First, we need a list, so I created a custon list, which looks like this:

Now we need the field, unfortunately I was not able to add it via UI. PowerShell it is.
Add-PSSnapin Microsoft.SharePoint.PowerShell
$web = Get-SPWeb "http://win-51thg297n5l:31132/sites/cinfo"
$list = $web.Lists["Company Locations"]
$fieldXML = "<field displayname="GLoc" type="Geolocation">"

It should look something like this:

When you are adding an item, you have two options for the location data. I picked the first one, but forgot to create a screenshot for that.

As you can see below, you have this little icon. Click on it an a small map will pop up.

An about that little banner telling you, that you need an account. PowerShell.
Add-PSSnapin Microsoft.SharePoint.PowerShell
$web = Get-SPWeb "http://win-51thg297n5l:31132/sites/cinfo"
$web.AllProperties["BING_MAPS_KEY"] = "YOURKEY"

Something else that is pretty cool: Map View.

The whole process still got some flaws, but I guess that's a problem with the whole cloud-first thing. It seems that SharePoint Online can use this without all this PowerShell stuff. I like this thing, I needed it a long time ago and from time to time, I guess, I will need something like that again. It could be a bit cooler if I could enter a city and Bing would get the coordinates for me, but that is something a workflow of some kind can handle.

Wednesday, September 24, 2014

SharePoint 2010: Get used Databasesize

I needed to know the database size of every database SharePoint 2010 uses. And I also needed information on the size that the database actually needs.
This gave me a little headache but, as always, PowerShell came to rescue me! With this little script you can get the databases, sorted from biggest to smallest, and also how much space they need (in MB)

Get-SPDatabase | Sort-Object disksizerequired -desc | Format-Table @{Label="DB Name"; Expression={$_.Name}}, @{Label="Size"; Expression={$_.disksizerequired/1024/1024}}

Sunday, September 21, 2014

SharePoint 2010: Search and Crawl not working

I got this error message out of the blue:

"Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository beeing crawled is a SharePoint repository, verify that the account you are using has "Full Read" permissions on the SharePoint Web Application being crawled."

The crawl account got enough permissions. I also checked the DisableLookbackCheck entry in regedit.
What I missed was: You need to set this setting on every server which is running the search components!

Here's how to:
1) open regedit
2) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
3) Add a 32Bit-DWord, Name "DisableLoopbackCheck"
4) Set Value to "1"
5) close regedit, start your crawl and be happy.

I can't stress this enough: Do this for every (EVERY) server which is running search components!

Thursday, September 18, 2014

SharePoint 2013: Metatags or Folder?

It seems that this is still a thing. I thought we've been through folders at the beginning of SharePoint 2010. I thought we were done with them. They were gone. Forever. For good. Never coming back. But I was so, so, so wrong. That's way I'm writing this blog: Don't use folders! They suck. And here's why:

1. Usability
Let's say: I'm creating a document library with 10 folders, also some folders nested within them. And I just tell you "Search for all files in the folder 'Betatest'". You have no idea where this folder is. Have fun clicking through all the folders and subfolders just to find that one folder. Wouldn't it be smarter to use Managed Meta Data Navigation? Yes it would be smarter, because you don't need a refresh everytime you switch a tag. You can first check every tag available and then choose to click on the right one. You still have to search, but you will be much faster. Oh, btw.: You can sort or filter while using meta data. Ever tried this with folders?

2. URL length
This is still a thing and it will still be a thing in the next years. Folders are a part of the URL and the limitation still sucks. Sometimes you simply can't have folder names that are long enough to explain the content. So maybe, just saying, you should use meta data or content types? You should.

3. File URL
Ever created a folder structure and realized you have a typo somewhere? But the link is already sent to everyone who needs to work with it? Well. If you would have used meta data, you would have been able to simply change the meta tag and be done with it.
Or have you tried to move files around? Everytime you have to move them to a different folder, the URL will also change. If you would only change the meta tags, the URL would stay the same.

4. Different views for different users
This is a great thing: Every user could create a view which only displays the data he/she needs. Won't work with folders.

5. Data integrity & duplication
If you allow users to create folders, in the end, they can have a lot of funny names. I found folders named "sharepoint", "Sharepoint", "sharePoint" and "SharePoint". Why not create a meta tag for this and everyone will get it right? Why give users a change for spelling errors? And the other thing about those four folders was: Guess what I found there. Just guess.
Yes, the same damn files, just different timestamps. Well done folders, well done.

6. Why SharePoint and not a file system?
Let's face it: You can have folders on any server, any file system, anywhere. Why spend so much money on SharePoint instead a cheap file system? You will have the same problems with folders on a file system, that's why SharePoint offers meta data. It's so much better than folders, otherwise you are just burning cash.

7. Permissions
I got this a lot. "We can set permissions on a folder and every file in there will have the same permissions. It's super easy and fast!" It is. Until your users are copying the files to different folders. The permission will change, they might loose the file or the wrong people work on the files. If you are using meta tags you might set permission on item level, but they will stay the same as long as they are in this library. Changing a meta tag won't change the permission! Or you just start using a couple of libraries and start setting permissions on library level instead on file level. Anyway: To keep track of every permission set on folders in huge libraries you would have to write a lot of documentation. And trying to keep up with changes might be really hard.

Meta tags rocks. Easy, fast and well-arranged. Shorter, consistent URL. They rock.
Don't use folders. Never.

Tuesday, September 16, 2014

Nintex Workflow 2013: "Something went wrong" / Can't activate Nintex

Well. something clearly went wrong. But what? Except the "Something went wrong" message I got nothing.
I was trying to activate Nintex Workflow 2013 via Internet Explorer and got up to this point.
What was wrong?

I have no idea, but I was able to activate the feature with PowerShell:
$nintex = Get-SPFeature -Identity 0561d315-d5db-4736-929e-26da142812c5
Enable-SPFeature $nintex -URL "THEURL" -Force

How did I get the ID for this feature?
Get-SPFeature | select ID, DisplayName, Scope | Export-Csv C:\FeatureList.csv
With this list, you can get every ID and just activate them with PowerShell.

Monday, September 15, 2014

SharePoint 2010: Hide Tags and Notes

I'm using MySites and also use the Social Features on a couple of sites. But on one of the lists I needed to hide "Tags and Notes" without deactivating the farm feature. I used this CSS for it:
<style type="text/css">
display:none !important;
This "#Ribbon\.ListItem\.TagsAndNotes" will remove the "Tages and Notes from the Ribbon:

You can find the ID via IE Dev Tools: