Tag Info

New answers tagged

0

Friends, that's interesting! If you add groups Active Directory in Sharepoint via Powershell format Claim the script work correctly, but why? $web = get-spweb "http://projects.rvsco.ru/M143" #$Groupfull="RVSCO\gf_sp_m143_participant" $Groupfull=" c:0+.w|s-1-5-21-3547894948-444176536-1024843340-6189" $account = $web.EnsureUser($Groupfull) $assignment = ...


0

Before using it, you should read the google analytics privacy policy which is surprising readable. Here is the tag to the info they collect: https://www.google.com/intl/en/policies/privacy/#infocollect They state "The Google Analytics terms of service, which all Google Analytics customers must adhere to, prohibits sending personally identifiable information ...


0

Google Analytics does have some security / privacy concerns if you use it on an Intranet site - here's a brief writeup: http://www.analyticsmarket.com/blog/sharepoint-and-google-analytics


1

When you create a SharePoint project in VS, look at the dialog that appears: it asks which site you want to use for debugging, and the second question is whether you want it to be a sandbox or a farm solution. (or, for an existing project, you can change this in the properties of the project). There's already been a lot written on both, so read up on them ...


3

It's not supported to install Moss 2007 on Windows Server 2012, but you might be able to link them as stated on MSDN forum in this post e.g. domain controller on another server if that helps. SharePoint Server 2007 is not supported Windows Server 2012


1

NotVonKaiser in this case is correct: 1 runs under farm account and all others are under logged in user account! The logged in user account will call the nt/authenticated account on the server that he/she has authentication on the server todo what he is requesting todo! if that makes sense ;) think of nt/authenticated as if you are physically logging on ...


2

1 should always run under the farm account. For 2, 3, 4, and 5, you should be able to ferret this information out by using this code: SPUser user = SPContext.Current.Web.CurrentUser; string userName = user.Name; //you can also call user.Email here Note that this will not work correctly if you have a 'RunWithElevatedPrivileges' delegate block. Rather, if ...


1

This it problem as Word (or any other program) does not know how is user logged in within IE. The only thing they can do is to enter credentials and check Remember credentials. This stores entered credentials to local user store and allows Word to use them next time. But as you mentioned "Remember my credential" functionality does not work all the time. To ...


1

for your origional question iv answered here about getting the root web of a site: for the root web of the site collection: SPWeb spWeb = SPContext.Current.Site.RootWeb; SPList spList = spWeb.Lists.TryGetList("MyList"); if its the root web of the root site collection than roberts way is the right way to get the spsite root! SPSite URL value following ...


0

looks like your fighting a loosing battle! Having one account for all is very bad to say the least! your giving way too much access not only to services but also to SQL server!! talk about unsecure! If somthing goes wrong with that account than everything is going to go wrong. This will fail compliance with any organisation! If your company wants to be ...


1

To access the rootweb use var rootWeb = SPContext.Current.Site.WebApplication.Sites[0].RootWeb; If your user will not have access to this collection, you must open it up in elevated privileges: SPSecurity.RunWithElevatedPrivileges(delegate() { using (SPSite site = new SPSite(SPContext.Current.Site.WebApplication.Sites[0].Id)) ...


1

Problem solved. It turns out a previous developer who had developed for us a library provisioning tool for some inexplicable reason decided to set the alloweveryoneviewitems property to true in the code. This meant every library we have provisioned in our system had this value set to true. Easy to fix with powershell script changing the value to false - ...


0

Setting up user policy on web application is not proper way how to fulfill your requirements. You should set permissions on the site for groups GroupA and GroupB. Then break permission inheritance on Shared Documents. Remove permissions for GroupA and GroupB and set permissions for Admin and Doc Admin groups. Beware how SharePoint handles access check. ...


1

If you've already checked the following my apologies for suggesting it: For the document (or documents) in question, can you verify that they have not had permissions broken off from the library ? If they are in a folder, also check that the folder hasn't had it's permissions broken off. I've seen what you are describing when the document had broken ...


1

On premises you can use this: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.speventreceivertype.aspx In Office 365 You can in theory create an app that will handle the administration of those groups for you. However you'd have to hide the original permission management page (master page changes).


0

Another option would be to embed JavaScript code via Content Link property. Steps: 1) Create the following regular text file <script type="text/javascript"> <!-- JS code goes here --> </script> and upload it into Site Assets library 2) Add a reference to a file via via Content Link web part property


0

There’s two parts to this. Both the ability to save, store, the information as well as being able to later review the information in central admin. Without any detailed knowledge about what type and amount of information you would like to store I would recommend a SharePoint list. Maybe stored in a central site collection or within the central ...



Top 50 recent answers are included