Thursday, December 10, 2015
Scenario: SharePoint 2013 server Enterprise Farm, installed SP2013 SP1 + CU October 2015:
This is the default User Profile Picture Library on the Mysite Host. I have some accounts. Me (Peter), test account ‘Clint’, 'Alex' and the SPSadmin (Administrator of the farm):
Logged on as the SPSadmin account:
As an administrator (spsadmin), when you go to the Central administration -> User Profile Service Application -> Manage User Profiles. Find another user like ‘Clint’ -> select ‘edit my profile’. You'll get the following:
When you (as the SPSAdmin) change the profice picture here and upload a new picture, Save and press ok. The user Clint's picture is changed to the new picture.
When you view this as the logged on user 'Clint' it will show this (correct):
But also the picture of the logged in administror (spsadmin) who just changed the picture, will be changed to the same picture of Clint. You can see this by going to the User Profile page of the SPSAdmin account and it will now also show the picture of Clint!!!:
When you go to the Mysite Host and the User Profile Pictures library, you’ll see that there are still 2 different pictures for both the ‘Clint’ account and the administrator ‘spsadmin’! And the SPSadmin account picture has changed into the Clint picture while Clint Eastwood still has it's own picture.
When you are logged on as the ‘Clint’ account, the profile picture will look like this:
While, when logged on as the SPSadmin account, the account will look also like this:
And this is the issue! Both have the same user profile picture while in the User Profile library it looks like they should have 2 different pictures:
When I ‘hoover’ over the image and look at the properties of the image for both ‘Clint’ and ‘SPSadmin’ it will look like this:
The Clint account:
And this is the issue! It has the URL to the SPSADmin account mapping! While we uploaded the picture to the Clint account! Now both accounts have a mapping to the spsadmin account. So it looks like the User Profile Administrator account gets the mapping if you change somebody’s profile picture through the User Profile Service Application.
When a logged on user changes his profile picture through the standard ‘About me’ link, the picture upload will be fine. The issue only exist when you change ANOTHER user profile picture as an User Profile Administrator through the User Profile Service Application -> Manage User Profiles -> Edit my profile. I’ve seen this happening in at least 3 environments with clients who upgraded to the October 2015 CU for SP2013.
Anyone else experienced this issue?
**Update** On december 10th I've installed the december 2015 CU and this issue is still in here.
***Update 7 april 2016*** This issue has been fixed in the March CU 2016 update
Friday, March 2, 2012
One of my last projects included a migration from a SharePoint 2010 on-premises to SharePoint Online. During the migration, I tested out some of the third-party migration solutions like Quest Migrator for SharePoint and MetaVis. In this migration I had a site collection which had a form library in which an InfoPath form was published. This library included hundreds of filled in InfoPath forms. The InfoPath itself had all sorts of logic with complex rules and actions in it. In the original on-premises the template opened fine within the Internet Explorer browser. But after the migration, the InfoPath forms didn’t open in the browser anymore. Instead, after clicking on a form, I received the following messages:
After pressing the OPEN option, I received the following screen:
After pressing the OK button, I received the following screen:
I was asked to enter my credentials from the old migrated SharePoint on-premises site! Huh? So it appeared that somewhere in this form template, it was still connected to the old SharePoint form library! So apparently, the migration didn’t go that well.
After doing some checking within InfoPath Designer in the ‘Design Checker’ option and going through all the field control properties, even tried replushing the template to this form library on the SharePoint Online site, I didn’t see anything strange. Then I looked in the SharePoint Online Site Collection if I would see anything strange. I could publish newly created InfoPath forms to this form library so my InfoPath was setup correctly.
Then I saw it. Within the form library settings, there is this link called ‘Relink documents to this library’.
When clicking on this link, I noticed that all the url’s in the column ‘Template Link’ were still directing to my old SharePoint on-premises site.
After selecting the Relink option in the first InfoPath form, the ribbon showed me the following options:
When I pressed the Relink option, the template was set to the correct SharePoint Online forms library. But when I clicked the ‘relinked’ InfoPath form, I still would get the message:
What was I doing wrong?
I then tried publishing the InfoPath form as a content type (remember to enable the option ‘Enable the form to be filled out by using a browser):
I then added this new content type called ‘Aanvraag Server’ to my forms library. I then had 2 content types attached to this forms library, the default ‘form’ and my newly published server content type:
I then went to my InfoPath form, edit the properties and set the content type from ‘Form’ to ‘Aanvraag Server’:
After saving the document, I returned to the library settings to the ‘Relink documents to this library’. When I pressed the Relink option on this InfoPath form, the template was set to the correct SharePoint Online forms library with the content type ‘Aanvraag server’. And when I clicked on this ‘relinked’ InfoPath form, it opened within the Browser….
So it looks like in my scenario the InfoPath forms were not migrated correctly to my SharePoint Online site collection. Republishing the form as the default ‘forms’ content type also didn’t work as expected. But republishing the form as a server content type and adding this newly created content type to my forms library en ‘relinking’ my InfoPath form to this template did open the form within my browser.
Saturday, January 8, 2011
One of the nice cool features in Word (or other Office 2010 programs) is the option “Save and send” –> Save to SharePoint. You can either ‘browse for a location’ of just click on one of the recent locations you’ve opened earlier.
This way, you can save directly to a SharePoint Server.
It also works when you are in a SharePoint 2010 site and when you create a New Document from the browser, your Word 2010 will open and after editing, you can choose “Save and send” –> Save to SharePoint and ‘Browse for a location”. SharePoint will automatically find the url of the SharePoint site you created the new document from.
This works by default on my windows 7 host machine. However… whenever I’m working on my Windows 2008R2 SharePoint 2010 server, this doesn’t seem to work by default. I do excactly the same. I’m on a default team site. I create a New Document from within the shared documents library. The blank Word file opens automatically in Word 2010. After finishing my document, I try to save it directly to the Shared Document library on my SharePoint 2010 team site.
When I choose a file underneath ‘recent locations’ or ‘Browse for a location’ different things are starting to happen.When I click on the option underneath ‘Recent Locations’, I get the following error message:
After clicking OK, I get prompted with this next screen:
In contrary with what happened in my Windows 7 host environment, I cannot save the Word file back to the Shared documents library in the SharePoint team site.
When I try ‘Browse for a location’, the same thing happens.
I didn’t pay a lot of attention on this matter. In september 2010 the SharePoint Connections event was held in the Hague, Netherlands. A lot of international presenters were doing workshops in this conference. During one of the sessions, Asif Rehmani was having the same issue and he asked publically if anybody knew a solution for this. Ok. That got me triggered. So it wasn’t just my vmware instance..
Just recently I found the solution… I admit, it was by accident.
Does this picture look familiar in your Windows Server 2008 R2 image?
It lacks one important option… the ‘Disk cleanup’ option is not available. After doing some searching on the internet, I found out that this option is by default not activated withing Windows Server 2008 R2. By installing a feature (not a SharePoint Feature), this option will become available again.
The Feature I’m talking about is the ‘Desktop Experience’. The Desktop Experience feature enables you to install a variety of Windows 7 features on your server running Windows Server 2008 and Windows Server 2008 R2. For a full list of all the feature, please read this technet article.
Go to All Programs –> Administrative Tools –> Server Manager. Choose Features –> Add Features
Next, check the ‘Desktop Experience’ feature. On the popup, choose ‘Add Required Features.
Choose NEXT and INSTALL. This is a good time to get some coffee and have a little break, because it will take some seconds for Windows to install this feature. After this, you are prompted with the question if you want to restart your server to finish the installation. Of course you want to do this, so restart your server. This will take some more time, so now you can do the dishes, make your bed, send your kids to bed, watch a good movie, go to bed. Sleep. Wake up, shower, get dressed, prepare breakfast and brush your teeth. After this, you server should have restarted again and will finish the installation.
Now, when trying again creating a new document from the ‘shared documents’ library and saving it back into SharePoint, I don’t get the error message, but instead the word file is saved to the ‘shared documents’ library.
Ain’t that a happy ending.
Wednesday, August 25, 2010
What I did for my customer was adding a hidden content editor webpart on the page (mine was based on the wike template, but this issue happens also on the default default.aspx with webpart zones). Via HTML I selected the Edit HTML source within the content editor webpart.
After this I added the following bit of code…
After a couple of seconds the image was rendered. I was a happy man and was already dreaming of drinking my beer when I got home, when I pressed ‘Save and Close’. Suddenly I had 2 rendered images… I returned back to the page, edited the content webpart again and pressed ‘Save and close’ again. Suddenly I had three (yes 3) rendered images… Apparently, every time you hit the ‘Save button’ SP2010 somehow renders the code again and adds another image in the webpart…..
Within the SP2010 Content Editor Webpart, you now have the option to link to a seperate file to include in your webpart. I put a .txt file in the assets library and typed in the url. This worked and the image is only rendered once.
Question is… Is this a bug (or feature) in SP2010 or just crappy coding from the anwb developer???
Wednesday, June 2, 2010
The other day I had this issue with an out of the box WSS 3.0 site. I had created some subsites. While creating the subsite, one of the options is to choose ‘Display this site on the top link bar of the parent site?’ You can either choose Yes or No.
Choosing Yes will of course show the link to this subsite, choosing No will not show the link. Incidentally I choose No in one of my subsites, thus the subsite is not showing in the top link bar of the parent WSS site. It does show in the quick launch bar.
Within WSS 3.0 you have the option through Site Actions, Site Settings, in the Look and Feel column to go to the Top link bar and create your own custom ‘tabs’. I created the subsite3 tab and it did show now on the top link bar. Issue closed, me:1 SharePoint: 0…… Not!!!!!
Security trimmed navigation
Here is where security comes into play. When you create a subsite, automatically SharePoint makes it a security trimmed ‘tab’ or link. Meaning, if you have permissions on this subsite, you’ll see the tab. If not, the tab will not show. Nothing new under the sun is it? Just plain good old SharePoint. However, the tab ‘subsite3’ I just created is NOT, I repeat, NOT security trimmed. BTW, if you had chosen Yes and let the link be displayed on the top link bar and then deleted the link and re-created it, it also would not be security trimmed.
I’ll show you how you can see this in the Top link bar and in a real time scenario.
Through Site Actions, Site Settings, in the Look and Feel column go to the Top link bar. Click on the edit button before ‘subsite1’. Notice that the url is greyed out?
Now go back 1 step and click on the edit button before ‘subsite3’. Notice that the url is NOT greyed out?
Real time scenario
In subsite 1 and 3 I broke the inheritance with the top level Demo site collection and created unique permissions. My demo user ‘Marc Manager’ does NOT have permissions to these subsites. Marc Manager has only got permissions on the top level Demo site collection and Subsite 2.
Now, when I log on with the credentials of Marc Manager, you will see that the ‘Subsite3’ tab is NOT security trimmed. The ‘subsite1’ tab is not show, the subsite3 tab does show because it’s just a link. Notice that in the quick launch the ‘subsite3’ link has dissapeared. This is because when I created the subsite 3 website, I choose the option ‘Display this site on the quick launch of the parent site, YES’, thus making it a security trimmed link.
So obviously, Marc Manager – the guy he is - sees the subsite 3 link. When he clicks on it, he will get the logical error, and blaming the whole world and IT Pro’s for this not so friendly error message…..
the big questions is.. How can we solve this?
Okay, ready to dive into some SharePoint Designer? Open up Sharepoint Designer and open the Demo top level site collection website. Always wondered what this Navigation link was?
You can also go in the Menu Bar to Site, and choose Navigation from the pull down menu.
You will get this nice Visio kinda’ tree view of the Demo website. This is called the Navigation Map.
Within SharePoint Designer, in the Navigation Map you can also build you own top link bar links and quick launch links. Now right-click on the most right Tab ‘The SharePoint Tob Navigation Bar’ and choose ‘View subtree only’. You will see something like this:
The Sharepoint Top Navigation Bar has 4 nodes under it. One is Home, which point to the Home page of the Top level site and the others are Subsite1, subsite2 and subsite3.
Now right-click the Sharepoint Top Navigation Bar node and click New -> Page. It will add a node under the Sharepoint Top Navigation Bar. Double click it (this is very important that you do this), it will create a untitled htm page (which you can close immediately) and then back on the untitled 1, right-click it. Choose Properties. You will see something like this:
It will allow you to Edit the Hyperlink. If you scroll down, you will see that the Subsite3 site is listed and you could dubbel click it and then select the ‘default.aspx’ and click OK. After this, click once on the untitled 1.html and it will change into the newly created hyperlink. The new added node will point to the Subsite3 now. BTW, the title now shows Subsite3/default.aspx. You can change the title into ‘Subsite 3 security trimmed’ by clicking once on this title. The end results shows something like this:
Save the site and then close Sharepoint Designer. Go back to the WSS Demo site, log into this site with administrator credentials and you will find the Subsite3 security trimmed tab is listed in the Top Link Bar.
Just checking. Again, go to Site Actions, Site Settings, in the Look and Feel column go to the Top link bar. Click on the edit button before ‘subsite3 security trimmed’. Notice that the url is greyed out?
Almost there. Now go to the edit button before ‘subsite3’ and choose Delete.
Finally, go back to the WSS top level site collection Demo and again login with Marc Managers’ credentials. Marc will now only see the sites he’s got permissions on through the security trimmed top link bar.
Marc Manager is now a happy SharePoint demo user again….