Deze website maakt gebruik van Functionele en Analytische cookies voor website optimalisatie en statistieken.
De technische opslag of toegang is strikt noodzakelijk voor het legitieme doel het gebruik mogelijk te maken van een specifieke dienst waarom de abonnee of gebruiker uitdrukkelijk heeft gevraagd, of met als enig doel de uitvoering van de transmissie van een communicatie over een elektronisch communicatienetwerk.
De technische opslag of toegang is noodzakelijk voor het legitieme doel voorkeuren op te slaan die niet door de abonnee of gebruiker zijn aangevraagd.
De technische opslag of toegang die uitsluitend voor statistische doeleinden wordt gebruikt.
De technische opslag of toegang die uitsluitend wordt gebruikt voor anonieme statistische doeleinden. Zonder dagvaarding, vrijwillige naleving door uw Internet Service Provider, of aanvullende gegevens van een derde partij, kan informatie die alleen voor dit doel wordt opgeslagen of opgehaald gewoonlijk niet worden gebruikt om je te identificeren.
De technische opslag of toegang is nodig om gebruikersprofielen op te stellen voor het verzenden van reclame, of om de gebruiker op een website of over verschillende websites te volgen voor soortgelijke marketingdoeleinden.
2 comments
.NET 
2 comments
By all means let us see how to do this by configuring CAS Policies.
PJ
Ben (the VPC Guy) writes: "The reason this happens is that PowerShell is a .Net application – and as a .Net application it does not run with sufficient privilege to be able to talk to our COM interfaces. "
This is what triggered me into thinking: then why not configure PowerShell with enough privileges.
After a couple of tests I found out that PowerShell.exe is not a *real* .NET app so I can’t configure it using CAS Policies as far as I can see…
Erno