[W2K] .NET applicatie mag niet bij environment komen

Pagina: 1
Acties:

  • Koffie
  • Registratie: Augustus 2000
  • Laatst online: 18:34

Koffie

Koffiebierbrouwer

Braaimeneer

Topicstarter
Ik zit met de handen in het haar ...

Ik heb een applicatie welke in .NET 2.x geschreven is.
De applicatie draait op een Windows 2000 Server, maar ook met Windows 2003 heb ik dit probleem.
De applicatie moet ergens een lokale environment variabele opvragen (specifiek : CLIENTNAME).
De applicatie krijgt dit niet voor elkaar, waardoor hij ergens in de applicatie (ik ken/heb de code niet) hij terugvalt op de server naam.

Op mijn verzoek heeft de ontwikkelaar een klein appje gemaakt welke niets meer doet dan deze environment variaele opvragen, en in een form displayen.
Dit maakte duidelijk wat er mis ging : .NET weigerde toegang tot deze variabele.
Dit alleen al is vreemd, want dit heeft in eerdere versie's van de applicatie wel gewerkt.

Bij toeval kwamen we erachter dat .NET het wel toestaat wanneer dit simpele form appje vanaf een lokale schijf gedraait word (ik testte het vanaf de home disk van de user).
Na wat testen met caspol, werkte het ook vanaf een share.
We hebben nu de volgende feiten:

- Het simpele form appje werkt prima vanaf de lokale schijf - ongeacht of de user local/domain admin is of niet
- Met caspol kunnen de het appje rechten geven om ook te mogen draaien vanaf een netwerk share
- Het bewuste programma zelf draait uberhaupt al vanaf een local disk
- Zowel bij een local/domain admin lukt het niet om het bewuste pakket de environment variabele op te vragen

Het commando wat we gebruiken om het appje vanaf een share toe te staan, hebben we ook uitgevoerd met als path de program dir van de applicatie zelf. Dit gaf geen verschil.

Ik weet zeker dat het in .NET zit, en niet in andere security / GPO settings : andere talen krijgen wel toegang tot de environment variabele

Ik weet dat dit als een behoorlijk onsamenhangende post overkomt, en ook maar richting programming gaat.
Ik post het hier, omdat ik als beheerder het probleem moet oplossen - ook al heb ik een behoorlijk nauwe samenwerking met de leverancier/ontwikkelaar om op diep niveau dit te troubleshooten.

Elk idee is welkom (zolang het maar niet 'format server' is, we hebben het over 35+ servers die dit probleem hebben) ;)

Tijd voor een nieuwe sig..


  • Question Mark
  • Registratie: Mei 2003
  • Laatst online: 15:48

Question Mark

Moderator SSC/WOS

F7 - Nee - Ja

Je zou eens kunnen proberen om de variable met "setx" te maken, ipv standaard "set". (evt. een machine-variable met de optie -m).

[/gok]

Ik heb ooit eens een loginscript moeten schrijven wat ook gebruik maakte van een extra tool. Variablen gemaakt met set konden niet gebruikt worden, werden ze gezet met setx dan werkte het wel...

MCSE NT4/2K/2K3, MCTS, MCITP, CCA, CCEA, CCEE, CCIA, CCNA, CCDA, CCNP, CCDP, VCP, CEH + zwemdiploma A & B


  • Koffie
  • Registratie: Augustus 2000
  • Laatst online: 18:34

Koffie

Koffiebierbrouwer

Braaimeneer

Topicstarter
De variabele 'clientname' is een defualt aanwezig zijnde variabele - niet eentje die ik of een script eerder aangemaakt heb.

Tijd voor een nieuwe sig..


  • alt-92
  • Registratie: Maart 2000
  • Niet online

alt-92

ye olde farte

Ik kwam deze link nog tegen:
http://www.tomshardware.c...010-46-clientname-console
In two weeks all the code
that depended on the CLIENTNAME system variable will be replaced with
code that uses GetSystemMetrics(SM_REMOTESESSION) as proposed by the
people at http://dev.remotenetworktechnology.com. I have tested the
API call on numerous machines. The results appears to be accurate.

[ Voor 64% gewijzigd door alt-92 op 29-02-2008 14:44 ]

ik heb een 864 GB floppydrive! - certified prutser - the social skills of a thermonuclear device