Strausy's O365/SharePoint KB

How to change the owner of PowerApps

2020-04-21T17:37:00.001-05:00

I have seen many blog posts and videos about how to change the owner of a PowerApp. The problem is that all the blogs posts out there (as of 4/21/2020) don't tell you how to change the owner to someone other than the Global Administrator running these commands. Some blogs just tell you there is a command which is supremely unhelpful. So I plan to fix that.

Q: Why would you change it?
A: In case someone created an app that left the company you want to transfer it. Or perhaps you created the app and you want to transfer ownership of it to a Service Account that will live beyond you.

Q: Why not just use the Export/Import process?
A: You can, but that is not the point of this article.

What you need

1) An Office 365 Global Administrator account and access to Azure Active Directory users portal
2) The App ID and Environment ID (more below)

3) PowerShell

Get the details

1) In a browser, login to admin.powerapps.com as a Global Administrator
2) In the Environments, select your Environment name
3) Select the Resources link and find the App want to transfer to a new owner and click on it

4) From the details screen URL you can obtain the App ID and Environment ID. For example the Environment ID will be after /environments/ and the App ID will be after /apps/. These are color coded in the example below. Copy these to Notepad or other text editor

https://admin.powerapps.com/environments/Default-b96ec01a-4e9e-4e5e-b216-f74187681f6b/resources/apps/a6f2e4c5-af2c-4ef4-8c5c-beb9bdb74efd/details

5) Ge the new owner's Object ID form the Azure AD Portal > Users > New Owner. In this case, my user is named "A Test User".

Copy the Object ID and save it to your Notepad or other text editor

6) Compose your PowerShell Script with the following template

Set-AdminPowerAppOwner -AppName 'AppID' -AppOwner 'Object ID' -EnvironmentName 'Environment ID'

My example would be

Set-AdminPowerAppOwner -AppName 'a6f2e4c5-af2c-4ef4-8c5c-beb9bdb74efd' -AppOwner 'a6ba8d8e-19c0-488b-9e20-d6cf2f76cecf ' -EnvironmentName 'Default-b96ec01a-4e9e-4e5e-b216-f74187681f6b'

Change Ownership with PowerShell

1) Run PowerShell as an administrator

2) Install the following PowerShell modules if you have not already
Install-Module -Name Microsoft.PowerApps.Administration.PowerShell
Install-Module -Name Microsoft.PowerApps.PowerShell -AllowClobber

3) Connect to PowerApps by entering Get-PowerApp
This will ask you to login to your tenant. Again, this should be a Global Admin

4) Copy and past your command. My example

Set-AdminPowerAppOwner -AppName 'a6f2e4c5-af2c-4ef4-8c5c-beb9bdb74efd' -AppOwner 'a6ba8d8e-19c0-488b-9e20-d6cf2f76cecf ' -EnvironmentName 'Default-b96ec01a-4e9e-4e5e-b216-f74187681f6b'

Done! The app is now owned by the new owner. You can reload the page in the PowerApps Admin Center > Resources > Apps to verify the owner was changed.

SqlException (0x80131904): profile name is not valid or Error 14607 Procedure: 'sp_send_dbmail'

2019-09-10T09:00:00.000-05:00

Recently I needed to patch my SharePoint 2013 on-premises environment with the August 2019 Cumulative Update (CU). After the binaries were installed on my farm, I proceeded to run the SharePoint Products and Configuration Wizard (henceforth, Config Wizard) to complete the process. Inevitably, this is where most SharePoint patches fail, but it usually takes a long time to do so. But this time, the failure was almost immediately, specifically Step 2 out of 10.

Symptoms and Error Messages
The error message indicated Exception: System.Data.SqlClient.SqlException (0x80131904): profile name is not valid. and gives you the link to the error log as shown below.

A review of the log didn't really provide any other details. After restarting the necessary SharePoint services, I was able to get back into Central Administration. I increased the logging level to Verbose to try and get more information about the error. Restarting Config Wizard and using a ULS Viewer to catch the error can be a tricky practice. Watching Config Wizard for the error to occur and go back to the ULS Viewer and select Pause. Filter your results to Critical or Error to try and narrow down only the useful information. And there it was: SqlError: 'profile name is not valid' Source: '.Net SqlClient Data Provider' Number: 14607 State: 1 Class: 16 Procedure: 'sp_send_dbmail' LineNumber: 141 Server: The "sp_" in front of that procedure is your clue this is SharePoint related.

Tip: Make sure you turn down your ULS diagnostic levels to the defaults now you have found the needle in a haystack.

Doing more research, this kind of error pointed to SQL DBMail not having a public profile for the account running Config Wizard (which should be your SharePoint Farm account). But in the 17 years of doing SharePoint patching, I had never run across this issue and this patch, with the exception of a pointless advertisement breaking Central Administration home pages, worked fine in my test environment.

Cause and Solution:
After speaking with my DBA, he had implemented a new SQL Trigger to email him whenever a new database was added or an existing database modified on the SharePoint SQL cluster. Unfortunately for me, he did not give the SharePoint Farm service account permission to it. This caused the Config Wizard to fail when it needed to gain exclusive access to a stored procedure as part of the patching process.

Unknown server tag 'AdminControls:MigrationToolPromotionTip'.

2019-08-14T14:44:00.001-05:00

I was applying the August 2019 CU for SharePoint 2013 in my Test environment. After installing the binaries, I tried to go to Central Administration to view the Servers in Farm page to verify the status.

Instead of loading the homepage, I got the error message Unknown server tag 'AdminControls:MigrationToolPromotionTip'. I was able to get to other pages within Central Admin by typing in the URL directly.

After successfully completing the Products and Configuration Wizard (which you should do after every patch), Central Administration loaded successfully. I then noticed a new advertising banner touting their SharePoint Migration tool. Not a coincidence.

SharePoint Online bug: New page opens with 500 Internal Server Error

2019-03-07T08:03:00.000-06:00

Issue:
In a SharePoint Online site collection, any publishing features (and Wiki pages) will not allow you to create a new item. Pages, Site Pages, Reusable HTML and Reusable Text using the modern interface.

Error:
Either a blank page with the standard "500 Internal Server Error" or nothing at all in the Reusable Content libraries.

Workarounds:
1) Use the Return to classic SharePoint to create these items. The errors will persist in the modern interface and you will need to manually switch each time the site is in the modern interface.

2) Change Document Library default open behavior setting. This will allow each library you set this way to behave normally. Advanced Settings > Open Documents in the Browser and set to "Open in the browser".

3) Disable the Open Documents in Client Applications by Default Site collection feature. This will prevent the issue completely.

Root cause:

Microsoft has confirmed a bug in a code release is causing this issue when the "Open Documents in Client Applications by Default" site collection feature is Active.

Outlook cannot open a new form on SharePoint Workflow Open this Task buttons

2015-12-16T11:11:00.000-06:00

Issue:
Recently a user stated they were getting an error message in Outlook stating "Outlook cannot open a new form. The form contains schema validation errors." when they clicked on the Open this Task button in a SharePoint Task assignment email.

Root Cause:
The user had created an out-of-the-box Approval workflow and inside the Request box had entered several HTML tags like <a href="site">link</a> where the site reference in the href was outside of SharePoint.

Resolution:
While I don't recommend putting HTML tags in the Task assignment emails in workflows, it will work if you reference the same SharePoint site or site collection the Task is coming from.

SharePoint 2013 Site Owner cannot manage Access Requests (Updated)

2014-09-24T10:25:00.000-05:00

I have been pulling my limited hair out for a week trying to figure out why a Site Owner will Full Control on the site would always get denied when they tried to respond to Access Requests. When they received the email and clicked on "Accept or decline this request" which goes to https://[siteurl]/Access Requests/pendingreq.aspx they would get "Sorry, this site hasn't been shared with you."

Preliminary Troubleshooting Steps

I went through each and every permission group on the site to make sure the Site Owner group was the owner of the group. I went through each list or library that had broken site permissions and made sure the Site Owners group had Full Control of those as well. They all did.

Then I looked at the Permission Level of the Site Owner's group. It said Full Control, but it also had that awful "Limited Access" permission. This site had many owners and many times they all tried their best to limit access to certain things and I got calls all the time about problems. I wasn't surprised to see yet another issue.

The Fix

As it turns out, the Access Requests page is actually part of a hidden list in SharePoint. I knew at that point, I just had to restore Site Owner's permissions back into this list it had somehow been removed from. A bit of searching and it turns out Microsoft had a KB article with just the fix for SharePoint Online. It also works for SharePoint On-Premise. Below are the steps I took:

Update - Easily Fix this issue with SharePoint Designer

An Anonymous comment to this post pointed out that SharePoint Designer can show you most of the item you need below. In fact, it it will save you a lot of time as the steps to find the list ID were time consuming. I will leave those instructions below, but here is the simple way to address the issue with SharePoint Designer.

Open your site with SharePoint Designer.
Right-click on Access Requests in All Files in the Site Objects Navigation and choose Properties.
Under Customization, click the Permissions for this list hyperlink. This will open your browser to the Access Request list permissions. (Note: You may need to initially select Preview in Browser in the SharePoint Designer ribbon to select an alternate browser. Selecting this link on my system tried to open Microsoft Edge, which immediately crashed. Your mileage may vary.)
Make the necessary changes to the permissions for the list to enable users other than those who are members of the Site Owners group to make changes to the Access Requests list

You may also need to perform the following steps to allow the Site Owner to respond to the requests.

The solution was to re-run the original permissions setup of the site, and specify the new Site Owners group as the Owners of the site. To get there, construct a URL like this:

https://<URL<URL of affected site or site collection>/[Path-To-Site]/_layouts/15/permsetup.aspx

This will open up the groups for the site. Click OK.

Once you've re-defined the default owners group in PermSetup.aspx, your new Site Owners group will be able to manage access requests.

The old way using only a browser

Note: I originally wrote this post in 2014 using Internet Explorer. You may also use Microsoft Edge Developer Tools or Chrome Developer Tools, but I have not included those instructions below.

As a user who has the Manage Permissions Permission Level on the affected site and who also has access to the Access Requests list (for example, a Site Collection administrator), browse to the Access Requests list in Internet Explorer.
Press F12 to open the F12 developer tools in Internet Explorer.
Click the Network tab in the Developer Tools window, and then press F5 to enable network traffic capturing.
Refresh the Access Requests page in Internet Explorer. After the page has loaded, press Shift+F5 to stop capturing network traffic.
In the Developer Tools window, double-click the first result in the URL list. This URL will end with "pendingreq.aspx."
In the Developer Tools window, click Request body.
In the search box, type pagelistid: and then press Enter.
The search will highlight the pageListId text. Following this text, copy the GUID after pageListId:. The GUID will be inside an opening { brace character and a closing } brace character as follows: {GUID}

Include the opening and closing brace character when you copy the GUID. This GUID is the identifier for the SharePoint Online Access Requests list for your organization.
In the browser address bar, enter https://<URL<URL of affected site or site collection>/_layouts/15/ListEdit.aspx?List=<{GUID}>, and then press Enter.

Note The <URL of affected site or site collection> placeholder represents the URL for the site collection where you are trying to change the access requests—for example, https://contoso.sharepoint.com. And <{GUID}> represents the GUID that you copied in step 8.
On the Settings page, click Permissions for this list.
Make the necessary changes to the permissions for the list to enable users other than those who are members of the Site Owners group to make changes to the Access Requests list.

SharePoint Servers with underscores. Trouble ahead.

2014-02-20T16:30:00.003-06:00

SharePoint_Server_Name = Trouble_Ahead

I recently had a friend of mine ask for some SharePoint 2013 troubleshooting help. It seemed that the server was running fine (Single Server Farm) but trying to configure a Secure Store Target Application for Excel Services that was causing grief.

The error message was "Your session has expired. Restart this wizard to continue."

The Correlation ID has a few errors, but one in particular stated "_admin/sssvc/managetargetapplicationinstance.aspx' doesn't match the Page '_admin/sssvc/managetargetapplicationfields.aspx" which in itself is not very useful.

But looking more into that error and noticing the server name is sharepoint_dev a light went on and a feeling of dread for said friend. SharePoint doesn't like underscores in server names, especially service apps on a single server farm where Central Admin is using the server name as the URL.

You have two options really.

You can rebuild your server and give it a name without underscores.
Give your Content web apps and Central Admin web app Alternate Access Mappings. You may need to recreate some service apps based on past experience. (My past experience has been with a lot of terrible system design that I always seem to inherit/troubleshoot.)

For a refresher, there are characters SharePoint you cannot use in site names, folders and files. http://support.microsoft.com/kb/905231. Typical end user errors when using them, but nice to know.

The installation of this package has failed on SharePoint 2010 August 2013 CU

2013-09-10T15:09:00.000-05:00

This post is something I encountered for the first time I can remember. Honestly, this may have happened before, but not in the last 3+ years of patching SharePoint 2010/2013 have I encountered the following error;

"The installation of this package has failed."

I've had my fair share of Config Wizard failing, but never the initial binaries failing. Did a bit of digging and the root cause was me, having had to only use one executable for patching SharePoint, not paying attention to the CU hotfix package. This particular package extracted an extra cab file, specifically ubersrv_1.cab. I mistakenly deleted that file and just tried to use the .exe.

Thanks to http://blogs.msdn.com/b/kaevans/archive/2013/06/11/sharepoint-2013-kb2726992-the-installation-of-this-package-failed.aspx for steering me in the right direction.

If it were not for Google/Bing/Yahoo (insert search engine of choice) I would still be perplexed.

Missing SharePoint 2010 Help Collections

2012-01-17T12:12:00.000-06:00

Recently a SharePoint farm I am working with was only showing a specific Help item. It was the most recent third-party tool and nothing else.

Within each Site Collection is a Help Settings link. This determines what Help Collections you can show to a user and typically contain at least the SharePoint 2010 help, but this was missing.

Stumbling through little or nothing, I found that the actual help items are stored in "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\HCCab\[language id], which in the English language pack is 1033. There were plenty of files here, but not seemed to be installed.

Using SharePoint Management Shell you can find out what Help Collections are installed. Get-SPHelpCollection is detailed on this TechNet article.

To fix this, the Help Collections simply needed to be installed using Install-SPHelpCollection, detailed in this TechNet article.

So I simply ran Install-SPHelpCollection -LiteralPath ‘C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\HCCab\1033\MS.Wss.HC.Cab’ went to the Site Collection Settings > Help Settings and checked "SharePoint Server 2010".

Seems like an easy fix, and it was, but the reason I'm writing this post is it took me way to long to find a solution. So everyone else "Missing SharePoint 2010 Help Collections", I hope this helps.

SharePoint 2010 Groups Display Item Limit

2011-10-18T10:13:00.001-05:00

The issue at hand is when you go to Site Actions > Site Settings > People and Groups. Under the Quick Launch the Groups are displayed. If you select "More..." you go to the /_layouts/groups.aspx page to hopefully sell all the SharePoint groups listed in that Site Collection.

For some unknown reason I can only see the first 30 groups. This happens in 2 of the 5 SharePoint 2010 environments I have tried this on. Some have many site collections, some have 1, some are pre-SP1 and some are post SP1.

As usual, when I write a post it is because I had a hard time finding the exact fix for my problem. There are a few other blog posts out there with the same issue, but they did not fix the issue for me. I will list those below if it may help someone else.

The fix for me was actually a comment on another post on SharePoint 2007 with the same issue by "Carlos J Sosa M" which was quite easy to do, unlike finding GUIDs and the like. I have modified for clarity.

1. Browse to "http://your site collection/_catalogs/users/AllGroups.aspx"
2. Site Actions > Edit Page.
3. Modify the List View web part.
4. Under Selected View click the "Edit the current view" link.
5. Go to the Item Limit section and choose the radio button for "Display items in batches of the specified size" and Click OK

You can now edit the view settings and change the paging value, like other SharePoint list.

Thank you Carlos!

Here are some of the other blogs with potential fixes for other users;
http://sharepointknowledgebase.blogspot.com/2009/12/no-next-in-list-of-users-and-groups.html
http://buyevich.blogspot.com/2011/03/no-paging-on-groups-page.html
http://www.networksteve.com/enterprise/topic.php?TopicId=3691
http://social.technet.microsoft.com/Forums/en-US/sharepointgeneral/thread/9d8e0fa2-05cd-40cf-8c69-d4e019521887

InfoPath cannot find or cannot access the following web server

2011-06-21T15:22:00.001-05:00

I recently had a user state they could not publish an InfoPath form to a SharePoint Form library that was not setup for InfoPath Forms Services. Since that required an Enterprise CAL it was not enabled until a license was purchased.

During the troubleshooting I walked through their form and verified it was set to the correct Compatibility level. I went into the Form Library that was created and verified "Open in Client Application" was also selected, but each time the error was that InfoPath couldn't find the server.

Having reproduced this on several sites and even different web applications and several farms, I knew it had to be either proxy or network related. I've seen numerous post about that exact error, but could not pinpoint a fix. I progressed down the path of it being a proxy issue, a LAN setting, etc., but I was wrong!

A big clue came when I notice the "New Document" was active even though I had not published a Form yet. When I clicked on it a Word document opened. Further investigation on the Advanced settings for the library showed [file].docx was the Template. That was strange.

I verified this on a different farm that it was incorrect. It should have been .../Forms/template.xsn. But every single Form library on the Site Collection was this way so I knew someone modified the Site Content Type of Form. I was right. In my case, a previous admin had modified the Default Site Content Type "Form" to be a generic Word document. Nowhere was this documented in the configuration of the farm, so let me point how important it is to document your changes in the farm in the event you get run over by a bus, or by your Admin replacing you because you were horrible at documenting anything. Also, please don't ever change the default Site Content Type, make a new one.

So why was it done? Who knows, but I'm giving the person the benefit of the doubt it was an attempt to block the use of InfoPath Forms in SharePoint. If I ever run into that person again, it is going to be with a bus.

The fix was simple. Go to the Site Collection Administration settings. Under Galleries, select Site content types. Look for Form and click on it. Click on Advanced Settings.

Instead of this;

It should be this:

I then created a new Form library and everything was published successfully. Now how exactly does that error message relate to an incorrect Form content type Microsoft?

SharePoint 2010 Spell Check Not Working?

2011-06-17T09:59:00.000-05:00

I recently had an issue where Spell Check was not working for any site, any site collection or any web app in SharePoint 2010. It also occurred in two different SharePoint farms.

The error message was "The spelling check cannot be completed because there is no dictionary installed for the current language." and occurred in any list item or page where spell check was an option.

Although you can enable/disable the Spell Checker feature in Central Admin in Manage Farm Features, it was already Activated. Deactivating and re-Activating did not resolve it.

A few other posts I read indicated it may be a permissions issue relating to the SharePoint permission levels, but those turned out to be a dead end as well

The ultimate fix was actually file permissions on the server. I did not have the local "Users" group granted Read access on the Program Files folder where SharePoint was installed. I granted that group this right, did and IISRESET an SharePoint Spell Check was working again.

Assigned Custom Tasks, Titles, Pausing workflows and the dreaded failure to resume

2011-05-20T12:53:00.002-05:00

I've had mixed results with pausing SharePoint Designer workflows based on a duration. Inevitably it will work a few times and then stop for no apparent reason when the pause duration ended. It could be the environment, a service pack level, or even a hotfix needing to be applied.

I was using the "Collect Data from User" action in a workflow and I needed to update the Title and pause for a while so that the Task List's Related Content field matched. (more detail in the Background) Pausing for any duration did not work. It simply stated "Failed to run" after pausing.

I did some research and found lots of hits on this, but nothing I could actually do. I didn't have physical access to the server to apply a hotfix or run any stsadm commands. So I tried a different approach as outlined below.

1) Added a status column on the first list, the one processing the information that the Task assignment workflow ran on

2) Modified my first workflow to only Update the Title, then set the Status column to "Updated Title"

3) Created a second workflow that also runs when a new item is created, but used the "If current item field equals value condition" to look for "Updated Title" in the Status column. This would then run and assign the Task with the Title column already updated, then change the Status to "Task Assigned".

So instead of pausing, it was waiting a brief period for that column to change, then resuming.

Background:
In my instance I was trying to assign a task to someone based on input from a Scheduling list (Custom List). That Scheduling list had a lookup column that was key piece of information located in a Candidate list. The problem was, a lookup column is not the primary column, as you may know this is the "Title" column. So when I assigned my Task it was using the Title for the "Related Content" field. Long story short, the user did not want them to enter anything in the Title field so I hid it in the content type as most people do so it doesn't appear on the Schedule form.

To overcome the Related Content field in the Task list from appearing as "(no title)" I created a very simple workflow that ran when an item was created to update the Title. Easy. What isn't easy is having that fire and update the list before the workflow assigns the task and uses the Title column. So I tried using the Pause until Duration, which sometimes would work, but then started failing. I tried extending the duration from 5 minutes to 10, to 30... nothing. Same error.

Update: Upon searching for another way around this, I cam across a great article from Laura Rogers. It utilized Information Management Policies in MOSS/SharePoint Server and I can kick myself for not thinking of this earlier. http://www.sharepoint911.com/blogs/laura/Lists/Posts/Post.aspx?List=676af157%2D7d96%2D4e15%2Da987%2D54b8a3e4d948&ID=72

References:
http://social.msdn.microsoft.com/Forums/en-US/sharepoint2010customization/thread/b84cbd31-aa97-4caf-bf99-ca30a4785714

http://richardihogan.wordpress.com/2010/11/23/sharepoint-designer-2007-workflows-with-a-pause-until-step-fails-to-resume/

Ban/Limit Access for a single user in SharePoint

2010-06-02T12:41:00.000-05:00

Recently I had a request. Secure SharePoint from people casually looking through the list of our sites. Well, the site in question wasn't public facing and anonymous access is turned off, so by default, you had to be authenticated to even see it.

"Oh no, this user is an authenticated user, they just shouldn't see it".... which got me off on a rant about how making Active Directory insecure makes your applications that depend on it insecure as well. If you provide a generic account with a password that doesn't expire, you opened up a hole. Even worse, it was just one user out of hundreds of users.

I've seen a lot of people talk about how you can jump through hoops to remove "NT AUTHORITY\authenticated users" from sites, how you can limit exposure to people adding it to your Visitors group and so on. Yeah, it works, but it is overkill in this instance.

The easiest approach is Central Administration.Central Administration > Application Management > Policy for Web Application.

Select your application.
Add a user or a group
Select your authentication method (All to be safe)
Choose Deny All

Now they can no longer access any site or page in the Web Application

InfoPath Error 5566 in SharePoint

2010-03-24T15:52:00.000-05:00

Recently a project I have been working on was to convert some existing forms to be used within SharePoint Forms Services/InfoPath Forms Services. The forms needed to have the user's Full Name instead of their logon, which is a relatively easy thing to pull out of the profiles imported in the Shared Service Provider. All went well until testing when I would occasionally receive Error 5566.

I spent countless hours trying to troubleshooting. The environment was load balanced so I had to edit my host file to point to one of the 3 servers that may be causing it. I finally tracked it down to one of the three, but nothing in my research really seemed to work. The most common "solution" people had was to disable the loopback check in the registry, one I see way too often and one that is really a bad idea on a production system. More research pointed to the use of load balancers and double hop authentication problems. All of these didn't really seem to help and I won't spend time trying to find out why.

But the simplest solution did the trick.
Edit your host file to point '127.0.0.1' to your URL of the SharePoint site
In some cases you might also need to add this as a host header in the IIS site, in my case I had to do both because of our Alternate Access Mappings (another long story).

These solutions are referenced here and here

Customization and Configuration

2010-01-29T16:07:00.001-06:00

As of recently, SharePoint is starting to take off here at my current employer. Good and Bad. Good is that it is my responsibility and I’m happy to see the usage take off like a jet plane. Bad because everyone is starting to use it all at once and they all want to “tweak” or “change” or “customize” all the things SharePoint does.

Except there is one problem. They use those terms to describe what I would consider SharePoint development. Things they want are not built-in, require custom coding of web parts, extensive use of either SharePoint Designer or Visual Studio.

So what is the problem with that? 1) I’m not a developer. I have done custom pages, custom workflows, etc., but not rewriting SharePoint controls like the Contact Details web part. 2) These simple “tweaks” are not simple. Heck, they don’t even know how to upload documents to SharePoint and they want to have the Rich Text Editor work like Word. In SharePoint 2007, that is not how it works.

Back to the point, to customize or configure and why that is important. I don’t want to discourage anyone from customizing SharePoint, I just want to warn those starting down that path. Have you thought about upgrades in the future? How will those customizations translate when a service pack is applied, when a new version of SharePoint comes out and you want to migrate the content? All those are not so simply to write off when you are talking about a site that is gaining popularity and has to be running for critical business processes.

So if you fear your users are asking for the world, use this simple statement. We can configure what is there, but we are not doing any customization of the existing features. At least not yet….

My Site link back to the Portal

2010-01-25T08:26:00.001-06:00

Sometimes I’m just baffled by how SharePoint makes the simplest of things so difficult. Case in point is the lack of a link back to your SharePoint portal from your My Site. Why?

Well, the SharePoint structure isn’t apparent to the average end user. They don’t know that each My Site is a separate Site Collection, but why do we need to punish them (and their laziness) and make it difficult to get back the portal?

This can be solved various ways. Some tedious, some simple. This is the simplest way I have seen to do it.

Launch the Central Administration URL.
Go to the Shared Service Provider site specific to the My Sites (if you have more than one)
Under “User Profiles and My Sites” select “Personalization site links”
Add a New Item
For the URL enter your Portal address, including the Default.aspx page
Add a “#” symbol at the end. Enter a description and owner and your set.

What does the # symbol do? It tells your browser to ignore anything after it. This is important because if you don’t, the Portal page will be displayed with a personal view and with My Site navigation links on the top.

This site content type cannot be deleted

2010-01-20T10:18:00.000-06:00

I will reiterate that most my posts are not for the true SharePoint Developer. Those using Visual Studio to do most, if not all, of this custom application will find better ways for the most part. No, this post is for people who want to use SharePoint out of the box and then have found themselves using SharePoint Designer workflows.

A reoccurring problem I have is that when I create a SharePoint Designer Workflow and decide later I need to redo it. I create a workflow that assigns a task and name that say "Task 1". This creates a list content type and a site content type.

Later I delete that section of my workflow, but I go back later to add it again, choosing the name it Task 1 again, but you get an error messaging stating it is already in use. Knowing full well you were the one that deleted it, how do you go about using that same name?

First, go to you Task list settings. There will be a section called Content Types. Select the one you want (in this case Task 1) and delete it.

Next, go to Site Settings, Under the Galleries section, choose Site Content Types. Find the Custom Content Types with the same name. It will probably be associated with the workflow task and Site you were working on. You can now delete this. If you were to try to do this step first, you would have received an error stating the content type was in use.

Collect Feedback Workflow never completes

2010-01-13T09:09:00.001-06:00

Here is a new one I ran into the other day. The user was using the standard Collect Feedback workflow on a Shared Document library. Then another user noticed that they received an email stating their task was overdue, even though it stated it was Completed in the Tasks list.

Initially I noticed that users were stating their Tasks were complete, but had percent complete ranging from 0 to 100%. A pet peeve of mine for sure, but why does this matter? The Collect Feedback workflow relies on this field to be 100%, otherwise the workflow never finishes.

So after a chance Google search I found a Microsoft KB article with a similar issue on the Approval workflow. As it turns out the Assigned To column must be set to allow only one person per task. Allowing multiple entries prevents the workflow from marking percent complete at all. Here is how to change that setting.

Go to the Tasks list
Go to Settings > List Settings
Under Columns, select Assigned To
Make sure "Allow multiple selections" is set to No (See Figure 1)
Note: When you change this and you have multiple users assigned to a Task, this will save only the first user. There will be a prompt stating this.

Figure 1

This does allow the Approval and Collect Feedback workflows to function properly, but it broke the Tasks lists for this particular user who had multiple users assigned to one Task. There is always a downside, but you can also create another Task list, or just duplicate a task for the other users.

Inspiration

2010-01-12T15:56:00.001-06:00

Over the years I have spent countless hours trying to find solutions to different problems or bugs in SharePoint. I'm thankful that I've had the opportunity to provide these solutions for many different companies in need.

What I'm not thankful for is that one power user in each company tends to find the little annoyances in SharePoint that drive me crazy. Things that have always annoyed me, things that I have to continually find a workaround for. That is why I created this blog. There has to be others out there that need this same information, that aren't SharePoint Developers, but SharePoint Administrators that need better information.

I'm not saying the information already out there isn't good, it's usually just poorly organized. Sometimes it is just really poorly written. And lastly I have seen many posts that are technically correct, but just don't follow through with a good solution that others can easily digest.

I'm also going to spend some time on SharePoint acceptance. Not governance, not training, but acceptance. If you want governance, Microsoft has done that quite well. What I want to address is the process at which point a company goes about using SharePoint in everyday business processes. The pitfalls you may run into when despite your best efforts, those companies treat SharePoint like nothing more than a place to link to files on a file share or don't understand what it can do to save them work hours.

Stay tuned, posts are coming fast and furious.