Skip to Content

Well, first off: let me put the blame squarely on the developers of the .NET framework for making it next to impossible to start an administrative tool over an intranet path. There should be a limit to paranoia when it comes to not trusting applications – a limit crossed when apps started explicitly by a human user with administrative privileges are not allowed to execute, in the name of security! Fortunately, there are solutions and workarounds, and typically NWSAPSetupAdmin.exe will recommend one to you. If it doesn’t, here are a couple of things that help almost everyone.

(These steps are also documented in Note # 1169612.)

 

Step 1: Reduce IE-based restrictions on Zone ‘Intranet’ to Low

  • Switch to Tab “Security”
  • Select Zone “Local Intranet”
  • Click button “Custom Level”
  • Reset custom settings to “Low”.
  • Click button “Reset”. You will be prompted, click “Yes”.
  • Click “OK” to close both windows.

The steps above are reflected in this screenshot .

 

Step II: Make .NET trust your network path</p><p>Execute command-line:<br />”%windir%\Microsoft.NET\Framework\v2.0.50727\caspol.exe” -m -ag 1.2 -url file:”<network path>\setup\*” FullTrust</p><p><network path> here is the network share path to the root of the installation server.</p><p>You will be prompted by CASPOL, type “Yes” (without quotes) and press enter.</p><p>Now start NWSAPSetupAdmin.exe from the network path.<br />Proceed to Step III only if this step fails without a guiding message.</p><p> </p><p>Step III: Switch OFF .NET Security temporarily

You need to do this only if Step II was unsuccessful.

Execute command-line:
“%windir%\Microsoft.NET\Framework\v2.0.50727\caspol.exe” -security off

Allow CASPOL to run in the background, and start NWSAPSetupAdmin.exe from the network path. When done with administering the installation server, return to the CASPOL window.

 

 

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Markus Doehr
    Thanx a lot for that! I was dealing with exactly that problem yesterday (and gave up) 🙂

    But a question: Why the heck are you using NetInstall and not a standard .MSI package to install your frontend software? This NetInstaller “thing” has been a major pain in the past already and now relies on .NET (+ service packs + language packs) but you are not using standard Microsoft packages…  It would be a lot easier to distribute software using group policies or other software distribution methods if not that kind of “proprietary” package things was there…

    Markus

    (0) 
    1. Siddhartha Rao Post author
      Hi Markus,

      Thank you for that prompt feedback! I am glad to know that this FAQ helped you.

      Regarding your point about NetInstall: We are not based on NetInstall, and haven’t been for many years now.

      Regarding your comment on MSI: let me first clarify that a MSI-based solution would not solve the problem addressed in this post i.e. MSI is not a solution to the problem of starting .NET applications on network paths. 🙂

      Regarding the other point you raised about using MSI: note that the SAP Installer is more than just an installation tool like MSI – it is an administration, packaging and deployment solution for all our customers. Unlike MSI, the SAP Installer does not need prerequisites either.

      There really are customers out there who:

      1. Don’t have Windows Installer on their desktops, and don’t want to keep upgrading it. (Read: that costs them time and money… )

      2. Find MSI based installations very slow.

      3. Find it very easy to administer, configure, customize, install, and diagnose SAP Installation Packages using the SAP Installer.

      The SAP Installer needs to be a solution that works for all customers. 🙂

      Having said all that: we do have a feature that allows customers to create a single-file installation package using our administration tool. Did you look it up?

      Here is the link:
      New feature: Self-installing packages…

      Thank you again for your prompt feedback.

      Best Regards,
      Siddhartha

      (0) 
      1. Markus Doehr
        I have to comment on those 🙂

        “3. Find it very easy to administer, configure, customize, install, and diagnose SAP Installation Packages using the SAP Installer.”

        Well… It may be “easy” at the first task – but it’s in fact not. We had some really lengthy calls about the installations saying “the source is incomplete” (228755/2008, 709550/2006) after having added some packages, the “solution” was to reboot the server (Windows!!) which was done accidentally due to a different reason. The original problem why this happened is still unknown.

        and: fiddling on command line with .NET components is.. well… – not intuitive – as an administrator – who is != .NET developer 🙂

        “Having said all that: we do have a feature that allows customers to create a single-file installation package using our administration tool. Did you look it up?”

        We have six SAPGUI installation servers distributed over the whole world with one master in Germany, it’s not possible to create a single installation package and somehow push that through the lines for each client. And due to the update frequency of some components (BI!) it can become really a major pain to keep the clients up-to-date, not to speak about dependencies of necessary Office patches (which can’t be evaluated in/during the SAPGUI installation – or can they?)

        Markus

        (0) 
        1. Siddhartha Rao Post author
          Hi Markus,

          >> It may be “easy” at the first task – but it’s in fact not. We had some really lengthy calls about the installations saying “the source is incomplete” <<

          Hey, an installation that tells you that the ‘source is incomplete’ is doing a great job! Would you’ve really been any happier if it indicated success instead of telling you that some files are missing on the source? 😉

          >> after having added some packages, the “solution” was to reboot the server (Windows!!) which was done accidentally due to a different reason. The original problem why this happened is still unknown.<<

          If rebooting solved the problem, it is usually because some files had to be copied / installed post reboot.

          Note that this again is not an issue that MSI would solve for you. All Windows Updates are MSI files, and all of them need a reboot. 😉

          >> and: fiddling on command line with .NET components is.. well… – not intuitive – as an administrator – who is != .NET developer 🙂

          You are right that the admin is not a .NET developer: hence, this FAQ to help the admin out. (Note that this is not a SAP related issue, an admin cannot start any .NET application over his local network.) Other than that, note that even this problem would not be solved by a MSI installation.

          A lot of problems you faced are connected to the Windows-way of doing things. These aren’t one that any installer can solve.

          Best Wishes,
          Siddhartha

          (0) 
          1. Markus Doehr
            If it´s intelligent enough to see, that the “source is incomplete” why isn´t it intelligent enough to tell “please reboot me” :))

            I agree with you – we have to deal with the Windows (installer) deficiencies 🙂

            Markus

            (0) 
            1. Siddhartha Rao Post author
              A workstation (installer) cannot look into the internals of the server. It simply does not have access to data (connected to reboot requirement) that is maintained in the server’s registry / program files.

              When an admin completes the patch / update, the administrative tool warns him of the need to reboot. Such requests are often overlooked. 🙂

              Having said that, I can take your feedback and see what we can do with the administrative tool – may be have it inform the admin of pending reboots on startup of the tool.

              Thank you for your comments.

              Sid!

              (0) 

Leave a Reply