I'm trying to move a SharePoint site from one server to another. I'm supposed to move all the users with their permissions as well. I've been told that the best way to do that is to export the users from the AD and then import the list on the target server.
Is this the best way to accomplish this? How do I export only the users and permissions and then import them?
The purist answer is to use stsadm export operation with the includeusersecurity option. Personally I'm not an stsadm fan and would recommend you use the SP Deployment Wizard tool and make sure you select the User info update to import all. That will bring in the security + user information for their profile.
Apparently you can't move an active directory with user and their permissions unless the servers you are moving it between are networked. You can then change server roles and move the directory that way. A more thorough example can be found here. Since there weren't too many users in the AD in the first place, I ended up manually adding them myself.
Related
I'm relatively new to SharePoint and am trying to put a bunch of Word
files (that were on our network file server) into SharePoint. We have
set up a document library that, by default, gives everyone access to
everything. This is the desired top-level permission set because
most items will work well this way.
The problem is that I have a bunch of documents I want to add and
apply some specific permissions to. I can do this, but...please tell
me there is some way I can do this for multiple documents at the same
time. Attempting to do this one-by-one is a pain and I'm hoping for a
better solution here.
Thanks very much in advance.
You can create a folder and set permissions on it. See Office Docs, for the user view of things.
An alternative is to have several document libraries, each one for a specific purpose (generally available or secret stuff) and the set the permissions on each library.
Personally (and it helps that I'm a powershell msmvp) I would use powershell to do this. Either v1 or v2 should suffice. If you run powershell on one of the servers in the sharepoint farm you will be able to load the sharepoint object model directly and programatically configure the ACLs on each document. Powershell can read the ACLs from the documents in the nextwork share quite easily:
dir \\server\Documents\*.* | get-acl |`
select path -expand access | ft -GroupBy path
This example will read all files from the share, grab the NTFS ACL from each one, expand the ACL into ACEs and will group by the path. If powershell is not running on a farm server, you can still upload and configure security via one of the webservices. PowerShell v2 would be more suitable here as it has a great cmdlet called New-WebServiceProxy that will generate a proxy in a snap.
If you want some help with the specifics of the script, follow me on twitter #oising and DM me.
-Oisin
I am currently working on a custom SharePoint web part (WSS 3.0, not MOSS) that will pull in information for all of the users in Active Directory to build an up to date employee directory. This web part shows things like phone number, address, and other similar fields. The issue that I am having is that, by default, the SharePoint web site on IIS is running as the user IUSR_. This user does not have access to Active Directory, so I am unable to retrieve any user information.
To get around this for testing I have hard coded the credentials for a test user which I added just for this purpose. This, obviously, is not ideal. If anyone removes this user or if they ever change the password then the web part will break and they will have no way to fix it (they have no in-house developers to take it over once I am finished here). To fix this problem, I would like to make the Username/Password custom properties on the web part so I can pass those to Active Directory to retrieve the information I need. The issue I am having with this is that the password is stored in plain text so anyone can read it. I would like it to display as ******** or something similar. Is there a way to make a custom property on a web part a password type?
If this isn't possible, can anyone recommend another way to accomplish what I am trying to do? At this time I cannot change the user that the SharePoint website runs as. Although, if I cannot find any other solutions I will try again to persuade them.
Thanks in advance!
We use a service account for that. That service account is solely used for that. Something like DOMAIN\SPS_AD_READ_CUSTOMER
In our documentation that we deliver when putting the application in production that account is put in the list of stuff that is needed to make the webpart run. If the webpart ever fails, the ITPro can go to the chapter and check if everything is still ok.
It's not ideal, but I don't really know another way on how to fix it.
I would go with custom Editor Part, then set up a control of TextBox with property TextBoxMode set to Password, then override methods from type EditorPart - SynchChanges() and ApplyChanges() to set and retrieve values.
tip: override method CreateEditorParts of a WebPart type to start with.
On the "My site" feature of Sharepoint there is a "memberships" Web part that shows the distribution list that the user is a member of.
This is picking up several groups that we would rather not be shown e.g. some that have been set up for administrative purposes only.
Is there any way to control which groups are shown; ideally this would be using another AD group and setting that only members of this group are shown.
I'm fairly sure this won't be possible without a custom web part that is deployed instead of the official part. The reason the Exchange solution doesn't work is because it's going the wrong way (from group to member instead of member to group).
To deploy it you can look at feature stapling... you would need to update the existing sites as well.
This is not an easy answer. I don't believe there is an easy answer.
The best solution would be to set a Deny Access Right for the distribution lists in Active Directory; follow these steps:
1) Open Active Directory Users & Computers as an admin (any user with access to creating groups and modify distribution list security settings).
2) Go to the View menu and make sure that there's a check-box next to Advanced Features.
Create a new security group in Active Directory (call it HideFromSharePoint or something) and add the SharePoint Content Access account (in my case DOMAIN\sa_spcontent) to that group (has to match the account used in step 4).
3) For all of the distribution lists that you don't want to show up in SharePoint do the following:
3a) Open the distribution list and select the Security tab (Advanced Features must be checked for this tab to be shown).
3b) Click on Add and type in the name of the security group that you created in step 3 (HideFromSharePoint); click Check Names and click Ok.
3c) Under Permissions for HideFromSharePoint; check the Deny box next to Read (it's set to Allow by default) and click Ok and Ok again at the prompt.
You've just denied any members of the HideFromSharePoint group read access to the distribution list.
4) Go to SharePoint Central Administration; SharedServices1; User Profiles and Properties; Configure Profile Import and under Specify Account enter the credentials of the account that you added to the HideFromSharePoint-group in step 3. (For some reason if you leave this to using the Default Content Access account SharePoint will use some other account to access Active Directory and thereby being allowed access to the distribution lists. You could experiment with adding other SharePoint service accounts to the HideFromSharePoint group but I think it's safer to specify an account explicitly so that you know which account is accessing AD and importing the data.) Also make sure the "Import Connection" for your Active Directory is set to "Use Default Account" (thereby "inheriting" the account used for Profile Imports).
5) Go to SharePoint Central Administration; SharedServices1; User Profiles and Properties and click on Start full import. (You can't do an incremental import because nothing has changed for the users in terms of group membership; it's just the access rights that have changed.) After completion of the full import (click Refresh until "Import time:" says "Started full import at 11/25/2009 ##:## AM - Ended import at 11/25/2009 ##:## AM")
The distribution lists should now no longer show up under Memberships.
A couple of things to note:
You have to set the Deny Access Right explicitly and individually on all of the distribution lists that you don't want showing up in SharePoint. That's because the special AD-group "Authenticated Users" has read access to every object in the directory by default and explicit Allow Access Rights trump Deny Access Rights set (for example) at the organizational unit level.
While you could skip the step of setting up the HideFromSharePoint-group and set the Deny Access Right directory for the SharePoint Content Access account Active Directory administration best practices is to use a group when configuring security permissions. (Then you can add additional members to that group and have those denied read access too.)
You might have to wait a while (5+ minutes or so) between setting the the Deny Access Rights for the changes to replicate to all of you domain controllers. Otherwise the import might read from a domain controller where the Deny hasn't yet come into effect.
Be careful adding any other accounts to the HideFromSharePoint-group because this might break your distribution lists. For example; if Exchange can't read the groups mail won't work. As long as you just add the SharePoint Content Access Account you're safe.
Also (and this has nothing to do with SharePoint or the solution above) be aware that any user in your domain can fire up ADUC or a LDAP tool and see the members of your distribution lists that way. If you have anything "Top Secret" you need to experiment further with setting access controls in Active Directory.
I assume that your "memberships" web part is using the SharePoint people picker functionality internally.
If that's the case, then the following stsadm command should help you scope your AD lookup the way you want it:
stsadm -o setsiteuseraccountdirectorypath -path <name of OU> -url <URL name>
You could try editing the Distribution List on the Exchange Advanced tab, selecting the "Hide group from Exchange Address lists" check box.
I have not tested this but in theory it would stop the Distribution List from appearing the the list of groups.
Easy fix: add a JavaScript to the page on which those appear that targets and then hides the specific items by applying a CSS style.
I don't have an exact answer, but here's how I would think through the problem. Perhaps you have already answered some of these questions, but it might help to go through them again. I would look at the questions in the following order:
Is there an option in Active Directory to hide a group from SharePoint? (sounds like no)
Is there an option in SharePoint administration (either through stsadm or the actual administration site) to exclude certain users or groups in AD from SharePoint?
Is there a way to configure the web part to exclude certain users or groups from the web part itself?
Is the source code to the web part available such that you can compile the web part to exclude certain groups in the list?
Can you use javascript (as Josh mentioned) in conjunction with the webpart to hide the Distribution Lists from the webpart? (Here's a site with an example of how to use JavaScript to Hide SharePoint's Quick-Launch bar. Maybe that will help).
Those questions are in order from the widest scope and easiest to implement to the narrowest scope that is more difficult to implement. Obviously, you'd like to implement a solution that is easiest to implement, but perhaps you find yourself farther down in the list.
In the last two examples, the solution may appear quite complex, but you may be able to write code that references an XML file of sites to exclude. That way, if your list of Distribution Lists changes, all you have to do is edit the XML file and not edit the source code (of either the javascript or the webpart).
If there's not a simple solution, you'd have to make the painful choice of either 1) letting the problem remain or 2) implementing a hack that adds a dependency to your solution.
I think Distribution Groups that aren't security enabled don't show up in SharePoint. Have you checked AD to see if these groups are security enabled? This may be only for permissions purposes, so I could be wrong.
You will probably need to do a profile import before you see any changes.
You can turn off Distribution Lists entirely, which is what we are doing at my company. This is done by going to the Profile Services Policies in the SSP and disabling the Distribution List feature.
Now if you want to pick and choose the Distribution Lists, it's not that simple, but hopefully this will help someone.
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.
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.