none
2 Erkennungsmethoden für eine Anwendung

    Question

  • Hallo,

    ich möchte eine Anwendung zur Verfügung stellen. Diese soll für Windows 10 und Windows 7 bereitgestellt werden.

    Da ich es übersichtlich gestalten möchte wollte ich gerne  1 Anwendung für beide Betriebssysteme bereitstellen.

    Da ich aber die Erkennungsmethode auf den Programmpfad verweisen möchte, wäre der Pfad pro Betriebssystem unterschiedlich.

    z.B. - VLC - Player

    W10 - "C:\Program Files (x86)\VideoLAN\VLC\vlc.exe"

    W7 -  "C:\Program Files\VideoLAN\VLC\vlc.exe"

    Also benötige ich 2 Erkennungsmethoden. Das wird doch aber nicht funktionieren,da eine Methode ja immer negativ ist oder bin ich auf dem Holzweg?

    Hat jemand einen Tipp ob ich mein vorhaben so umsetzten kann?

    Sicherlich kann ich 2 unterschiedliche Anwendungen verteilen aber das würde ich gerne umgehen.

    Danke für eure Hilfe!


    Toni

    Tuesday, January 8, 2019 8:06 AM

Answers

  • Eine Application mit zwei Deployment Types (einen für W7, einen für W10) und pro Deployment Type dann halt ein Requirement für das entsprechende Betriebssystem.

    Torsten Meringer | http://www.mssccmfaq.de

    • Marked as answer by tonibert Friday, January 18, 2019 10:57 AM
    Tuesday, January 8, 2019 10:45 AM
    Answerer

All replies

  • Eine Application mit zwei Deployment Types (einen für W7, einen für W10) und pro Deployment Type dann halt ein Requirement für das entsprechende Betriebssystem.

    Torsten Meringer | http://www.mssccmfaq.de

    • Marked as answer by tonibert Friday, January 18, 2019 10:57 AM
    Tuesday, January 8, 2019 10:45 AM
    Answerer
  • Wozu soll das gut sein?

    Die 2 Pfade, die du da anführst, unterscheiden nach Bit-Klasse.
    Eine 32-Bit-Anwendung wird im C:\Program Files (x86)-Verzeichnis installiert, eine 64-Bit-Anwendung im C:\Program Files-Verzeichnis.

    Windows 7 und Windows 10 gibt es beide in der 32- und 64-Bit-Version.

    Da dies unterschiedliche Technologien sind, musst du deine Anwendung mal als 32-Bit oder als 64-Bit kompilieren.
    Ebenso benötigst du dann auch 2 verschiedene Installer.

    Entwickelst du mittels .Net, kannst du als CPU-Typ ANY angeben, dann wird autoamatisch deine Anwendung in der verfügbaren Bit-Architektur ausgeführt.

    Wenn dein Programm mit max. 1,4GB Hauptspeicher auskommt, kannst du auch generell in 32Bit verteilen.
    Der Programmpfad ist i.Ü. nur ein Vorschlag bei der Installation. In den meisten Installern kann man den Zielpfad der Anwendung nämlich sowieso ändern.

    Tuesday, January 8, 2019 12:00 PM
  • Da dies unterschiedliche Technologien sind, musst du deine Anwendung mal als 32-Bit oder als 64-Bit kompilieren.


    VLC gibt es bereits fertig zum Download. Da muss nichts kompiliert werden.
    Die Frage wäre, welche Version (x86 / x64) auf welchem OS (7/10) in welcher Ausprägung installiert werden soll.

    Torsten Meringer | http://www.mssccmfaq.de

    Tuesday, January 8, 2019 2:10 PM
    Answerer
  • VLC wurde ja nur als Beispiel genannt.

    Fertige Anwendungen haben i.d.R. auch bereits ihre eigenen Installer.

    Tuesday, January 8, 2019 3:25 PM
  • Hallo und danke für die Antworten!

    Ja, VLC war ein Beispiel!Aber nicht unbedingt aus der Luft gegriffen, da ich die z.B. die 32 Bit Version nutzen würde aber das ist Nebensache.

    Ich würde eher die Antwort mit Requirement aufgreifen.

    Kannst du mir vielleicht, wenn es dir nicht zu große Mühe macht, dafür ein Beispiel geben?

    Natürlich werde ich es morgen trotzdem ausprobieren.Es würde mich aber wahrscheinlich schneller zum Ziel führen.

    Ich danke euch beiden für eure Beiträge und Hilfe.

    Schönen Abend!


    Toni

    Tuesday, January 8, 2019 7:22 PM
  • da ich die z.B. die 32 Bit Version nutzen würde aber das ist Nebensache.

    Moin,

    das ist nicht ganz Nebensache, denn das Problem entsteht ja NUR, wenn Du die 32-Bit-Version nutzen willst. Eine Version gleicher Bitness wie das OS wird immer unter %PROGRAMFILES% installiert und kann dort auch geprüft werden. Unter 32-Bit-OS gibt's halt kein %PROGRAMFILES(x86)%.

    Ich würde vermutlich die Detection einfach per PowerShell machen, so etwas wie

    if ([Environment]::Is64BitOperatingSystem) {
        $mypath = "$(${env:ProgramFiles(x86)})\MyAppFolder\MyApp.exe"
    } else {
        $mypath = "$($env:ProgramFiles)\MyAppFolder\MyApp.exe"
    }
    if (Test-Path $mypath -PathType Leaf) {
        $true
    }


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Tuesday, January 8, 2019 7:50 PM
  • Guten Morgen Evgenij,

    vielen Dank auch für deine Antwort!

    Nebensache war ein Wort welches ich nicht mehr nutze ;-)

    Es war auch nur bezogen auf die Anwendung jedoch nicht auf die Bitness :-) da das genau mein Thema ist.

    Wir (sollen) zum großen Teil 32 Bit verteilen und genau dann habe ich das Thema mit %ProgramFiles%.

    Eine kurze Info:

    Ich bin erst seit kurzer Zeit in dem tollen Zustand mit dem SCCM zu arbeiten. Daher verteile ich noch nicht so lange Software darüber. Es klappt aber und man lernt Step-by-Step.

    Und genau deshalb ist mir eben nicht ganz klar wenn ihr über Detection oder Deployment Types redet wo ich wie ich diese einstelle.Dazu kommt, dass wir den SCCM in deutscher Sprache nutzen und die Übersetzung manchmal nicht ganz logisch ist.

    Ich hätte sogar ein Script welches über PS das OS abfragt aber ich suche eben genau den Weg das zu Verknüpfen!


    Toni

    Wednesday, January 9, 2019 6:23 AM
  • Eine Software zu verteilen ist etwas anderes als sie zu installieren.
    In den meisten Fällen kann ich keine Software einfach so auf einen PC verschieben sondern ich verschiebe den Setup.exe, die Setup.msi o.ä. auf den Ziel-PC und starte dort die Installation.
    Dazu bieten die meisten Installer (msi sowieso) auch sog. Silent-Aufrufe.
    Diese regeln dann, was wohin installiert und eingestellt werden muss, dazu gehört auch das Programmverzeichnis.
    Es werden ja auch z.B. DLL's ins System32 (umgeleitet in SYSWOW64) oder direkt umgeleitet ins WinSxS installiert, Registry-Entries geschrieben, %APPDATA%, %LOCALAPPDATA% u.ä. Verzeichnisse Objekte verteilt.

    Einer 32-Bit-Anwendung, also auch einem 32-Bit-Installer werden einige Pfade zur Laufzeit verbogen.
    Z.b. das Verzeichnis %Windir%\System32 wird nach %windir\SYSWOW64 umgeleitet.
    Das selbe gilt für Registry und Programmverzeichnis.

    Dem Windows ist das eigentlich egal, ob du 32-Bit ins %Programfiles%-Verzeichnis kopierst, da zur Laufzeit an Hand der Exe die Bitness entschieden wird. Problematisch kann es nur sein, wenn du dann auf bestimmte Verzeichnisse keinen Zugriff hast, da sie ja umgeleitet werden.

    Ich würde die zu installierenden Programme in ein InstallDir schieben und von dort aus installieren lassen.

    Ach ja, wenn du ein PS-Script als 32-Bit auf dem Remotecomputer ausführst, verweisen die obigen Variablen automatisch nur auf die 32-Bit-Verzeichnisse, an die 64-Bit-Verzeichnisse kommst du dann sowieso nur über Umwege.
    • Edited by bfuerchau Wednesday, January 9, 2019 6:51 AM
    Wednesday, January 9, 2019 6:47 AM
  • Moin bfuerchau,

    danke für die Info.

    Ich deploye seid vielen Jahren Betriebssysteme und Anwendungen auf unterschiedlichster Arten und Weisen.

    Installer, selbstgeschriebene Scripte (bat, ps1 etc.) bisher aber über das MDT, GPO etc.

    Nun bin ich in einem anderen Bereich wo ich u.a. die deployte Software aus dem MDT über den SCCM pflegen soll und möchte.Deshalb ist das auch nicht zwingend mein Problem :-)

    Ich suche ja eigentlich Tipps und Erfahrungen zum Bereitstellen von Software für unterschiedliche OS'es.

    Ob nun über eine oder mehrere Bereitstellungen bzw. Anwendungen/Pakete.

    Deshalb interessiert mich der Teil Requirement von Torsten oder Detection von Evgenij schon sehr.

    Natürlich kann ich einfach 2 Anwendungen bauen und diese Bereitstellen.

    Aber ich wollte eben die erfahrenen Profis nach deren Meinung und Ideen fragen, da ja oft viele Wege nach Rom führen.

    Tschö 


    Toni

    Wednesday, January 9, 2019 7:32 AM
  • Natürlich kann ich einfach 2 Anwendungen bauen und diese Bereitstellen.

    Das macht keinen Sinn. Mache es einfach so, wie von mir ursprünglich erwähnt und dann passt das.

    Wenn Du wirklich 32 und 64bit VLC verteilen willst (um bei dem Bsp zu bleiben), dann 1 Anwendung mit 2 Bereitstellungstypen (Deployment Types/DT).

    - DT #1: VLC 3.0.5 x86. Mit dem Requirement (Anforderung): Alle Windows 7 x86.

    - DT #2: VLC 3.0.5 x64. Mit dem Requirement (Anforderung): Alle Windows 10 x64.

    Es wird auf einem Client immer nur 1 DT installiert. Der Client fängt "oben" (als bei dem DT mit Priorität 1) an und prüft ob die Requirements erfüllt sind. Auf einem Windows 10 x64 Rechner würde also DT 1 übersprungen, weil das Requirement nicht erfüllt ist. Dann geht's weiter zu DT 2. Dessen Requirement ist erfüllt und der DT wird installiert. (Wenn Du einen Windows 10 x86 Rechner hättest, dann würde nichts installiert werden, da kein Requirement erfüllt wäre).


    Torsten Meringer | http://www.mssccmfaq.de

    Wednesday, January 9, 2019 9:25 AM
    Answerer
  • Nur eine Verständnisfrage:

    Muss die Reihenfolge der DT's nicht genau anders herum sein?
    Da ja auf einem x64 eine x86-Installation ebenso möglich ist, würde ja die DT1 immer genommen.

    Man kann ja u.U. auch die Windowsversion außen vor lassen um nur die Bitarchitektur zu berücksichtigen.
    Die Windowsversion ist (in meinem Installer) nur die Minimalversion und nicht die absolute Version.
    Also ein Win7 X86 lässt sich ebenso auf Win8, Win8.1, Win10 und Server >= 2008 installieren, nur nicht mehr auf XP und Server<=2003.

    Wednesday, January 9, 2019 11:06 AM
  • Du musst den ganzen Text von Torsten lesen, auch den letzten Absatz ;-)

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Wednesday, January 9, 2019 11:12 AM
  • ...und noch zur Erkennung: Eine Applikation, die mit einem wohlgemanagten MSI-Paket installiert wird, würde ich versuchen, anhand der Installations-ID zu erkennen und erst wenn ich merke, dass die ID sich z.B. von Version zu Version ändert, auf Pfadprüfungen zurück fallen.

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Wednesday, January 9, 2019 11:15 AM
  • Wie bereits gesagt:

    Ein Requirement Windows7 x86 gilt als Minimalanforderung.
    Eine Installation auf einem Win10 x86 würde eine so definierte MSI trotzdem durchführen.

    Es heißt eben nicht: ausschließlich auf Win7 mit X86.
    Das würde ja bedeuten, dass ich für wirklich jede Windowsversion eine eigene Requirement definieren müsste.

    Wenn ich meine .Net-Application für 4.6.1 entwickle, wird sie auf einem Rechner, der bereits 4.6.2 oder 4.7 hat ja auch ausgeführt.
    Wednesday, January 9, 2019 11:28 AM
  • @Evgenij

    "...und noch zur Erkennung: Eine Applikation, die mit einem wohlgemanagten MSI-Paket installiert wird, würde ich versuchen, anhand der Installations-ID zu erkennen und erst wenn ich merke, dass die ID sich z.B. von Version zu Version ändert, auf Pfadprüfungen zurück fallen."

    Da bin ich ja völlig deiner Meinung Evgenij. Aber bei VLC handelt es sich eben um eine exe. Ansonsten habe ich das auch immer die msi mit samt Installations-ID genutzt.

    @Torsten: Vielen Dank!

    Ich teste und berichte

    Nachtrag:Natürlich auch vielen Dank

    @Evgenij

    @bfuerchau


    Toni



    • Edited by tonibert Wednesday, January 9, 2019 2:21 PM
    Wednesday, January 9, 2019 11:51 AM
  • #1

    Ein Requirement Windows7 x86 gilt als Minimalanforderung.
    Eine Installation auf einem Win10 x86 würde eine so definierte MSI trotzdem durchführen.

    #2
    Es heißt eben nicht: ausschließlich auf Win7 mit X86.
    Das würde ja bedeuten, dass ich für wirklich jede Windowsversion eine eigene Requirement definieren müsste.

    #1: nein. Bei ConfigMgr ist das keine Minimalanforderung, sondern *die* Anforderung. Für alles andere ist die Bedingung nicht erfüllt. Entsprechend wird auch der DT auf einem Win 10 PC (auf mein Bsp bezogen) nicht installiert.

    #2: doch. Ausschliesslich so, wie im Requirement definiert. Und ja: für jede Windows Version muss das Requirement dann gelistet sein.


    Torsten Meringer | http://www.mssccmfaq.de


    Wednesday, January 9, 2019 1:06 PM
    Answerer
  • Hallo Männer,

    es klappt prima mit 2 Bereitstellungstypen (1xW7 & 1x W10 ) und der jeweiligen Anforderungen zum Betriebssystem!

    Ich danke euch!

    Schönes Wochenende


    Toni

    Friday, January 18, 2019 10:56 AM