I have been getting this error for a while on my Server 2012 R2 DHCP cluster. Every time it syncs or replicates hundreds of errors are generated.
Some information around the web indicates I needed KB 2919393, KB 2919355 and KB 2955135 installed. KB 2955135 was not my scenario here, however it was installed. All other KBs are already installed.
Some information told me to replicate the scopes, using the powershell command:
However, this did not resolve the issue and is the same command used by the DHCP management tool.
A deconfigure of the failover and reconfigure of the failover did not solve the issue. However I knew based on previous searches that I was still out of sync with the scope.
Finally was resolved after a deconfigure of the failover, restarting the dhcp server that no longer had the failover, then reconfigured the failover. This cleared up the issues and the errors are not longer occurring.
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.
This one has been bugging me for a while. I had a CIFS based ISO share. For some reason the share would fail to update now and then with the error message “The specified storage repository scan failed”. A restart of the CIFS system would fix it, but none the less it wasn’t a solution. Other google results mostly pointed to NAS/SAN issues and not a CIFS share issue. I thought that the windows system was to blame because of the connections limit it has on non server editions.
While I was manually browsing the CIFS share I noticed something. There was a file on the share with a file name being a UUID. The file contained nothing and I checked and sure enough I was getting this error at the time. So I copied it somewhere else and deleted it. A rescan worked without any errors. No more errors and new files show up right away when added to the ISO share.