The bossman wants to know how to delete a user in Sharepoint. We've got him convinced that deleting a user is too difficult because of traces of that user through the system, so now he wants to be able to change the username to all Xs or somesuch. I've poked around the DB and found a couple of UserInfo tables, one in SharePoint_AdminContent_<guid> db and another in SharedServices. Is there a better way to change usernames? Am I on the wrong track?
Thanks.
There is "stsadm -o deleteuser". See this TechNet article. That command will delete a user from a site collection.
You can also find more options on Keith Richie's blog. That is from WSS 2.0 / SPS 2003 era but there is a lot of good information there.
Please don't access the database directly as it's not supported ; you may even destroy integrity in the process.
If you really want to "remove" all trace of a user, I suggest looking to "stsadm -o migrateuser" to rename the user to a dummy XXX user created in your membership provider.
Edit: it's migrateuser and not renameuser, my mistake
http://technet.microsoft.com/en-us/library/cc262141.aspx
The reason you cannot remove users from SharePoint is because users are not stored in SharePoint. Users are stored in the respective membership provider: AD, aspnetsqlmembershipprovider, etc.
The process for removing a user from SharePoint's environment is to first go to your membership provider and delete the user there. After you have done this, you have a choice.
You can leave the user's artifacts for legacy information. Ie, Joe Blow created a document and even though Joe Blow doesn't exist anymore (hit by bus) it's good to know that he created the document.
Alternatively, you can run the stsadm -o deleteuser command Alex mentioned (once per site collection), which should disassociate that user from all their artifacts for that site collection. Any documents the user created will now be owned by the system administrator (I believe). An example of using this option is when the user account was misspelled and you want to remove all traces before creating the correct account.
Related
I have imported users from AD and keep syncing them for a while. Today two of users' display names have been changed on AD and SharePoint synced them correctly. Just to be sure, I checked users from User Profile Service App which looks OK. New names are appearing correctly.
Yet when I try to add a list item and select user from people picker, I get old user info. This also happens when I try to insert a list item programmatically.
Tried to delete users from SharePoint, however I still get same old users. Do you have any idea for solving this situation?
Thanks in advance.
I found the solution. There was an another User Profile Service Application which was not used and not properly configured. Weird point is, that malconfigured app was not listed on service applications. I found it by using Get-SPServiceApplication cmdlet and removed it. After removal, did a full synchronization and voila! Now I can get current information.
This is may be because entry in SharePoint's hidden user-list - User Information List.
Browse to this list - http://{SiteCollectionURL}/_catalogs/users/detail.aspx
Check for the display name of the users you have updated. If you see old user name instead of new/updated, delete these users from this list.
After this ask user to login to the same site again.
I am working on Sharepoint Online. I have a requirement that when a user has no permission to a file, he/she still can see file in search result, but no permission to open the file.
I know there is security trimming in sharepoint search. But is it possible to achieve my requirement?
As Ondrej has said this isn't possible via the OOTB search functionality and this is by design.
If you wanted to be able to see all information returned by search you would need to write something custom and impersonate a user who does have access to the document.
Impersonation of User in office 365/SharePoint online
I'd only do the above in exceptional circumstances.
I would be questioning why you want someone to be able to see something they do not have access to read.
Cheers
Truez
I have a requirement in a Sharepoint 2013 setup wherein I've to give access to external users to a document library. Each User will have a folder by their name, and would be allowed to ACCESS their folder ONLY. They are not even allowed to see each other folder names. They can anytime upload additional or delete the existing documents. External Users are setup using FBA.
Inside the network, there is a Windows user who'll have access to all the folders and documents of that library. I don;t think standard document library can handle this since there is no "Deny View" Permission in Sharepoint.
Sharepoint Folks - Please guide what will be the best way to handle this kind of requirement.
I don't think having a bunch of folders makes sense. However, you could have users upload documents to the shared documents library and have a column in the documents library of the user's username. You could then create a content query on that list to query documents that the current user uploaded. You could then replicate a "folder" type of feel by creating this page, styling it, and directing all users to it.
Let me know what you think of that.
There actually is a way to deny all users. Remove the Authenticated Users, and Remove Anonymous Access from the Library. I agree, that using folders is the wrong idea here. Folders can cause much more harm than help in certain situations.
Create a site to hold multiple libraries, or disinherit the site, remove everyone not essential to the libraries, and use it as a container for the document libraries. Each library can still have it's own unique permissions, and without Authenticated or Anonymous, you'r essentially telling SharePoint that none has access except for the users specified in the ACL's on that library.
You COULD leave the permissions intact on the site and powershell the creation of the document libraries within the site, assigning custom permissions.
We're planning to use Sharepoint 2010 as a CMS for a website we're building. This site will also have login functionality; and my boss suggested we use Sharepoint's user profile features to store user info (username, password, contact info, etc.) for the site. How is this better then say using a standard list or a database table somewhere? I'm looking into how this could possibly work; but has anyone here tried something similar? Any anecdotes about it you could share? Any constructive input is greatly appreciated.
Thanks,
Frank
You asked for anecdotes. I have an anecdote.
A while back, I was trying to set up a Sharepoint server that exposed users' personal pages to the Internet at large. We wanted to allow authenticated access, but not to require it; that is to say, normal users would have read-only access and additionally the ability to submit InfoPath form data to Sharepoint libraries created to receive the results. The users could thus post public information and create public surveys using Infopath web forms.
When I went to make access public, I ran into a few problems. The "unauthenticated users" option on the preferences page of the document library was greyed out, even when I was logged in with a super-admin account.
In the end, I had to do a little bit of URL hacking to make this work. I had to change "DOC" to "DOCLIST" in the URL I used to access the preferences page (not that exactly, but something like that) and then the "everyone" option became available. In other words, there was actually no official way to do what I was trying to do.
The whole thing left a really sour taste in my mouth about Sharepoint for Internet-facing sites. See also things like this. Sharepoint is really designed for Intranet use only. As an additional downside, it is much more resource-hungry than normal CMSen. A full Sharepoint install can, without a single user, choke a pretty powerful virtual machine. I can't comment on its scalability as I've never done a really large rollout, but I can say that the indexing service is pretty heavy on the CPU.
Seems to me that LDAP would be a better way to store information on users; if you're using Sharepoint, you've probably already got an AD infrastructure. AD stores user profile info in LDAP anyhow - what you see in "Active Directory Users and Computers" is just a glorified LDAP browser.
Here is my initial toughts:
PRO: It's "easy" to merge infomation from outer sources like your AD, to be stored with the "other" user information in order to be displayed using the same means.
CON: I haven't come across a FBA Membership provider for User Profile Store.
In our Sharepoint implementation users have been granted site collection admin rights. On a few occasions they've managed to delete a subsite or even the entire site collection. I'd like to be able to block this but not being a developer I'm finding it pretty tricky.
I've had a look at the MSIT site delete capture tool to try to understand how that's working and it seams fairly straight forward. I want to override the delete function and either block it entirely or have the user type a password. What I can't see is any way to fully override the default behavior as it looks like the MSIT tool simply adds some functionality (backs up the site) then falls back into the default behavior.
So my question is, can I prevent the default behavior or can I only add actions before or after it fires?
Thanks in advance
Change the user permissions may be the best way to go. site collection admin is a crazy level of access for normal users.
Two answers:
You cannot prevent site deletes without either coding up something yourself, or buying a product to help you with "site lifecycle management" or "site governance" or some other vague term they use to describe this sort of thing.
The Site Delete Capture Tool may be good enough for you. It doesn't prevent any kind of deletions, but it does take a crude backup that (hopefully) allows you to restore anything they delete. We're using this tool in production and it works.
You could try to edit the site settings aspx file and comment out the delete site link, don't have a setup around to try that. While users could delete the site in other ways it would prevent the most common method.
Other option for important sites would be to make sure the site has a sub-site, if one does not already exist create one and don't user any access. The site would not be seen by the users and it would prevent them from deleting the parent site.
As for programming, in the before behavior you can return a false to stop the action. Just be sure to place a work around so you can delete a site.
A Site Collection administrator has the permission to delete sites and it should stay that way. We have modified MSIT to do additional stuff
The best way to limit user privileges is to put users in the right SharePoint group (ie) Owners, Members, Visitors or you could create a new group with right permission/permission levels.