Immer Probleme mit dieser Adobe Cloud

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

Bei der (extrem umständlichen) Geräte-Lizenzierung innerhalb der ADOBE Cloud kommt nun erschwerend dazu, dass bei nicht erfolgter Lizenzierung und fehlender Installation von Acrobat Reader PDF-Dateien nicht geöffnet werden können.

Die Lösung:
Adobe DC deinstallieren, Acrobat Reader installieren – alles per Script remote.

Ich mache das natürlich mit ADMINOMAT für gesamte OrganisationsEinheiten (anstatt von PC zu PC zu gehen…)

1.) Acrobat DC deinstallieren:
ADMINOMAT starten -> OU auswählen -> PSEXEC ->

msiexec /X {AC76BA86-1033-FFFF-7760-0C0F074E4100} /qn REBOOT=Suppress

(wobei {AC76BA86-1033-FFFF-7760-0C0F074E4100} bzw. der entsprechende Eintrag gesucht werden muss in für 64bit: HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
für 32bit: HKLM\Software\Microsoft\Windows\CurrentVersion‌​\Uninstall

1a) mit ADIMONAT eventuell kontrollieren, ob UnInstall erfolgreich war:
Ansicht -> Detailfelder -> “acrobat” eingeben

2.) Acrobat Reader als Offline-Installer herunterladen

3.) Acrobat REader mit ADMINOMAT installieren
ADMINOMAT starten -> OU auswählen -> PSEXEC ->

/V /C “\\Server\share\AdbeRdr11010_de_DE.exe”  /sAll /msi /norestart ALLUSERS=1 EULA_ACCEPT=YES

3a) mit ADIMONAT eventuell kontrollieren, ob Rollout erfolgreich war:
Ansicht -> Detailfelder -> “reader” eingeben

Posted in Active Directory, Adminomat | 1 Comment

Fehlerhafte Absenderadressen in Office365 Exchange – Lösung

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

Problem:
Aus dem Active Directory nach Office 365 exportierte Benutzer haben als erste E-Mail-Adresse nicht die gewünschten “Domänenerweiterungen”, sondern Adressen nach dem Muster

Benutzername@MeineFirma.onmicrosoft.com
und zusätzlich
Benutzername@wunschdomain.at

Mails können an beide Adressen versandt bzw. empfangen werden, beim Versenden wird aber die unerwünschte
Benutzername@MeineFirma.onmicrosoft.com
als Absenderadresse verwendet, was nicht nur etwas ungünstig wirkt, sondern bei manchen als SPAM klassifiziert wird.

Ursache:
Während der Synchronisierung der Benutzer aus Active Directory mittels Synchronization Service Manager bzw. Azure AD Connect werden auch alle Attribute synchronisiert. Dazu zählt auch das Feld “E-Mail”.
Ist dieses Feld leer, dann wird nach der Synchronisierung automatisch eine Mailbox angelegt nach obigem Muster.

Der Versuch, den Eintrag für den Primären SMTP-Server per PowerShell zu ändern schlägt fehl!
Fehlermeldung:

Fehler bei Vorgang für Postfach "BRGM_TestUser", da es außerhalb des 
Schreibbereichs für den aktuellen Benutzer liegt. Die Aktion 'Set-Mailbox',
'EmailAddresses', kann nicht für das Objekt 'BRGM_TestUser' durchgeführt 
werden, weil dieses Objekt von lokal synchronisiert wird. Diese Aktion sollte
lokal für das Objekt durchgeführt werden.

——————————– EXKURS – ist zur Problemlösung völlig uninteressant                    ——————-

Zur Info – und damit ich es selber schneller finde beim nächsten Anlass:

1.) PowerShell-Script, um alle User inkl. einschlägiger Attribute in ein csv zu exportieren:
HINWEIS: PowerShell als Administrator starten und folgenden Befehl absetzen:
Set-ExecutionPolicy Unrestricted

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://outlook.office365.com/powershell-liveid/" -Credential $cred -Authentication Basic -AllowRedirection
 Import-PSSession $session
 Get-Mailbox -Resultsize Unlimited | Select Alias, UserPrincipalName, WindowsEmailAddress | Export-Csv "C:\off365\user.csv"

2.) csv entsprechend ändern – WICHTIG: Felder MÜSSEN mit KOMMA (NICHT SEMIKOLON) getrennt sein!!!

Recipient PrimaryEmail AliasEmail
edi.mustermann edi.mustermann@MeineSchule.at edi.mustermann@MeineSchule.onmicrosoft.com

3.) Das PowerShell-Script, das mit den Daten aus dem .csv die Primary SMTP-Address ändert:

$Recipients = Import-Csv C:\off365\User.csv
Foreach ($Mailbox in $Recipients)
{
Set-Mailbox -Identity $Mailbox.Recipient -EmailAddresses $Mailbox.PrimaryEmail,$Mailbox.AliasEmail 
}

——————————————————— EXKURS – ENDE  ——————————————————–

Lösung:
Das entsprechende Attribut “E-Mail” muss direkt in Active Directory am DC für den jeweiligen User geändert werden! (Im FachChargon würde das dann “On Premises” genannt werden)
Danach wird es automatisch synchronisiert und die Einträge stimmen auch in Office 365.

Nachdem das für ein paar Hundert User nicht manuell durchführbar ist, hier ein VBScript, mit dem im Bulk – also massenhaft – Benutzern das Attribut eingetragen wird:
(Quelle: Scripting Guys und ein paar Extrazeilen)

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 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("Name").Value

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

		    objUser.Put "mail", objRecordSet.Fields("Name").Value & "@meineDomain.at" 
		    objUser.SetInfo

    objRecordSet.MoveNext

Loop

Verwendung:
Auf einen DomänenController als “Emailer.vbs” speichern und die Einträge an die eigene Domäne anpassen!
(Zeile 11 und Zeile 24)
Abschließend in einer Command-Shell mit
cscript Emailer.vbs
starten.

Die Benutzernamen schwirren dann über den Bildschirm – und nach wenigen Sekunden haben alle Benutzer den gewünschten Eintrag im Feld E-Mail im AD. Nach der nächsten Synchronisierung dann auch in Office 365.

In Office 365 bleiben weiterhin beide zu Beginn genannten Mailadressen erhalten, auch am Loginnamen ändert dies nichts! Lediglich der Eintrag für den Primary SMTP-Server (=Absendeadresse) wird geändert.

 

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

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 [1 Bewertung, Durchschnitt: 5,00]

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!



style="display:block"
data-ad-client="ca-pub-3997389528218855"
data-ad-slot="2006664521"
data-ad-format="auto">

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 | 4 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