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)
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..