InfoPath Dev

We have been using the DBXL product for a number of years without any issues until a recent infrastructure change which occurred, driven by the central IT function.  As part of an upgrade project, a new domain was created and as machines were upgraded to Windows 7 they were added to this new domain.  Unfortunately, our SharePoint and databases servers remained on the old domain and this now seems to be causing an issue for new users when submitting data.  User accounts were also migrated onto the new domain along with AD groups.

Our forms contain both push and pull functions - reading the name of the form author from the active directory as well as permitting the usual form submission.  Users who had an account on the old domain prior to migration are unaffected and are able to use the forms and submit data as normal.  Users who joined since the migration and subsequently have an account on the new domain can open the forms and user the data connections to read in the name of the author, etc but are unable to submit forms with the system complaining about a lack of permissions.

Access to the web service is controlled by the same AD group and hence cannot understand why it allows the user to access the web service and draw data from the AD, but won't work the other way around and accept data from the form.  I have considered that the only approach would be to migrate the whole server farm over to the new domain, but thought I'd ask if anyone knew of any workarounds in the interim.

A couple of questions:

• How are individual doctype permissions configured? Are new users just not able to submit to DBXL?
• Is the user alias is the same across domains? 

If you are using the Qdabra Active Directory web service,  you can add a second domain for lookups if you have a later version of DBXL.  I believe v2.8 and later allow for altpath.  The lookup is done by alias without domain, if the alias is in the primary AD path, it will return that, otherwise it return info from the alternate if it exists.

Example:

<adService path="LDAP://DC=domainA,DC=local" altpath="LDAP://DC=domainB,DC=local">

Hi Jim,

Apologies if I don't understand your first question correctly, but there are no specific permissions set within the DBXL Admin tool.  Access to the forms is controlled using standard SharePoint server ACLs with each project having it's own subsite and then form libraries within each subsite.  Yes, the issue appears to be solely with new users into the organisation whose account is created within the NEW domain who didn't have a corresponding physical account in the OLD domain where the SharePoint farm currently resides.

The account that the system uses on the OLD domain has a mirror account on the NEW domain, but we don't have any kind of AD permissions to be able to work with groups or user accounts on the NEW domain, as it's a managed service now and we are currently running v2.7 of the tool.

Can't understand how a single group controls access to both the READ and WRITE groups and all users seem to be okay with using the web services to read data, but not to submit back.

I am considering migrating the whole SharePoint farm onto the NEW domain in the hope that it will solve the issue, as it is growing over time with more new users joining the service.