Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
DiscussionsAccessExcelInfoPathOutlookPowerPointPublisherWord
DirectoryUser Groups
Related Topics
Outlook ExpressInternet ExplorerWindowsMS Server ProductsMore Topics ...

MS Office Forum / General MS InfoPath Questions / January 2008

Tip: Looking for answers? Try searching our database.

Datasource Connection/Certificate Signing

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Lee Vance - 31 Dec 2007 13:58 GMT
I just submitted a post regarding an InfoPath form that I really need to
release this week.  The biggest issues that need to be resovled have to do
with the end user experience.  I've got several things that happening when
filling out the form that will totally confuse the users.

1)  I have secondary datasources pulling from SQL tables.  Originally, I
setup the data connection to connect using Windows authentication, which
causes problems for people that are not mapped to that database.  We do not
want to map any of these people to the database for security reasons.

I've change the data connection to connect using a new SQL user that we
created with the appropriate rights to the tables.  The problem is that when
someone tries to fill out the form from the SharePoint forms library the form
reverts back to trying to connect through Windows authentication.  I've done
everything I can think to do...even posting the form to a completely
different SharePoint forms library.  Could changing the unique form ID
correct this problem?

I would guess that creating web services would solve the biggest part of my
problems, but I don't really have that as an option right now so I'm stuck
with what I have unless there are better options out there that do not
require us to purchase additional software.

2)  In order to get rid of the whole "trust" dialog, I create a certificate
from my machine.  I also had to go into InfoPath and tell it to always trust
from this publisher.  When someone else tries to fill out the form, it gives
them a popup that lets them install the certificate and trust it.

I have never dealt with certificates so I really have no clue what the best
approach is.  I would guess that the certificate should be created from
Active Directory and force installed by IT in a group policy or something.  
But I'm just guessing.

I do not want the end users to have to deal with any popups or questions
when they open these forms for the first time.  What would be the best way to
get around this certificate issue?  If this is going to require interaction
with IT, what do I need to know to communicate this to them in terms that
they would understand?  I know that they have a thorough understanding of
group policies and log on scripts.  I do not know if they have ever had to
create certificates before.

Sorry for all the posts, but I'm very new to InfoPath, and I've got a
deadline to release this form this week.  Please help!  :)

Thanks
Paul - 11 Jan 2008 15:33 GMT
> I just submitted a post regarding an InfoPath form that I really need to
> release this week.  The biggest issues that need to be resovled have to do
[quoted text clipped - 41 lines]
>
> Thanks

The certificate is necessary if the form is going to be full trust.
I'd also make sure that the newly created form (from item one) had a
certificate installed as well.  I had a similar problem as the form is
published in sharepoint so it must be accessed by multiple users.  We
spent the $ on a certificate to take care of the prompt and it seems
to have worked out well.  The Office SDK toolkit does have some
information regarding this but it was just easier to purchase the
certificate.  They can force a group policy to trust the certificate
providing the administrator is good enough to do it.  I've published
multiple forms using the same certificate and it was worth the cost to
avoid the aggrivation.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.