InfoPath Dev

Yes, both of these methods come from the same web service - UserProfileService.  They also accept the same parameter for retrieving data.  If GetUserProfileByName works, then GetCommonMemberships works, since they work the same way.

I just got a reply from the service ppl and the permission is disabled for everyone in domain. Is there any alternative to solving the problem then?

 I was thinking of having 2 libraries and setting the rules for submitter and approver in form and then moving it to the second library after approval where only the group has access. But in this approach, i need to set the save location dynamically to point to the library form is stored in as it will be editied in both libraries.

 Could you provide me with help in doing that?

 Thanks

I would be finding out why that is disabled for everyone when it's a useful piece of MOSS on the people side (beyond our use of the web services in forms).  Why would they disable such a useful part of SharePoint that can't hut anything?  I assume you also have MySites turned off, which some organizations prefer, but Personal Features does not allow MySites.  That would be Personal Site, which is right above it.

That's a real shame as that will really restrict you.  However, you can use the Qdabra Active Directory Web Service to do all the same stuff, and it's not expensive. Instead of relying on the SSP Profile Database, it reaches out straight to AD to get this same type of info.  I'd try that before building some funky workaround as long as you can spare $249 for such a useful tool.

They said as it was related to mysites which was not supported/wanted in our environment, it was disabled.

Very poor decision as it does not enable mysites and can be used without mysites.  Very, very unfortunate...

Hey Clayton,

Can you expand for me on the GetCommonMemberships. We have a combination of distribution lists and security groups set up in AD. I'm really interested in obtaining the security groups from AD as these are what we are using to define roles in our organisation so will be perfect to modify views in my InfoPath forms based on roles. I tested this in my form and it brings back those groups with a distribution group type but not the security groups. Is this standard behaviour?

Thanks.

No, it just gives them the name of DistributionList, but they aren't DLs.  Those are actual security groups, because SharePoint only uses Security Groups and cannot recognize actual DLs.  You should be able to see that if you compare the results with what is in AD and with what you use in SP.  I wish that method would pull back SharePoint Group memberships, but it doesn't.

Don't be fooled by the DistributionList label - this is the information you want and can use.

Hi Clayton,

Just to be clear. I have checked this against AD. It is pulling back only DLs from AD. We also have AD groups created which are of the security group type. So in AD, when you create a group you can either make it a DL or a security group. The security groups are not being pulled back through this web service. I'm not referring to SharePoint groups here.

Just wondering if this is standard?

Thanks.

Are you sure?  I double-checked, and you are right that it does pull in DLs, but for me, it also pulls in SGs.  I am VERY familiar with both, because it's one of the first things I look at when I walk into a new environment.  My current client had (and still has) a mess, because they had duplicates for every group - one a DL and one an SG.  Theyhad not been assigning email address to the SG, but I have no idea why.  So, they had to add/remove people from 2 groups each time, and when I went to use groups in SP, I could only get to some random ones that actually were SGs, but none of them had email addresses.  They're soon to reconcile all of them and get everything turned into an SG while cleaning up the dupes.

Anyway, I had some of the previous DLs converted to SGs (a simple radio button toggle), and some others I got created as SGs as new.  All of my personal DL and SG memberships show up, which in the end is more powerful.  The fact that SP can only leverage SGs, but this web service allows us to compare both SGs and DLs could be an extra boon.

Do you not see _any_ security groups?  Not a single group that shows up for you in this web service's results can be used for permissions in SP?

Ok, this is good to know that SGs should appear as well.... I was thinking...what's the point if you can only get DLs? Anyway, no, I don't see any security groups at all. Any suggestions why this might be happening?

It's strange because in our intranet we follow the process of adding users to AD security groups > then add AD security groups to SharePoint groups. All these AD security groups appear in SharePoint when I'm assigning permissions so why wouldn't they be coming back in through the web service?

Yes - I have too seen some major messes in AD, luckily we are only small at the moment and I'm in control of SharePoint and AD and I'm anal so I won't let it get messy :-)

Well, tell me this.  If all you see are DLs for yourself and not any SGs, why is it that you HAVE DLs that you are a member of that are not SGs?  How many do you have?  I don't see much reason for a DL when you have SharePoint, because it does the same thing a DL does.  Do you have some reason for having DLs that you're a member of at all?  What happens if you go change a DL that shows up in this web service to an SG.  Does it disappear?

This web method is part of the UserProfileService, which pulls from the SSP profile database.  It pulls its info from AD via the profile import.  That is why I had thought at first that it only would pull SGs, but you pointed out that it pulls DLs.  I have no idea why the profile import would pull in that info, but maybe it's because it can't differentiate the object in AD, since it obviously refers to them all as DistributionLists.  I can say 100% that I am seeing SGs.

We only have one DL (the one that is getting returned by the webservice) and that was set up by someone else and really is a legacy that I want to get rid of but just haven't got round to it yet. All other groups in AD are of the SG type. I haven't tried changing a DL to an SG but will give that a go shortly.

So, the only thing you get is one record, and it's that old DL?  You don't also get SharePointSite memberships (not SharePoint Groups, but sites)?

I get a big long repeating table of DL/SGs and Site memberships (not useful).  Do you do regular profile imports?  Have you done one in a while?

Yep, I'm also seeing SharePoint site memberships iin the long repeating table.

Just went in and looked at the profile import logs. All DL imports have this next to them "The directory property cannot be found in the cache". I'm guessing this is causing the problems. Any suggestions?

Wow, that's a new one.  I can only find one instance of that error online that has to do with SharePoint, and no one answered it.  That sounds like it's definitely why you aren't seeing SGs, but it's interesting that the SGs still work in SP.  I guess when adding permissions, SP doesn't leverage the profile database, but rather goes straight to AD.

Try making a new DL and run your import - see if it comes through.  Then, change it to an SG and run the import again.  See if it works or if that exact one gets the same error.