This is AndrewJ's Typepad Profile.
Join Typepad and start following AndrewJ's activity
Join Now!
Already a member? Sign In
Recent Activity
Also one thing I'm confused by if this is truly a supported configuration by MSFT: as soon as you disable the async service on one of the two web servers, it disables that same server in the deployment manager. What does "disabled" mean in the context of the deployment manager?
We tried this again this morning but still no luck. Our CRM 4.0 environment is still using 3.0 callouts. We noticed that on the new prod box APPSERVER2 that CRM was not picking up the server\bin\assembly DLLs and registering them. The Plugin Registration tool showed no callouts at all. This thread over at Microsoft describes the exact same problem we're seeing.
The URL that the plugins are calling is cobbled together from values in the web.config file. We store the OrgName and various server URLs separately so that we can update them when pushing from our dev environment to production; this has worked well for several years. I just tested again now for the third time just to make sure I wasn't going nuts and this is *definitely* a plugin issue. As soon as I remove the APPSERVER2 entry in the deployment manager and restart IIS on APPSERVER1, things spring right back to normal. I can see the URLs that the plugins are calling and they are accessible via the browser but if CRM calls them (via button press, for example) I get a litany of "Object not set" errors. I should add that APPSERVER1 uses the Network Service account and has all default IIS settings but APPSERVER2 uses a domain account. I can get it to load CRM from the web app so I don't think there are any Kerberos issues. This is about the plugins and something fishy is going on for sure.
I don't understand how this approach works. I have an existing deployment that runs the web app and async service on one server, call it APPSERVER1, and the DB server is separate, call it SQLBOX. I then create a new machine called APPSERVER2 and install CRM on it and point it to the existing DB install. The CRM Deployment Manager creates two entries in the "Servers" list, one for APPSERVER1 and one for APPSERVER2. I disable async service on APPSERVER2. However CRM is now unstable: my callouts don't work properly. The only way for me to regain stability is to delete APPSERVER2 from the deployment. I tested this twice and on both occasions things *immediately* stopped working as soon as APPSERVER2 showed up in the deployment list. Any thoughts?
AndrewJ is now following The Typepad Team
May 29, 2011