This was a strange issue that fortunately has a technote for it…
We had a person who used to be a contractor and then subsequently became an employee in a different area. They were added to a particular site with Contribute level access, but whenever they tried to get to the site, they’d get an access denied message. In Active Directory, they had the correct information for their new position. Their My Site had all the right profile information. But when I’d use the People and Groups dialog box to add them to the site, they’d show up with the contractor information. It was as if the person in that site was different than the person we were trying to add.
After some searching (and flailing for the right combination of keywords), I found a technote from Microsoft that explained the issue:
A user’s display name is incorrect on a specific SharePoint Site Collection
A user in your organization has recently updated some of his or her information (such as the user’s display name) in Active Directory Domain Services. The information was updated correctly in the user Profile Service Application. However, on a specific Microsoft SharePoint 2010 Site Collection, that information was not updated.
The key is to remove them from the All People group in the Site Collection, which can be found in SharePoint 2010 at <Site URL>/_layouts/people.aspx?MembershipGroupId=0.
Once I did that and then re-added them, their information was correct, and they could access the site with no issues. Whew!
I got a help desk case today asking if I could tell who had updated permissions on a particular site. After a little bit of Googling, I was able to get the basic information for them. Go to the site in question and do the following:
- Go to Site Actions > Site Settings > Site Collection Administration > Site Collection Audit Settings
- Check to see what’s being audited. In my case, I was fortunate in that the List, Libraries, and Sites > Editing Users and Permissions was selected (which is what I want). If that hadn’t been selected, I could have only set it and audited items going forward from this point in time.
- Click OK
Now to run the audit report:
- Go to Site Actions > Site Settings > Site Collection Administration > Audit Log Reports
- Click the link for Security Settings under Security And Site Settings Reports
- Select a location where the spreadsheet report will be stored. In my case, I just used the Shared Document library.
- Click OK.
The report will churn away for a short bit and save the spreadsheet when its done. When you go into the location where it’s saved, just click on the file and Excel will launch.
There are two sheets in the report. The first is summary information (which wasn’t of much use to me), and the second sheet is the detail. You’ll quickly see that the information will never be mistaken for “user-friendly”, but you can dig through and find who added, deleted, or updated permissions to the site. It doesn’t tell you what was added or changed, but at least it gives you a general guide to who has been making updates and when they occurred.
Once I learn more about SharePoint, perhaps the other columns will be of more use to me. But for right now, this worked for what I needed.
Here’s a shoutout to a great source of free online training that’s quick and concise (and often very practical)… Qdabra’s free Thursday webinars.
Their Thursday webinars (at 8 am Pacific time, so *very* convenient for me) are only about 30 minutes long, so they get to point without much fluff. Even though Qdabra has SharePoint software to sell, they don’t tie every webinar to something you have to buy from them. It’s just very good information that is perfect for those of us who are always looking for some tip that will improve our solutions and sites.
I have an InfoPath 2010 form that is used in a particular site, and it’s designed to be used with InfoPath Filler as the client. I use a URL similar to the following on the site home page to allow the user to launch the form:
Of course, it works for me, as well as 99% of all other users. But for a few people, the following error shows up after clicking the link:
Generally I have the help desk make sure that their OS and browser is set to launch .xsn files as InfoPath, but in this one particular case it didn’t seem to make a difference. The user was still getting the error. What gives?
It turns out that if you’re using a non-Internet Explorer browser like Firefox, you’ll get this error. Since we use IE as our “standard” in-house browser, it’s a matter of having them use IE instead of Firefox or Chrome or whatever.
I realize the right answer would be to “fix” things so that .xsn files would be launched correctly (with InfoPath Filler) regardless of the browser being used. But there doesn’t seem to be a way to add .xsn files to Firefox as a “new” application to use. Given this particular situation, I’m fine with just figuring out the “why” that caused this not to work for the user in the first place.
This is one of those tips that was shown to me by Sandra (who will be known and referenced in all subsequent blog entries as SPB – SharePoint Buddy), but I kept forgetting how to do it every time I needed to remember it. Let’s fix that right now…
When you create a workflow for a list and set the trigger to run it manually, you normally have to click the dropdown next to the list item, then select Workflows, then find the right workflow, then… you get the idea.
You can take a few steps out of that process by putting the workflow directly on the list item menu… Go into SharePoint Designer (I’m using SPD 2010) and navigate to the list that contains the workflow:
The resulting dialog box will give you the options for what to name the list item menu entry, and what it should bind to:
I go back to the site and try the list item menu again, and voila!
Thank you, SPB…