Personal Finance

Aida · Guest

I'm having this annoying problem with CRM, that once installed every other
web application on that server wont function properly.

This wether the web application existed on the IIS prior to CRM or if it was
installed afterwards in it's own virtual directory using windows installer
from VS.NET.

It seems that CRM (besides wanting to be root in IIS) does somthing to the
user configurations on the IIS or for the ASP.NET user. I can see that things
like sessions for example, doesn't work for any web application what so ever,
after CRM has been installed, and that's rather annoying nicely put.

Could somone please explain to me what CRM does when installed to cause this
problem and also how to fix it or even better, how to avoid it all together.

Best regards
Aida

PS. Our different servers are running: IIS 6.0 & IIS 5.1, Windows 2003
Server & Windows 2000 Server.

Ronald Lemmen · Guest

CRM has its own web.config file. The settings which are in there are
overruled by the web.config settings in your app. If there is nothing about
sessions in your web.config, then these are being disabled by the crm's
config file. (<sessionState mode="Off"/> is one of the lines in crm's
web.config file).

Hope this helps,

Ronald Lemmen
Avanade Netherlands

"Aida" wrote:

Matt Parks · Guest

The other setting to look out for is taht CRM disables viewstate which will
affect any ASP.Net controls that you use.

--

Matt Parks
MVP - Microsoft CRM

"Ronald Lemmen" <RonaldL@-REMOVETHIS-avanade.com> wrote in message
news:5EA1EB55-0D60-4904-AE2C-9B8BBC7059E7@microsoft.com...
CRM has its own web.config file. The settings which are in there are
overruled by the web.config settings in your app. If there is nothing about
sessions in your web.config, then these are being disabled by the crm's
config file. (<sessionState mode="Off"/> is one of the lines in crm's
web.config file).

Hope this helps,

Ronald Lemmen
Avanade Netherlands

"Aida" wrote:

Aida · Guest

Thank you both of you for your answers. However, I know about web.config
files and their precedens - I may not have been specific enough in my
question and I didn't really have much knowledge (about CRM) to be either.

This issue (I've now looked even more into it) is also about CRM (the site)
not allowing anonymous users to log on.
Allowing anonymous users (in IIS) is very often the default behaviour you'd
want for a webapplication and then you'd take care of authentication
yourself, so this is one point that CRM (as site root) messes your
application up.

I tried removing CRM, creating a new site for it while NOT making this the
default site of IIS, say http://localhost:8080/ for example.

Then deploy my webapplications to the default site. This alone didn't do the
job though, the webapplication needed to impersonate (in this case I used the
administrator) which isn't exactly what you want for your webapplications.

But this is only possible if CRM is NOT root of the default site on IIS.

So I guess I can now specify my question a bit...

Question:
-----------
If CRM is indeed the root of the default site on IIS and I'm not the
administrator of the site, as in, I can't just remove it and place it
somwhere else, then what am I to do?

As far as I remember, I've already tried to make a new site for the
webapplications and deploy them there, but that didn't do the job.
I don't remember wether I tried with impersonate too or not, but I'd like to
avoid impersonate regardless.

Thanks for your time...

Best regards
Aida

"Matt Parks" wrote:

Matt Parks · Guest

These should be CRM users anyway, so they already do the integrated login
w/o any problem, so why do you want anonymous login? In order to properly
(and securely) impersonate, you should run your code under the CRM Root
website and require integrated authentication. Then your API calls can use
defaultCredentials w/o any issue.

Standard security will prevent the crednetials from passing between servers
and will require explicit credentials to be provided.

--

Matt Parks
MVP - Microsoft CRM

"Aida" <Aida@discussions.microsoft.com> wrote in message
news:AF05E4D1-D3C0-4C13-9638-19C87C948CE5@microsoft.com...
Thank you both of you for your answers. However, I know about web.config
files and their precedens - I may not have been specific enough in my
question and I didn't really have much knowledge (about CRM) to be either.

This issue (I've now looked even more into it) is also about CRM (the site)
not allowing anonymous users to log on.
Allowing anonymous users (in IIS) is very often the default behaviour you'd
want for a webapplication and then you'd take care of authentication
yourself, so this is one point that CRM (as site root) messes your
application up.

I tried removing CRM, creating a new site for it while NOT making this the
default site of IIS, say http://localhost:8080/ for example.

Then deploy my webapplications to the default site. This alone didn't do the
job though, the webapplication needed to impersonate (in this case I used
the
administrator) which isn't exactly what you want for your webapplications.

But this is only possible if CRM is NOT root of the default site on IIS.

So I guess I can now specify my question a bit...

Question:
-----------
If CRM is indeed the root of the default site on IIS and I'm not the
administrator of the site, as in, I can't just remove it and place it
somwhere else, then what am I to do?

As far as I remember, I've already tried to make a new site for the
webapplications and deploy them there, but that didn't do the job.
I don't remember wether I tried with impersonate too or not, but I'd like to
avoid impersonate regardless.

Thanks for your time...

Best regards
Aida

"Matt Parks" wrote:

Aida · Guest

Users of my webapplications aren't nessesarily users of the CRM. The
webapplication I'm working on, that made me aware of this problem, is a
webinterface for another application (a windows service) which is the one
working with CRM, not the user of the webapplication.

That's why the scenario of me attempting to install my webapplication on a
customer's IIS which already has CRM installed (most likely as root in IIS)
would be rather common.
In this case the one needing access to the webapplication doesn't have to
have a reason also to be a CRM user, unless he actually has a reason to use
CRM, as in, he uses CRM himself on a daily basis or what not.
However, if he is an administrator of some sort, he most likely have no
reason or desire to use CRM hance has no CRM user account.

Besides all this, I'm not interested in using impersonate in my
webapplication if I can help it.

If the CRM application doesn't run with impersonate itself (I don't know if
it is or if it's autherization of resourses is done elsewhere) then which
user account is it using?

"Matt Parks" wrote:

Matt Parks · Guest

At some level, what you describe appears to violate the EULA for the app.
If a user is interacting with the API calls, they are supposed to be a valid
CRM user and have a license. That aside...

In your case, it sounds like the identity that the window service is running
under is the one being used to invoke the call. If that's the case, then
this user should have a license in CRM. You can verfiy which user identity
is getting sent into your app by umping the server AUTH_USER variable.

--

Matt Parks
MVP - Microsoft CRM

"Aida" <Aida@discussions.microsoft.com> wrote in message
news:38B5571D-DEBF-4647-8DE0-F5EE3E9C41A9@microsoft.com...
Users of my webapplications aren't nessesarily users of the CRM. The
webapplication I'm working on, that made me aware of this problem, is a
webinterface for another application (a windows service) which is the one
working with CRM, not the user of the webapplication.

That's why the scenario of me attempting to install my webapplication on a
customer's IIS which already has CRM installed (most likely as root in IIS)
would be rather common.
In this case the one needing access to the webapplication doesn't have to
have a reason also to be a CRM user, unless he actually has a reason to use
CRM, as in, he uses CRM himself on a daily basis or what not.
However, if he is an administrator of some sort, he most likely have no
reason or desire to use CRM hance has no CRM user account.

Besides all this, I'm not interested in using impersonate in my
webapplication if I can help it.

If the CRM application doesn't run with impersonate itself (I don't know if
it is or if it's autherization of resourses is done elsewhere) then which
user account is it using?

"Matt Parks" wrote:

Aida · Guest

It is indeed the windows service communicating with CRM and obviously through
the means described in the SDK for CRM, aka it authenticates itself through a
CRM user account hence no EULA violations as far as I know.

The webapplication doesn't interact with CRM, it doesn't have anything to do
with CRM what so ever, it only communicates with a database.
So the problem it not how to talk to CRM through a webapplication or
anything like that, it's only about being able to make an installer project
for the webapplication that I know will actually work when deployed
regardless or the location (on IIS) of CRM - The only reason I mention CRM in
this context is because it's CRM messing things up for the webapplication
when deployed if the CRM is indeed the default website on the IIS.

So, to sum up - all I want is to be able to make a deployment project for
the webapplication, so I know that the webapplication will work once deployed
regardless of where on IIS CRM is installed.

"Matt Parks" wrote:

	Personal Finance Forum Index -> CRM	All times are GMT
Page 1 of 1