I wonder if someone might clarify what, during site creation, prompts the creation of the the Record Center Web Service Submitter group? Is it tied to the activation of a particular feature? Is it a required part of, say, content organizer? Our sites are not explicitly Records Centers, but these security groups still have been created...
I ask because it has had the net effect of blowing out our list of permission groups, and unless we really need these, I'd rather not retain them.
The Web Service Submitter security groups are created so that you can use the SendTo function. If you go into Central Administration->General Settings, there is a link there to configure SendTo. This is also part of the Content Organizer Rules that are connected to the Drop Off Library that is created if you enable Content Organizer from Site-Settings->Manage Site Features. BTW, I caution people on enabling this feature, as the Drop Off Library is not a deletable library (through the GUI) once it is created. Just disabling the feature will NOT give you the option to delete this library. You will have to enable deletion ability on this library via PowerShell. I intend to document this on my blog in the near future, but haven't yet.
Anyway, that security group is tied into those features. Your service accounts that handle moving files for those features will need to be in that group. I am still researching exactly WHICH service accounts those need to be, as I haven't seen anything printed from MicroSoft detailing who needs to be in those groups.
Looking at the time stamps, this is one of the epic-long forum threads on what should have been a very well-documented topic by Microsoft... but wasn't.
I'm in the middle of trying to configure this very feature as part of a storage-management solution for my current client, and this is what I've found:
- The Content Organizer (site) feature CAN - contrary to other posts - be used to programmatically send documents to ANY other SharePoint Site Collection, NOT only "Report Center" ;
- By "programmatically" you can even leverage SharePoint Designer 2010's "Send Document to Repository" built-in workflow action, where one of the parameters you provide is the URL to the "OfficialFile.asmx web service created and launched the moment you activated the Content Organizer site feature on your site (the one which is going to act as the receiver and organizer/router of incoming documents);
- THIS web service is what uses the Records Center Web Service Submitters group (if I understood the MSDN documentation in the references I found - see below), to decide WHICH "consumers" of the web service are PERMITTED to send content. Let's
see if I can describe this clearly - In the scenario where you have a ListWorkflowDEF watching LibraryABC in SiteCollectionGHI in WebApplicationPQR in Server Farm A, and that workflow attempts to use SPD2010's Send To functionality
to send (as a "move" operation in my case) a document to a Content Organizer (site) in Server Farm Z...
... then the Content Organizer web service (which typically is the Records Center web service, but DOESN'T have to be an actual "records center") demands that WebApplicationPQR's application pool identity (a domain-level service account) MUST be its associated Records Center Web Service Submitters group, or it will presumably consider the SendTo attempt bogus, and reject it.
THAT's the importance of the Submitters group you're describing.
Hope this helps,