We recently had an issue where DYNSA could not grant users access to companies. The User Access Screen would not allow DYNSA to check or uncheck access to any company. We found that DYNSA was not the owner of one of the company databases.

Make sure DYNSA is the owner of the DYNAMICS system database and all Company databases. Run:
EXEC sp_changedbowner 'DYNSA'
against EACH GP database.

Great Plains script error

You are getting a script error pop-up when clicking on links in Great Plains

“An error has occurred in the script on this page”

“The system cannot find the file specified”

This is occurring mainly because you are using re-directed folders in your user profiles. GP and Dynamics will try use Internet Explorer, which is trying to write to a folder under UserData. If the user logged in and had the folder redirected before launching IE, it will never create the folder in the remote location.

The quick fix is to create the folder manually, in the redirected location. IE can now write its temp files and GP and Dynamics function correctly.

Since this will happen to every new user, I have created a logon script which populates the UserData folder automatically.

Please see this msdn blog entry with specific details on the issue, and example resolutions.

The following is from http://www.interactivewebs.com/blog/index.php/server-tips/ad-fs-certificate-rollover-crm-2011/

The Fix

Basically the certificate automatically rolls over to a new one and ADFS won’t authenticate any more. Here are the steps that seem to fix this issue:

1. Open windows Powershell as administrator (right click runas)
2. Run the following commands:
3. add-pssnapin Microsoft.adfs.powershell
4. set-adfsproperties -autocertificaterollover $true
5. update-adfscertificate -urgent
6. Run the CRM deployment manager
   
7. Run through Configure Claims-Based Authentication Wizard (no changes)
8. Run through Configure Internet-Facing Deployment Wizard (no changes)
9. Restart the adfs service
   From a Command Prompt “cmd” Type
   net stop adfssrv
   then
   net start adfssrv
10. Restart the Microsoft Asynchronous processing service
    From Services Windows
    Click the Restart Icon while the Service is selected
    
11. run an iisreset from the elevated command prompt
    Start RUN “cmd”
    iisreset

While making changes to a custom report for Microsoft Dynamics CRM 4.0 we found the changes weren't being applied to reports used by the Microsoft Dynamics CRM 4.0 Report To PDF Converter. After investigation we discovered that the Report to PDF Converter was looking in the Report Server virtual directory /crmorg_MSCRM/.  The reports for CRM 4.0 are actually in /crmorg_MSCRM/4.0.  But the names of the reports are GUIDs so it is hard to figure out which report to set up int the Report To PDF configurations.  So the original consultant and republished the reports in the  organization root.  

No problem.  We opened up IE and browsed to the Report Manager page and uploaded the new .RDL file to the /crmorg_MSCRM/ folder.

Problem - after we published the new verision of the report Workflows in CRM started hanging in the Waiting state and the emails they created were hung in draft status reason with no attachment.  We forgot that when you upload a custom report to CRM the report is modified to include the parameters that allow it to be run for all records, a group of records or just a single record.  The workflow and associated email were getting hung up because the report CRM 4.0 Report To PDF Converter was running a report with no parameters.

Fix - In IE we browsed to the Report Manager /crmorg_MSCRM/4.0 folder, opened the properties for the appropriate report, clicked edit and saved the report to a temporary location.  Then we brosed back to the /crmorg_MSCRM folder and opened the properties for the report the PDF Converter was configured to use and uploaded the version we just saved.

There is an issue with the BI360 OneStop Reporting Excel Add-in by Solver  not creating the correct registry entries during installation. The installer finishes without error but the BI360 OneStop Reporting Excel Add-in does not load when you open Excel. As the BI360 OneStop Reporting Excel Add-In does not load, the OneStop Reporting Tab does not appear in the Excel Ribbon. When you go to Options > Add-ins in Excel the OneStop Reporting Add-In shows as inactive but it is checked as active. The installer is creating the registry keys and values in the wrong location.

Important: This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. The following is provided without warranty.

Copy the following text to notepad or another text editor. Save it as something like OneStop.reg. Right click on the saved file and select merge.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\Excel]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\Excel\Addins]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\Excel\Addins\OneStop.ReportDesigner]
"FriendlyName"="OneStop Reporting 3.7"
"LoadBehavior"=dword:00000003
"Description"="Excel-based reporting like you have never seen it before!"
"Manifest"="file://C:\\Program Files (x86)\\OneStop Reporting\\v3\\OneStop.ReportDesigner.vsto|vstolocal"

[-HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Wow6432Node]