Massenlizenzierung in Office365 mit Powershell

sehr verwirrender ArtikelNaja, ganz OKbrauchbar für Checker...guter Artikelsehr guter Artikel - Danke

Problem:
Nachdem die Benutzer aus dem Active Directory mit dem Synchronization Service Manager bzw. Azure AD Connect mit Office 365 synchronisiert wurden, müssen ihnen noch Lizenzen zugewiesen werden.

Lösung:
Variante 1:
Die Zuweisung von Lizenzen kann in der WebGUI erfolgen.
Checkboxen der betreffenden User auswählen -> Massenaktionen -> Produktlizenzen bearbeiten
[Problem dieser Methode: das dauert bei mehreren Hundert Benutzern vieeel zu lange!!!]

Variante 2 (Empfohlen ab einer größeren Anzahl von Usern):
Die Zuweisung von Lizenzen kann mittels PowerShell erfolgen (empfohlene Methode!):

Vorbereitung:
Am DC, auf dem Azure AD Connect installiert wird, muss zuerst noch eine Kleinigkeit installiert werden (erfordert kein Reboot!)

  1. Microsoft Online Services-Anmelde-Assistenten für IT-Experten RTW
  2. Azure Active Directory-Modul für Windows PowerShell (64-Bit-Version)

1.) Verbindung zum Online Services Modul

Connect-MsolService

Benutzername nach dem Muster Wurstmann@WurstDomain.local eingeben!

 

2.) Eine Abfrage mit den vorhandenen Lizenzen:

Get-MsolAccountSku

get-msolAccountSku1

 

3.) Allen bzw. bestimmten Usern eine UsageLocation zuweisen

Get-MsolUser -All | where {$_.UserPrincipalName -match "@brg-MeineSchule.at"} | Set-MsolUser -UsageLocation "AT"

Der Teil  | where …. | ist optional

Anschließende Kontrolle, ob die Location zugewiesen wurde
:

Get-MsolUser -UserPrincipalName "edi@brg-MeineSchule.at" | Select-Object UsageLocation

 

 

4.) Allen bzw. bestimmten Usern eine Lizenz zuweisen!

Tipp: die Zuweisung von mehreren Lizenzen ist nicht möglich!!!
Daher empfiehlt es sich, in nachfolgender Zuweisung nach Usern zu filtern, die noch keine Lizenz zugewiesen bekommen haben.

where {$_.UserPrincipalName -match [...] } ist wieder optional!!!

Get-MsolUser -All -UnlicensedUsersOnly | where {$_.UserPrincipalName -match "NMS_"} | Set-MsolUserLicense -AddLicenses BGbrg-MeineSchule:STANDARDWOFFPACK_IW_STUDENT

Eine Zuweisung für alle User wäre also:

Get-MsolUser -All -UnlicensedUsersOnly | Set-MsolUserLicense -AddLicenses BGbrg-MeineSchule:STANDARDWOFFPACK_IW_STUDENT

Die jeweiligen Vorgänge dauern einige Minuten – abhängig von der Benutzeranzahl – und werden ohne Meldung abgeschlossen. Keine Fehlermeldung = Erfolg!

Posted in Active Directory, Azure, Office 365, Scripts | Leave a comment

Office 365 – Benutzernamen haben eine falsche Domain

sehr verwirrender ArtikelNaja, ganz OKbrauchbar für Checker...guter Artikelsehr guter Artikel - Danke

Problem:
Die Benutzername in Office 365 – insbesonders der Teil hinter dem @ (also der Domänenname) ist nach der synchronisierung nicht wie gewünscht!

NICHT
Benutzername@wunschdomain.at
SONDERN
Benutzername@MeineFirma.onmicrosoft.com

Ursache:
Als Benutzername wird der UPN (der in Active Directory Benutzer und Computer –> rechte Maustaste auf User –> Eigenschaften –> Attribut-Editor –> User Principle Name angezeigt wird) verwendet. Falls sich dieser (bzw. der Domain-Teil) von der in Office365 registrierten Domäne unterscheidet, dann wird stattdessen  @MeineFirma.onmicrosoft.com verwendet.

Lösung:

  • 1.) Active Directory-Domänen und -Vertrauensstellungen -> Rechte Maustaste -> Domäne hinzufügenDomainHinzufügen
  • Den UPN-Suffix für alle User einer OU ändern:
    Alle User markieren -> Eigenschaften ->UPN_Suffix_Ändern

Nach der nächsten Synchronisierung sind die Benutzernamen in der Weboberfläche richtig, und damit können sich die Benutzer dann auch mit dem von uns erwünschten UPN einloggen

 

Abschließend ein VBScript, das massenhaft im Bulk für alle User einer OU und UnterOU die Einträge für den “Benutzer-PrinzipalsNamen-Suffix” aka UserPrincipalName vornimmt:

On Error Resume Next
Const ADS_SCOPE_SUBTREE = 2
Set objConnection = CreateObject("ADODB.Connection")
Set objCommand =   CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"
Set objCommand.ActiveConnection = objConnection
objCommand.Properties("Page Size") = 1000
objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE 

objCommand.CommandText = "SELECT userPrincipalName, name, distinguishedName FROM 'LDAP://OU=Schueler,OU=Benutzer,DC=MeineSchule,DC=at' WHERE objectCategory='user'"

Set objRecordSet = objCommand.Execute

objRecordSet.MoveFirst

Do Until objRecordSet.EOF

    'Wscript.Echo objRecordSet.Fields("distinguishedName").Value
	Wscript.Echo objRecordSet.Fields("userPrincipalName").Value

			Set objUser = GetObject("LDAP://" & objRecordSet.Fields("distinguishedName").Value)

		    objUser.Put "userPrincipalName", objRecordSet.Fields("Name").Value & "@meine-schule.at" 
		    objUser.SetInfo

			'wscript.Echo "done"

    objRecordSet.MoveNext

Loop

Verwendung:
Zeile 11 und 25 an die eigene Umgebung anpassen!

Als “userUpdater.vbs” am DomänenController speichern und in einer Command-Shell mit
cscript userUpdater.vbs
starten.

Posted in Active Directory, Azure, Office 365, Scripts | 1 Comment

Rollout Scribus in einer Domäne

sehr verwirrender ArtikelNaja, ganz OKbrauchbar für Checker...guter Artikelsehr guter Artikel - Danke

Einer der einfachsten Wege, Scribus (und andere Software, die nicht als .msi daherkommt) auszurollen, ist mit dem Einsatz von ADMINOMAT möglich.

Vorgangsweise:
ADMINOMAT downloaden
PsExec downloaden und in den selben Ordner speichern, wo ADMINOMAT ist

Scribus downloaden und auf ein Share speichern

Vorgangsweise:

Adminomat starten -> betreffende PCs auswählen –> Schaltfläche “psexec” ->
/V /C “\\Server\share\scribus146.exe” -install

Beim jeweils angemeldeten User erscheint darauf hin die Installationsroutine (ohne dass er dabei lokale Admin-Rechte hat!) und klickt sich nun einfach durch…
(Anmerkung: falls kein User angemeldet ist, läuft das ganze auch!!! Der jeweils nächste User bekommt gleich nach dem Login die Installationsroutine auf den Desktop…)

Einfacher, rascher und kostengünstiger ist das kaum machbar…

Tipp: von ADMINOMAT gibt es eine kostenlose Testversion!

Posted in Active Directory, Adminomat, Rollout, Software | Leave a comment

Warnung: Unifi UAP AC Lite – Beschädigung durch EdgeSwitch 8-150

sehr verwirrender ArtikelNaja, ganz OKbrauchbar für Checker...guter Artikelsehr guter Artikel - Danke [1 Bewertung, Durchschnitt: 5,00]

Nach eigener leidvoller Erfahrung muss ich vor folgendem Szenario warnen:

Unifi UAP AC Lite werden in Verbindung mit dem Unifi Edgeswitch 8 Port 150 W unter gewissen Umständen dauerhaft beschädigt!

Näheres gibt es hier zu lesen bzw. auch Informationen über den Austausch bereits beschädigter Geräte durch Ubiquiti

https://www.ubnt.com/edgemax/edgeswitch-8-150w/

Nichts desto trotz sind das tolle Geräte mit einem sagenhaften Preis/Leistungsverhältnis!

Posted in WLAN | Leave a comment

Rollout ProjectLibre mit ADMINOMAT

sehr verwirrender ArtikelNaja, ganz OKbrauchbar für Checker...guter Artikelsehr guter Artikel - Danke [1 Bewertung, Durchschnitt: 5,00]

Mit dem Tool ADMINOMAT kann natürlich auch in wenigen Minuten das Rollout von ProjectLibre erledigt werden!

ToDo-List:

  1. ADMINOMAT download
  2. psexec download uns in das gleiche Verzeichnis kopieren, in dem ADMINOMAT liegt
  3. ProjectLibre download
  4. ProjectLibre_1_6_2.msi auf ein Netzwerkshare kopieren
  5. im ADMINOMAT die OU auswählen, in der die Software ausgerollt werden soll
  6. ADMINOMAT -> PSEXEC -> Eingabe:
    msiexec /qn /a \\Server\Share\projectlibre162.msi
  7. Fertig

Nähere Infos und ein paar Screenshots zu ADMINOMAT gibts hier

Posted in Active Directory, Adminomat | Leave a comment

Rollout Flash Player 23 in einer Windows Domäne

sehr verwirrender ArtikelNaja, ganz OKbrauchbar für Checker...guter Artikelsehr guter Artikel - Danke [1 Bewertung, Durchschnitt: 5,00]

Mittels ADMINOMAT lässt sich auch die derzeit aktuelle Version 23 des Adobe Flash Player ausrollen….

Downloadlink Flash Player: hier

Beischreibung der Vorgangsweise in diesem Artikel

Edit:
Aufgrund des Hinweises in den Kommentaren:
Bitte rollen Sie Flash Player 23 NICHT aus, dies wird nämlich von Adobe explizit seit Version 23 untersagt!
Ich wollte nur darauf hingewiesen haben…. Sie machen das Rollout auf eigene Gefahr! Es entspricht nicht den Lizenzbestimmungen von Adobe ist daher verboten!!!!

 

Posted in Active Directory, Adminomat, Rollout, Software | 3 Comments

PDF erstellen mit webPDF

sehr verwirrender ArtikelNaja, ganz OKbrauchbar für Checker...guter Artikelsehr guter Artikel - Danke [1 Bewertung, Durchschnitt: 5,00]

 Problem: Häufige Updates  Adobe Acrobat Reader

Am 19. 6. 2016 wurde die aktuellste Version [15.016.20041] von Acobe Acrobat (Reader) DC als optionales Update released. Sollte man die automatischen Updates nicht deaktiviert haben, werden User durch entsprechende Meldungen auf Updates hingewiesen, was uns AdministratorInnen wiederum Arbeit beschert.

Seit Anfang 2016 wurden bis zum heutigen Tag (Stand: 22. 6. 2016) 6 Updates angeboten, was für SystemadministratorInnen einen – für mich zumindest – inakzeptablen Mehraufwand bedeutet, den es zu vermeiden gilt.

Die Deaktivierung der automatischen Updates bzw. Unterdrückung der Meldung bringt hier nur bedingten Erfolg, da die zu den Updates führenden Sicherheitsrisiken bzw. Bugs dadurch nicht behoben werden.

Mir erscheint als einzig tragbare und wartungsfreieste Lösung ein zentralisierter Ansatz sinnvoll, dh, eine Serverlösung, auf die Benutzer zugreifen.

Aus Sicht des Datenschutzes müssen dabei Lösungen, die als Service im Web angeboten werden, vermieden werden, da unternehmensinterne Daten keinesfalls aus der Hand gegeben werden dürfen!

Wünschenswert wäre es also, eine Lösung zu finden, die folgende 3 Kriterien erfüllt:

  1. Keine Clientinstallation (um die bereits bekannten Probleme wie Updates etc zu verhindern)
  2. Daten dürfen das Unternehmen nicht verlassen
  3. Intuitive Handhabung für die BenutzerInnen

Lösung: PDF erstellen mit webPDF

Ich wurde nun fündig anhand der Lösung von WebPDF. Hier wurden konsequent die oben gelisteten Forderungen umgesetzt.

Das Konzept im groben Überblick:

Es wird auf einem beliebigen (auch virtualisierten) Rechner innerhalb der Infrastruktur WebPDF installiert (Betriebssystem ab Windows XP Pro bzw. Server 2003 bis Server 2012 R2 bzw. Linux) – und das wars auch schon!
Die BenutzerInnen greifen mittels Weboberfläche auf den Service zu, wodurch eine Clientinstallation entfällt! Darüber hinaus kann dieser Dienst natürlich auch – zb via VPN oder SSL – an verschiedenen Unternehmensstandorten genutzt werden. Zeitraubende Updates auf den Clients gehören damit der Vergangenheit an!

Da ein Bild mehr als 1000 Worte sagt:

webpdf_technical_concept_deu_ph

WebPDF arbeitet mit allen gängigen Dateiformaten, von Office-Dateien über Bilddateien bis hin zu Websites oder Mails, und erstellt daraus ein PDF. Mit an Board ist eine weiters eine PDF-OCR Funktion sowie die Möglichkeit, PDF-Dateien zu signieren.

Darüber hinaus gibt es für Entwickler entsprechende Schnittstellen, sodass aus selbst erstellten Anwendungen auch direkt auf den zentralen Service zugegriffen werden kann. Eine Integration in SAP, Exchange etc ist ebenfalls einfachst zu realisieren.

Interessant für zertifizierte Unternehmen ist auch, dass der ISO-Standard 19005-2:2012 (PDF/A-3) eingehalten wird!

 

Posted in JAVA, Software, Windows 7, Windows 8, Windows Server 2003, Windows Server 2008 | Leave a comment

Tool, um lokalen Client direkt am PC in eine andere OU im AD verschieben

sehr verwirrender ArtikelNaja, ganz OKbrauchbar für Checker...guter Artikelsehr guter Artikel - Danke [3 Bewertung, Durchschnitt: 3,33]

Problem:
Es kommt manchmal vor, dass ein Client der falschen Organisationseinheit zugeteilt wurde.

Ein Verschieben wird meist dadurch vorgenommen, dass man sich remote zu einem Domänen Controller verbindet und diesen Client dann in “Active Directory-Benutzer und -Computer” sucht bzw verschiebt.

Dies erschien uns recht umständlich und kostet außerdem Zeit (die wir lieber für andere Aktivitäten verwenden möchten…)

Daher waren wir auf der Suche nach einem Tool, das dies ohne Umwege direkt am jeweiligen Client ermöglicht.

Lösung:
ADMINOMAT hat seit der Version 2.01 folgende neue Features:

  • Der Name des Clients bzw dessen IP-Adresse wird direkt in der Titelzeile des Programms angezeigt
  • im Menüpunkt Datei findet sich
    move local PC to OU
    –> ein Mausklick weiter kann nun der Client einfach verschoben werden

Vorgangsweise:

Szenario: am Client ist ein beliebiger User angemelden, der über keine besonderen Rechte verfügt.
Wir möchten diesen User nicht abmeldet, auch nicht den Benutzer wechseln, weil:
wir wollen möglichst rasch wieder in unser Büro zurück  ;-)

  1. ADMINOMAT downloaden, .rar an beliebigen Ort (C:\ oder USB-Stick bzw. Netzlaufwerk) entpacken.
    Wichtig: es wird NICHTS installiert, ADMINOMAT läuft sofort – auf jedem Windows Client ab XP!
  2. Umschalttaste drücken + RECHTE Maustaste auf adminomat.exe ->
    Als anderer Benutzer ausführen
    –> User verwenden, der in der Gruppe der Domänen-Administratoren ist
  3. Menüpunkt DATEI -> Move local Client to OU
  4. verschieben -> fertig!

moveOU

Posted in Active Directory, Adminomat, Gruppenrichtlinie, Netzwerk, Software | Leave a comment

Rollout Flash Player 21 in einer Domain

sehr verwirrender ArtikelNaja, ganz OKbrauchbar für Checker...guter Artikelsehr guter Artikel - Danke [1 Bewertung, Durchschnitt: 5,00]

Das Tool ADMINOMAT kann auch dazu verwendet werden, um Flash Player 21 auszurollen.

Adminomat_2.0

Vorgangsweise:
1.) Download der Offline-Installation von Flash-Player, z. B. hier
2.) ADMINOMAT und PSEXEC im selben Ordner speichern
3.) ADMINOMAT starten
4.) OU oder einzelne Rechner auswählen –> PSEXEC anklicken
5.) folgendes eingeben (MIT Anführungszeichen!):

/V /C "\\server\share\install_flash_player_21_active_x.exe" -install

flash_rollout

6.) optional kontrollieren, ob alles läuft:
Ansicht / Detailfelder… / Software_Lookup –> Reload –> ins Popup “Flash Player 21″ eingeben

fertig

Posted in Active Directory, Adminomat, Gruppenrichtlinie | Leave a comment

Rollout JAVA 8 Update 91 mit ADMINOMAT

sehr verwirrender ArtikelNaja, ganz OKbrauchbar für Checker...guter Artikelsehr guter Artikel - Danke [2 Bewertung, Durchschnitt: 5,00]

Wie nicht anders zu erwarten war, funktioniert mit ADMINOMAT natürlich auch das Rollout für die Version JAVA 8 Update 91.

Eine detaillierte Beschreibung der Vorgangsweise gibts hier

Ein Bild sagt oft mehr als 1000 Worte:

VORHER:JAVA8_91_vorher_ NACHHER (und dazwischen liegen 2 Minuten :lol: ):JAVA8_91_nachher_ Kurzanleitung:

  1. Logon als DomänenAdmin an einem beliebigen PC innerhalb des AD
     
  2. Adminomat + psexec downloaden und beide in einen Ordner an einem beliebigen Ort speichern.
    Dies kann auch ein USB-Stick oder Netzlaufwerk sein!
     
  3. jre-8u91-windows-i586.exe bzw jre-8u91-windows-x64.exe auf einem ServerShare speichern
    (Anm.: wir brauchen KEINE .msi)
     
  4. Adminomat durch Doppelklick starten -> es ist KEINE Installation nötig
     
  5. gewünschte OU (Organisationseinheit) auswählen, gegebenfalls die Clients mit “boot” aufwecken
    (Anm.: WOL muss auf den Clients in diesem Fall aktiviert sein)
     
  6. Funktion //psexec// anlicken, im Popup folgende Befehlszeile eingeben:
     
    für 32bit Systeme:
     /V /C "\\SERVER\share\jre-8u91-windows-i586.exe" /s

    oder für 64bit Systeme:

     /V /C "\\SERVER\share\jre-8u91-windows-x64.exe" /s

    Tipp: im ADMINOMAT kann unter Ansicht->Detailfelder kann ausgewählt werden, dass angezeigt wird, ob die Clients als 32bit oder 64bit System laufen. Eine Sortierung danach ist ebenfalls möglich…

  7. Fertig!
Posted in Active Directory, Adminomat, Gruppenrichtlinie, JAVA | Leave a comment