Tag Archives: User Management

Read Only users cannot access SharePoint via Web DAV

SharePoint has an alternative method for accessing it’s files, and that is via a web standard called Web DAV. This connection type has been around a long time, and is supported by the web server. This connection type allows other applications, in my case GoodReader, to connect to SharePoint and access folders and files directly.

A user who only has Read permissions is not allow log in rights into the site over the Web DAV connection. Fortunately, this is an easy fix. You can either create a new permission level, like “Read – Web DAV”, or modify the existing Read permission level to include WebDAV.

To do so:

Go to Site Actions > Site Settings.
Click Site Permissions.
Click Permission Levels in the ribbon.
If you want to add a new permission level, click on Read, then press Copy Permission Level at the bottom.
If you want to modify the existing Read permission level, click on Read.
Scroll down, under Site Permissions is Browse Directories. Check that option.
Click Submit.

That should do it. Immediately, Read users, or users in this permission level, can access SharePoint via Web DAV.

Happy SharePointing!

All People in SharePoint 2010

Finding a security management solution for SharePoint

6 Replies

I had the opportunity to assist a customer in their decision making process as they looked for a SharePoint security management tool. Basically, I was the middle man, which lets me get all of the sales and marketing emails, and protects the customer from getting harrassed by sales people ;) .

The customer’s requirements were simple:

Report on all users who have access, and level of permission, to a site.
Report on all sites a specified user has access to.
Include details on how the user is gaining their access: direct access, SharePoint groups and/or Active Directory groups.
Site owners had to be able to access these reports.
Integration with SharePoint is preferred.
Delete a user from everywhere in SharePoint, multiple web applications, site collections, etc.
Clone user permissions to a new user.

There were some secondary “nice to haves”: activity reporting, storage/content reporting, move libraries and keep metadata.

I did some initial research and narrowed down our results to AvePoint’s DocAve and Axceler’s ControlPoint. I threw it up on Twitter as well, and got some good feedback for both sides. We then reviewed any and all materials we could find on their web sites including a recorded webinar. Funny enough both of their webinars were for SharePoint 2007 (they both said the 2010 videos are coming soon) . We liked what we saw on both, and decided to get someone on the phone for a conference call and a live demo. This is where the key decisions were made.

Both systems handled the reporting requirements and the deletion and cloning of a user well. In addition, the “nice to haves” were there as well. Like I said, requirements were simple.

The biggest difference is how they each interacted with SharePoint.

DocAve:

Has a separate web interface, their enterprise management console. This utilized a separate authentication login, however did authenticate against Active Directory.
Required agents to be installed on the SharePoint servers and would discover and index the farm on a periodic schedule.
Reports can be pulled up on the fly or can be scheduled, but the scheduled reports had to be emailed or saved to disk.
There was no SharePoint integration.

ControlPoint:

Sits inside its own web application within the SharePoint farm, on an alternate port.
Imports your sites owners as users within the application. Along with activation of a site feature, admins can access their site’s reports via a link to the Site Actions menu and Site Settings page.
Reports are also available on the fly, or can be scheduled. The scheduled reports can be emailed, saved to a SharePoint library or saved to a SharePoint list (I loved this as we can now build some PowerPivot reports and PerformancePoint KPIs based on security!)
Reports can pull from cache or use current live data.

Axceler’s ControlPoint’s tight SharePoint integration made it the perfect fit for our needs!

We initially installed ControlPoint on a MOSS farm, which gave us a slew of headaches (several issues around the farm configuration and the ControlPoint application). Axceler’s support team was amazing. Daily they worked with me to resolve the issues around our farm, provided new DLLs, and everything. I hate to have to call support, but when I do, it’s awesome to have a great, responsive support team available!

I look forward to using ControlPoint as we move forward with new a new farm and migrating data and users from the old to the new!

Using PowerShell to access SharePoint Sites, Users, and Groups

15 Replies

In this post I am going to dive into some of the basics of accessing your SharePoint sites using PowerShell. This is a pretty basic concept, but something that I think is worth knowing. Understanding the basics allows us to dive deeper into the more complex stuff.

So let’s start! On one of the SharePoint servers, open your SharePoint 2010 Management Shell (Start > All Programs > Microsoft SharePoint 2010 Products). You may have to right click on the app and select Start as Administrator to get the correct permissions.

You will get a nice black window, type in cd\ to get to the root. This gives us a little more room to work with. At any time, you can type in cls to clear the screen, this is helpful to keep your eyes focused.

First things first, let’s get a site collection. Type in the following, followed by the Enter key

$site = Get-SPSite http://yoursitename

Now the $site object is your site collection. If it worked correctly, you’ll just be returned to the command prompt

Let’s make sure you have the right site, so lets check the URL. Type in the following and press enter after

$site.URL

And that should return your address to the site collection. Want to see all webs in your site? Type in

$site.allwebs

Pretty neat eh? You can get the site owner now

$site.owner

You can explore the site object and all of its properties and methods by referencing MSDN article http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsite_properties.aspx .

Initially we used the Get-SPSite command to get a site. If you leave the address off, and just type in get the command, we can get all sites back

get-spsite

Using the previous reference to MSDN, we can add additional properties for a nice report. Let’s pull all site collections with their associated content database.

get-spsite | format-table -property URL,contentdatabase

And you’ll see all my site collections are in the same database.

Ok, back to our first $site. Now let’s get the root web and check the name.

$root = $site.rootweb
$root.title

You just got your first site! Good job! There’s a slightly faster way to get a website. Instead of getting the site then getting the web, you can just call Get-SPWeb http://youraddress, and that will return the web for you.

So if you want to grab a subsite, you would call

$web = Get-SPWeb http://address/site/site/site

Now that you have a web, you can explore it’s properties and find out some more information about it. Check out MSDN article: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spweb_properties.aspx.

Back to our $root. Let’s get a list of all users in the web.

$root.allusers

Next, let’s see who’s a site admin, and whether or not any of these users are domain groups.

$root.allusers | format-table -property displayname, issiteadmin, isdomaingroup

The additional properties, issiteadmin, isdomaingroup, are from the SPUser object (see http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spuser_properties.aspx for more detail).

Let’s check out the groups of the site.

$root.groups | format-table -property name, owner, users

If you run just $root.groups (try it) it’ll dump out a lot of information at once. Formatting and selecting our data makes it easier to work with.

The above results tells us the groups of the site, and who owns it, and a sneak peak of the users within the group. Let’s explore one group to see all of the users in it.

$group = $root.groups["Sideswipe Members"]
$group.users

To get a user, you need to know the user’s ID or email address. To find this info, you can add the properties to the above command

$group.users | format-table -property displayname, id, email

No, my users do not have email addresses, so I’ll have to use the ID. Either way, you would use

$user = $group.users.getbyemail("emailaddress")

$user = $group.users.getbyid(17)

Confirm you have the right users

$user.displayname

This was a very top level overview of accessing some of SharePoint’s objects. From here, now that you know how to get some of the common objects, you can query some more, update values and properties, add users to groups, etc. Microsoft’s MSDN site is extremely helpful in exploring these objects.

Please leave a comment below if you want to see something more specific.

Initial Topology Planning: Site Collections vs Subsites

David Lozzi's Blog

Doing cool stuff with SharePoint