By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,694 Members | 1,307 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,694 IT Pros & Developers. It's quick & easy.

processModel userName="MyDomain\UserName"

P: n/a
Greetings,

I apologize for the cross post I posted previously to .Net Framework with no
replies...
I have an application server that potentially will service all enterprise
applications from the context of business components.. The components that
will run on this machine in some circumstances could be very far reaching
and require much more access than just the local system account could
provide. I am considering creating a application services account in the
domain and having the .Net framework run in the context of that account on
machines that need to participate in enterprise application operations.
Could someone point me in the right direction or provide some feedback as to
why this would or would not be a good idea...? Or possibly suggest another
solution.. I'll also add that I've been through Microsofts best practices
white papers and don't recall reading anything in there about such a
requirement...

Thanks,

Dan B
Nov 20 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Hi Dan,

In the context of the domain of your question I am having to be very
enterprising, on account of the abstract circumstance of the components of
your query, in understanding how I can participate in the servicing of same.

Do you think you could rephrase the question with fewer marketing terms?
;-)

Regards,
Fergus
MVP [Windows Start button, Shutdown dialogue]

Nov 20 '05 #2

P: n/a
Cor
Hi Alien,

When I did understand you right, than I think this isn't a good idea.

You are not the first one who has these thoughts, but it will take a lot of
effort and a lot of sleepless nights to manage it.

You have to keep track of all the computers that are used for your central
processing. A simple power break on a client computer can mean a total
disaster on an essential process.

This is the total opposite from the mainframe thinking and I like this, but
it is from the time that the server hardware was very expensive. Today the
software and keeping things up is mostly much more expensive than a piece of
hardware (when you are situated in a western country and after sometime I
hope everywhere).

The new operating systems are made for clustering servers and load balancing
the processing.
Maybe that did give you the idea; "why not make from my client computers
servers". Maybe it is technical possible, but my thought about it did you
read above.

I would go in your situation to the clustering model of servers. That is
manageable and extensible; to be dependable of client computers, who can be
plugged of just for fun, will give you probably very much nights of bad
sleeping.

Just some thoughts,

Cor

Nov 20 '05 #3

P: n/a
We have had to use a domain\username in the processModel element because, in
a domain, the machine account (ASPNET) doesn't like to work. We still use
this account name (ourdomain\ASPNET) but have further restricted it
massively. Don't let it have anything more than it needs (i.e., taking the
defaults).

If you're dealing with enterprise applications and want to run something in
the logged-in user contect (via Kerberos (.NET 1.1) or NTLM (1.0+), then set
the <identity impersonate="true"/> and the context will impersonate the
user, giving you further control on resources.

I'm not sure this answers your question, but I hope it leads you in the
right direction.

--
Heath Stewart
Senior Software Architect
Proplanner.NET: Web-based Production Planning Solutions
http://www.proplanner.net
Nov 20 '05 #4

P: n/a
We have had to use a domain\username in the processModel element because, in
a domain, the machine account (ASPNET) doesn't like to work. We still use
this account name (ourdomain\ASPNET) but have further restricted it
massively. Don't let it have anything more than it needs (i.e., taking the
defaults).

If you're dealing with enterprise applications and want to run something in
the logged-in user contect (via Kerberos (.NET 1.1) or NTLM (1.0+), then set
the <identity impersonate="true"/> and the context will impersonate the
user, giving you further control on resources.

I'm not sure this answers your question, but I hope it leads you in the
right direction.

--
Heath Stewart
Senior Software Architect
Proplanner.NET: Web-based Production Planning Solutions
http://www.proplanner.net
Nov 20 '05 #5

P: n/a
It does help.. thank you!!

"Heath Stewart" <no*************@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
We have had to use a domain\username in the processModel element because, in a domain, the machine account (ASPNET) doesn't like to work. We still use
this account name (ourdomain\ASPNET) but have further restricted it
massively. Don't let it have anything more than it needs (i.e., taking the
defaults).

If you're dealing with enterprise applications and want to run something in the logged-in user contect (via Kerberos (.NET 1.1) or NTLM (1.0+), then set the <identity impersonate="true"/> and the context will impersonate the
user, giving you further control on resources.

I'm not sure this answers your question, but I hope it leads you in the
right direction.

--
Heath Stewart
Senior Software Architect
Proplanner.NET: Web-based Production Planning Solutions
http://www.proplanner.net

Nov 20 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.