Sometimes it can happen, that you want to execute a fetch simply to see if it works. And also see the results.

With the attached solution, you have the possibility to execute a fetch. Please note that this solution is not designed to generate fetches!

1. Download the solution and import it into your CRM System ExecuteFetchXML_1_0_0_0_managed.zip (5.35 kb)

2. Open the solution with a double-click.

Figure 1: Open solution

3. Then you'll find a simple text box and a [Fetch]-button on this form. Just enter your fetch in the textbox and hit the [Fetch]-button and you'll be presented with the fetch result.

Figure 2: Fetch command window - blank with [Fetch]-button

That’s it! We appreciate your feedback! Please share your thoughts by sending an email to support@mscrm-addons.com.

In some rare cases the WScript.Shell ActiveX component is not correctly registered. This causes, that the DocumentsCorePack Print in Word and TelephoneIntegration Call Number buttons are not working properly. To resolve the issue open a command prompt and enter regsvr32.exe wshom.ocx

That’s it! We appreciate your feedback! Please share your thoughts by sending an email to support@mscrm-addons.com.

Simply open the following URL:

http://SERVER:PORT/ORGANIZATIONNAME
/WebResources/ptm_WebApplicationPreloaderGroupCalendar

That’s it! We appreciate your feedback! Please share your thoughts by sending an email to support@mscrm-addons.com.

With the Directory Security Feature of DocumentsCorePack for MS CRM 2011, you can prevent users to see certain files from CRM records. Users will not be able to navigate to the associated directory within the file share or SharePoint because DocumentsCorePack will overtake the security for you. In short words: when a user is not able to see the CRM record, he/she will also not be able to see the documents.

For a detailed description, please have a look at the documentation.

However, you have to do additional steps for the Directory Security.

Each time a user accesses the documents through DocumentsCorePack, the user will be granted for this specific directory. Because it is possible that user privileges are changed, the user will not have permissions to see the CRM record anymore.

But the permissions are already granted. That is the reason why DocumentsCorePack resets the permission every night at 11pm (server time). But you have to specify a user under which the task should run. You have to do this manually.

To do so, please open the Windows Task Scheduler

Figure 1: Windows Task Scheduler

You'll see two tasks, the DCP FX-SPS Directory Security Resetter which is for FileExplorer and the DCP FX-SPS Directory Security Resetter sps, which resets the SharePoint Directory Security.

Per default, the tasks are running under the SYSTEM account which has not enough privileges to connect to CRM.

You need to specify a user which is able to read all organizations.

To do so, double-click the tasks and click on Change User or Group and specify a user which is able to connect to CRM.

Figure 2: Change user group

Now the directory security will be resetted every night to the default permissions.

That’s it! We appreciate your feedback! Please share your thoughts by sending an email to support@mscrm-addons.com.

If you receive the below error message, please make a repair install of Office. This should resolve the issue.

Figure 1: Error message

That’s it! We appreciate your feedback! Please share your thoughts by sending an email to support@mscrm-addons.com.

If you upgrade from DocumentsCorePack (DCP) Server for MS CRM 2011 v5.5 to a higher version, you have to completely remove DocumentsCorePack Server for MS CRM 2011 from your CRM.

1. Please ensure that you have a backup of all your templates generated through DocumentsCorePack Client for MS CRM 2011.
Please note: After the complete removal of DocumentsCorePack Server for MS CRM 2011, the templates will be deleted!

Unfortunately, in DCP Server for MS CRM 2011 v5.5 there is no option to export all templates (this option exists with newer versions).
So you have to do this manually.
You have to open each template in DocumentsCorePack Client for MS CRM 2011 and save it to your local disc via the Save as functionality of Word.

As soon as the new version is installed, you can import all templates via the Import Template-functionality in the DCP Server Configuration.

2. Run the uninstall routine of DCP Server

Figure 1: Uninstall routine

3. During the uninstall, you will see the following message. Please click on the [Yes]-button in order to proceed. 

Figure 2: Uninstall process - security message

If you have multiple organizations where DCP Server is installed, you will see also the following message. Please click on the [Yes]-button in order to proceed. 

Figure 3: Delete all customizations? - question dialog

4. After the uninstall is finished, please verify that the DocumentsCorePackServerCore solution does not exist on your system. To do this, open CRM > Settings > Solutions and check if there still exists a solution named DocumentsCorePackServerCore.

Figure 4: Solution overview

If the solution exists, you have to delete it manually.

5. After that, you can install the newer version of DocumentsCorePack Server for MS CRM 2011.

That’s it! We appreciate your feedback! Please share your thoughts by sending an email to support@mscrm-addons.com.

SSL enables browsers to communicate with a web-server over a secure channel that prevents eavesdropping, tampering and message forgery.  You should always use SSL for login pages where users are entering usernames/passwords, as well as for all other sensitive pages on sites (for example: account pages that show financial or personal information).

Configuring SSL on Windows with previous versions of IIS has been a pain.  Figuring out how to install and manage a certificate, and then associate it with a web-site, is something I bet most web developers don't know how to enable.

The good news is that IIS 7.0 makes it radically easier to configure and enable SSL.  IIS 7.0 also now has built-in support for creating "Self Signed Certificates" that enable you to easily create test/personal certificates that you can use to quickly SSL enable a site for development or test purposes. 

Using IIS 7.0 you can SSL enable an existing web site in under 30 seconds.  The below tutorial demonstrates how to-do this.

Step 1: Create a new website 

We'll start by creating a new web-site using the new IIS 7.0 admin tool.  This admin tool is a complete re-write of the previous IIS admin tool (and was written entirely in managed code using Windows Forms), and provides a more logical organization of web features.  It provides a GUI admin experience for all ASP.NET and IIS settings:

Figure 1: IIS 7.0

To create a new site on the box, right click on the Web Sites-node in the left hand treeview pane and select the Add Web Site context menu option. Enter the appropriate details to create a new web-site:

Figure 2: Add Web Site
 

One nice feature of IIS7 on Windows Vista is that you can now have an unlimited number of sites on a box (previous versions of IIS on Windows Client only allowed 1 site).  The 10 simultaneous request limitation on Windows Client versions of IIS also no longer exists with IIS 7.0.

Once we've completed the above steps, we will now have a brand new site running on our IIS web-server.

Step 2: Create a new self signed certificate 

Before binding SSL rules to our new site, we need to first import and setup a security certificate to use with the SSL binding. 

Certificates are managed in IIS 7.0 by clicking the root machine-node in the left-hand tree-view explorer, and then selecting the Server Certificates icon in the feature pane on the right:

Figure 3: Manage certificates
 

This will then list all certificates registered on the machine, and allow you to optionally import and/or create new ones.

I could optionally go to a certificate authority like Verisign and purchase a certificate to import using this admin UI.  Alternatively, I can create a self-signed certificate which is a test certificate that I can use during the development and testing of my site. To do so, click on the Create Self-Signed Certificate link on the right-hand side of the admin tool:

Figure 4: Click on the Create Self-Signed Certificate link 

Enter a name to use for the certificate (for example: test) and proceed with a click on the [OK]-button. IIS7 will then automatically create a new self-signed crypto certificate for you and register it on the machine:

Figure 5: Server Certificates

Step 3: Enable HTTPS bindings for our new site 

To SSL enable the website we have created previously, please select the website node in the left hand treeview, and the click on the Bindings-link in the actions-pane on the right-hand side of the screen:

Figure 6: Click on the Bindings-link

This will then bring up a dialog that lists all of the binding rules that direct traffic to this site (meaning the host-header/IP address/port combinations for the site):

Figure 7: Web Site Binding dialog 

To enable SSL for the site, click on the [Add]-button. This will bring up an add binding dialog that we can use to add HTTPS protocol support. We can select the self-signed certificate we created earlier from the SSL certificate dropdownlist in the dialog, and in doing so indicate that we want to use that certificate when encrypting content over SSL:

Figure 8: Add Web Site Binding dialog 

Click on the [OK]-button, and we now have SSL enabled for our site:

Figure 9: SSL enabled 

Step 4: Test the website 

Add a default.aspx-page to the site, and then try and hit it with the browser by typing https://localhost/default.aspx (note the usage of "https" instead of "http" to indicate that you want to connect over SSL).

If you are using Internet Explorer (IE) 7, you could see this anti-phishing error message: 

Figure 10: Anti-phishing error message

Don't panic if this happens - it simply indicates that IE is trying to be helpful by suggesting that a self-signed certificate on your local machine looks suspicious.

Click the Continue to this website-link to bypass this security warning and proceed to the site. You'll find that your default.aspx page is now running protected via SSL: 

Figure 11: The result

Well done! :) That’s it! We appreciate your feedback! Please share your thoughts by sending an email to support@mscrm-addons.com.

Appendix: A Few Last SSL Notes by Scott Guthrie

A few last SSL related notes:

• The IIS 7.0 admin tool has an SSL Settings-node that you can select for each site, directory or file that allows you to control whether that particular resource (and by default its children) requires an SSL request in order to execute.  
  This is useful for pages like a login.aspx-page, where you want to guarantee that users can only enter their credentials when they are posting via an encrypted channel.
  If you configure the login.aspx-page to require SSL, IIS 7.0 will block browsers from accessing it, unless they are doing so over SSL.

• Within an ASP.NET page or handler, you can programmatically check whether the current request is using SSL by checking the Request.IsSecure property (it will return true if the incoming browser request is over SSL).

• You can set the requireSSL attribute on the configuration section within web.config-files to have ASP.NET's forms-authentication system ensure that forms-authentication cookies are only set and used on SSL enabled pages and URLs. 
  This avoids the risk of a hacker trying to intercept the authentication cookie on a non-SSL secured page, and then trying to use a replay attack from a different machine to impersonate a user.

For more information on IIS 7.0, please read my earlier IIS 7.0 overview blog post.  Also make sure to check out the www.iis.net website. 

To read more of my Tips and Tricks blog posts, please visit my Tips and Tricks Summary Page.

Source: The RIGHT way to enable SSL on MOSS Web Applications

I have been going back and forth a few times on enabling SSL on MOSS 2007 Web applications and here is the way that I have found to work best.

1. Go to central admin --> Create or extend a new web application --> Create a new web application.

2. Fill in the Web app, DB and App pool names as usual. Select yes to enable SSL on the web application. If you are using host headers for this web app, then enter those too. (Important: Make sure to set the port to 443, not 80).

3. After the web application has been created, reset IIS and then open up IIS mmc. Scroll to the IIS website that MOSS just created for you and select the right SSL certificate from the available certificates (Ask your network folks to generate an internal or external SSL cert for you depending on whether this is a test or prod server). Important: Go to the Home Directory tab and click Advanced. Make sure you set the host header and the right IP for port 80. For SSL entries, select port 443 and the IP. (If you have multiple IP's on the server, I usually pick one here for these entries). Click on the edit button for SSL entries and check the 'Require SSL' box. Also check 'Require 128 bit encryption' to make this more secure.

4. Now go ahead and create your first site collection for this web app. MOSS will automatically create a new site collection for you and present you with a "https://.." link upon completion. You should now have a SSL ready web app.

5. By default, if you want multiple web apps using SSL on the same server - this does not work in IIS 6. If you want multiple MOSS 2007 Web apps to be SSL enabled, there are two ways of going about this. One way is to get as many IPs as you want SSL web apps for that web server and assign one IP per host header settings for port 80 and 443 under IIS Website properties --> Home Directory --> Advanced. The other option is to modify the IIS metabase to allow multiple SSL web apps on the same IP. Be careful with the second option and make sure you know what you are doing.

That’s it! We appreciate your feedback! Please share your thoughts by sending an email to support@mscrm-addons.com.

1. Verify that the values under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders use valid drive letters.
2. If there are invalid drive letters, change them to point to valid drives. 
3. Try to install the software and check if that helps.

That’s it! We appreciate your feedback! Please share your thoughts by sending an email to support@mscrm-addons.com.

In an IFD Environment it is hard to implement a FileShare which is available through the Internet. We found a product named WebDrive where you could configure, for example an FTP which will be mapped to a local drive.

Here is a link to the product website: http://www.southrivertech.com/products/webdrive/winindex.html 

You are able to connect to FTP, WebDAV, FrontPage, GroupDrive, SFTP (ssh) and Amazon-S3.

We tested the tool and in combination with DCP FileExplorer Integration it works really fine.

To configure WebDrive, please follow the user guide of WebDrive. The important thing is, that you have to install WebDrive on the CRM Server and on all Clients. And the WebDrive must be mapped on all machines to the same local drive letter. E.g. W:\

Per default settings the WebDrive caches the files. So when one user creates a document and another user opens the file location, it could be possible that the file doesn’t exist for the second user because of the cache. In the WebDrive settings you have to set the Cache options to None.

Figure 1: WebDrive settings
 

After you have configured WebDrive to e.g. W:\ you have to configure the FileShare for the FileExplorer Documents in the DCP Config also to W:\

Figure 2: WebDrive settings - FileShare 

Figure 3: DCP Server Config Setting

After these steps you should be able to use FileExplorer integration in an IFD environment.

That’s it! We appreciate your feedback! Please share your thoughts by sending an email to support@mscrm-addons.com.