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.
I needed to figure out a simple way to set the default background image. I didn’t want to force the background image, I didn’t want to apply a GPO, and I wasn’t having much luck editing the default user hive. I happen to stumble onto this solution by chance, really. So into regedit we go for this.
The location I am looking for is:
You may need to add keys, but in general you want the below keys to be set. I set DesktopBackground, but excluded it in this example because it contained a path I didn’t want to post. This is just a hex string that contains the full path to a file using the oobe folder is recommended. The oobe folder may not exist on your system, so go ahead and create it if needed.
Using this plus other OOBE branding, I was able to make a bat file which upon running completely sets up branding on the System Information panel, theme and default background.
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.
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.