While opening files in Explorer to a connected SharePoint Document library, you may receive a warning that action is unsafe, etc. The fix to this for network drives is to add them to the Intranet sites in Internet Settings. It isn’t clear how to do this for SharePoint as using SSL gives you a address such as \\sharepoint@SSL\davwwwroot\. Adding this site to your list just results in it storing SSL as an address rather than the full address you want (i.e. sharepoint@SSL). The fix is simple, just use registry
Windows Registry Editor Version 5.00
I’ve directly added sites to my intranet sets in the past before with registry. It is how I manage my company so users can still modify their trusted sites, but I can inject the proper trusted/intranet sites they need for things to work.
I was looking for a way to accomplish the need of making it easier for users to access a SharePoint Document Library, with the plus side of being able to add this into a GPO and letting it be mapped across the domain. Of course you can add a network location to a SharePoint Document Library, but I didn’t know of a way to script that via a GPO logon script. I really didn’t research much into that, I figured mapping drives would be easier to explain to users.
It turns out this is really simple to do. The SharePoint server maps it as a WebDav path on a network share. So by using \\SERVERNAME\DavWWWroot\ I got the root of the SharePoint site. From there, I just filled out the rest. Such as \\SharePoint\DavWWWroot\Shared&20Documents links to the Shared Documents library on the SharePoint site.
From that point on, its as simple as using a GPO to deploy this and map the drive.
While configuring Reporting Services on a server running Windows 2008 R2, I came across this issue. After some searching I found out Microsoft has a kb article about this (http://support.microsoft.com/kb/972328), however it mentions only applying to MSSQL 2005. Well the Server I had had MSSQL 2008 R2, as well as SharePoint 2010 and Exchange 2010. It seems that this fix also still works. So if you are confused as to why this is happening and think the article doesn’t apply to you, give it a shot anyways.
Info Path 2010 does not let you change the field type to a fill in or any other type. You have to use SharePoint to modify the column. However once you do this, even when you reopen the modified form in InfoPath, the drop down does not change to a Fill-In type. It seems while the column is updated (and InfoPath asks to update the changed columns), it doesn’t update the binding in the form.
In addition it seems that InfoPath 2010 doesn’t allow any option or checkbox to enable Fill-In type. The only way around this is to delete the control field dropdown (not the field) and add the new one (by dragging it in). Not the friendliest of setups when you have rules and other changes to the control.