I stumbled across a weird issue with Dynamics CRM 2011. I thought it was due to Rollup 12 as it only recently started happening, but it appears to be default behavior (whether I noticed it before or not). Basically the steps to reproduce this are very simple.
- Create a case with some basics
- Add some notes
- Add the case to the queue
- Access the queue
- Click Assign in ribbon
- Assign case to yourself.
- Save and close.
After a short while the case notes that once where owned by User A, now are owned by User B. Thats not what I expect to happen. I expect the notes to stay the same.
Well it appears there is a simple work around to this. Although not what I wanted to change, this does get around it.
- Go to Settings -> Customizations -> Customize this system
- Navigate to Entities -> Cases -> 1:N Relationships
- Open Notes
- Change Relationship from Parent to Cascading.
- Change the Assign from All to None
- Save and close
- Publish all Customizations (may not be needed but just to be sure)
One of my co-workers who use Safari way more than I do pointed out today that he couldn’t click links in Safari on his Macbook Pro running Mountain Lion. I was able to reproduce this as well in my Safari. Starting my debugging I noticed if I opened the developer console the links worked, which didn’t help me much. I made sure popups where disabled and no luck as well. Finally thinking maybe I had an extension in Safari causing it, I tried disabling all extensions. Again nothing was working to resolve the issue.
By chance I happen to stumble on a workaround at least. In the progress of debugging this, I changed my user agent, the page refreshed and it worked. I realized something, after opening the debug console it refreshed the page as well. So closing Safari and opening it again, I again came upon the page and couldn’t open any links in CRM. I hit F5 and let the page refresh. Once the refresh completed all the links worked. Not sure why, but a refresh seems to resolve this.
Note: My co-worker couldn’t use F5 in his Safari. I believe I remapped it at one point in Safari as its F5 in all other browsers and just like it that way. I believe the default is Apple + R.
Doing more testing with CRM 2011 Rollup 12, I found out that Chrome was self closing when I logged into CRM. This is very annoying, but having worked with CRM before in IE, I knew what this was. By chance I was able to verify it by going to the CRM url and changing the last part of the url to /main.aspx. I got a notification that a popup was blocked. Sure enough, after I added the crm address to the popup blocker exception list, no more self closing windows.
Update 2/14/13: Also should note that this affects Safari as well. Popupblocker’s cause quite a problem with CRM and there is no notification what it is about to do. I find the fact that CRM needs to launch into its own window a pain. I personally have it in a pinned tab in Chrome. I don’t worry about it and when I need CRM its there and not on some other obscure window.
While testing out CRM 2011 Rollup 12, I noticed that I could not get it to log me in for Chrome. After checking my security log and resetting Chrome back to defaults, it still didn’t shed any light onto why this was happening.
After much searching, I happen to find the article explaining this. http://support.microsoft.com/kb/2709891/en-us?sd=rss&spid=15707
While this requires a registry edit and supposedly opens up a man in the middle attack, it does indeed fix it. Hopefully a proper fix comes out in the near future to resolve this properly. In the mean time this works well.
So I needed to add a search box to a Microsoft Dynamics CRM Customer Portal. So into Visual Web Developer 2010 Express I went. I opened the Customer Portal project and then expanded Pages and eService in the tree.
Opening up ViewCases.aspx I located the following
I added this before that:
<asp:Label ID="Label2" Font-Bold="true" runat="server"> Search: </asp:Label>
<asp:TextBox ID="CaseSearch" AutoPostBack="true" runat="server"></asp:TextBox>
I then opened the code for the file (right clicked and showed code) and located the following:
if (casesByCustomer.Count() == 0)
and added before that:
casesByCustomer = casesByStatus.Where(c => c.Title.ToLower().Contains(CaseSearch.Text.ToLower().ToString()));
Saved the files, built the code and tested. Everything worked just fine, except for an error that occurred because the view I had, used follow up by and some of those cases didn’t have them. If a search returned only results with no follow up by set, it would give an error. But I just swapped out the follow up by for modified on.
I had a issue today where a machine was getting a 404 error while logging into CRM over IFD. Using the internal crm login url worked just fine. Since this was only affecting this one machine, I didn’t suspect any issue with the IFD setup. Not that I didn’t check the CRM server to verify if the login was actually successful or not (it was) and to make sure the ADFS Relaying party was updated.
What this issue finally came down to was that the organization url (hxxps://org.crmhost.com) was added as a trusted site. It seems that caused some issues with the ADFS/IFD login page. Removing that from trusted sites made it work as expected.
The important piece here is that multiple urls are used during the login process and other aspects. dev, auth, and sts are other default subdomains used during the IFD setup process. Adding these to trusted sites will allow this to work properly. In addition and easier to setup, using a wildcard (hxxps://*.crmhost.com), is much easier to add to trusted sites.
Finally, if you have a trust setup between the crm host domain and your domain and you can use the internal crm url (hxxp://internalcrm.crmhost.com). Using that you would add the internal crm url (hxxp://internalcrm.crmhost.com) to the internal sites. This allows your domain credentials to be passed directly to the server without the need for a login prompt. Just remember to setup your security policies to prevent logins to machines and other security risks.