Interesting. I'll think about it. I don't have much in the way of logs (all the logs for enabling claims were clean), but I do have the moneyshot screengrab. Thanks.
On Mon, Jun 2, 2014 at 12:54 PM, Tim Evans <[email protected]> wrote: > He would probably be just as happy if you wrote him and told him about > how use used Process Monitor and the problem you solved with it. He does a > presentation at TechEd every year called "The Case of the Unexplained…" > where he talks about interesting cases he has found or people have sent > him. He always ends them with "If you’ve solved one, send me a description, > screenshots and log files". > > > > …Tim > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Richard Stovall > *Sent:* Monday, June 02, 2014 9:40 AM > > *To:* [email protected] > *Subject:* Re: [NTSysADM] CRM 2011 SSL cert error - Completely down > > > > Aboslutely. I'll probably never meet Mr. Russinovich in person. If > someone would buy him an adult malt beverage of his choice and send me the > bill, that would be much appreciated. > > > > On Mon, Jun 2, 2014 at 11:16 AM, <[email protected]> wrote: > > Process Monitor rules. > > You should blog it up, looks like another interesting event where > SysInternals saves the day :-) > > Despatched via Blackberry. Mock if you will, but it gets my email without > a fuss. > ------------------------------ > > *From: *Richard Stovall <[email protected]> > > *Sender: *[email protected] > > *Date: *Mon, 2 Jun 2014 11:04:44 -0400 > > *To: *<[email protected]> > > *ReplyTo: *[email protected] > > *Subject: *Re: [NTSysADM] CRM 2011 SSL cert error - Completely down > > > > This was the third time I've installed a wildcard cert on this server in > its 2.5 year life. Never had a problem before. This time, obviously, > there were problems. The AppPool's account could not read new cert's > private key. All of the research I did said to manually add a read ACE on > the private key's ACL in the certificates mmc snapin. I did that with no > effect. Some others people reported success by subsequently adding a > similar ACE to the key's ACL in the machinekeys folder. That did not help > either. I worked on it for several hours yesterday before calling PSS. > When they did call me back, two gentlemen worked on it for about 7 hours > and got nowhere. > > > > While they were working on it, one of the techs added a read ACE for the > AppPool's account to the machinekeys folder's ACL so that the permission > would propagate down, but that did not help. Soon thereafter the CRM guys > decided that it was definitely a Windows issue and punted to another team. > This morning, while waiting for the second team to call, I fired up > procmon to see what the heck was really going on. It turned out that the > w3wp process was trying to access a key in the machinekeys folder that did > not exist anywhere on the drive. Seriously. Phantom stuff. I e-mailed a > screenshot to the CRM PSS techs and they suggested deleting the cert and > re-importing it. I did and presto! Back in business. > > > > It turns out that the ACE on the machinekeys folder's ACL has to exist > BEFORE you import the certificate or the whole thing is mangled, and > mysterious calls to non-existent keys are created. Why this was not an > issue the prior two times I installed previous iterations of the same > certificate on the same server is unclear, nor is it evident why the > (undocumented) procedure has to be in the correct (undocumented) order. > > > > I hope none of you ever have to deal with this, but if you do, the fix is > really simple. (If you know the secret handshake.) > > > > > > > > On Mon, Jun 2, 2014 at 9:55 AM, Richard Stovall <[email protected]> wrote: > > Yup. Very. > > > > It is finally resolved. I'll write a post-mortem in a bit. > > > > On Mon, Jun 2, 2014 at 8:18 AM, Michael B. Smith <[email protected]> > wrote: > > That's....odd. > > Sent from my Windows Phone > ------------------------------ > > *From: *Richard Stovall <[email protected]> > *Sent: *6/2/2014 6:42 AM > *To: *[email protected] > *Subject: *Re: [NTSysADM] CRM 2011 SSL cert error - Completely down > > Still no resolution. The CRM people are handing it to the Windows team > because they believe it is an issue with the IIS AppPool not being able to > read the private key. (Which is what it looked like all along.) None of > the known fixes are working, however. Ugh. > > > > On Sun, Jun 1, 2014 at 10:09 PM, Richard Stovall <[email protected]> > wrote: > > Yep. I have done this before without trouble, but this time it's not > working. > > > > I did get a call from PSS (apparently there's one CRM engineer on duty on > weekends) about an hour ago and he's (very politely) scratching his head > and having me repeat all the troubleshooting steps I've already gone > through. Thanks for checking. If we ever get this resolved, I'll post the > fix. > > > > On Sun, Jun 1, 2014 at 9:50 PM, Susan Bradley <[email protected]> > wrote: > > Have you reran then claims config wizard and ifd config wizard after > replacing the SSL cert ? > > (passed this onto a crm listserve) > > > > On 6/1/2014 11:01 AM, Richard Stovall wrote: > > Any one out there using CRM 2011 on premise? I have been for years and > went to replace an expiring SSL cert today and now cannot successfully > enable claims or IFD. Getting the dreaded "keyset does not exist" error. > I have granted the network service account access to the private key, > which is usually the answer, but this does not work in this case. > > I'm completely stumped and PSS is apparently not available to work on CRM > issues on weekends. > > > > > > > > > > > > >
