2 Replies Latest reply on Jan 13, 2017 9:05 AM by dsears

    Interactive Services Detection

    MatthewPlumb Rookie

      I'm developing a Powershell script for Java deployment via LDMS. I'm almost there but want to display a popup dialogue at the very end that forces the user to "click ok" to restart the machine.


      The script works (as the local System Account) but when I try to deploy it with LDMS I get the dreaded Interactive Services Detection message shown below:



      If I click on 'View the message' I see my popup and can click OK and the machine will restart.


      However, I don't want to have the ISD message as it will just confuse people. I have tried stopping and disabling the UI0Detect service but then I see nothing, no popup message.


      Should stopping and disabling this service still display my popup message (without the ISD warning) or is this working as designed?


      What's the recommended method of display interactive messages in Powershell apps being deployed by LDMS as the local System Account?





        • 1. Re: Interactive Services Detection
          phoffmann SupportEmployee

          Chances are your problem is user context - namely "Local System" or "whatever admin you're running as".


          So Microsoft is "trying to be helpful" here, and this is mainly a security feature, but that can (/will) confuse end-users.


          I'd use the option to launch your "display message package" specifically as "the logged on user" - that *SHOULD* help you out ... and then launch (seperately / as an additional package in a bundle) your "actual install".


          The message script could just hang around until a "I'm done" type token exists (simple file check, for example) and close that way after your install is done.


          Hope that helps.

          • 2. Re: Interactive Services Detection

            You have to disable the "Interactive Services Detection" service to not see that message.


            I would reccommend you convert the package into a bundle and use a custom windows action for the prompt and here's how/why...


            The install script will need to run as an account that has permission to install (system) but you can't prompt using the same account. This is where the custom action comes into play.


            Create 2 packages:

            first package will install Java. This will run as local system or a specified admin.

            second package will be a custom windows action package that has your prompt script in it. This will run as logged in user.


            When configuring the bundle, set the second package to continue on failure (if no one is logged in that causes "run as logged in user"  packages to fail).



            When deploying, schedule the bundle. I would name the packages something that would prompt your admins to know to use the bundle. We usually put the word "dependent" at the beginning so it looks like "dependent - package name" so that people know it's a dependent and should not be pushed on it's own.