per VBScript MailAttribute aus den UserAccounts entfernen

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

Es war einmal ein Exchange – der dann abgedreht wurde – und die User wurden dann auf Gmail umgesiedelt.

Das lief prima – bis die User auf den Hosted Exchange von OFFICE365 migriert werden sollten… (und es ja onPrime keinen Exchange mehr gab)…

Das folgende Script hat diese Einträge für alle User einer bestimmten OU entfernt – seither klappts mit der Migration wie am Schnürchen…
Als ExchangeAttributeDelete.vbs speichern und direkt am Domänencontroller starten (nach Anpassung an die eigene Domain!)

On Error Resume Next
Const ADS_SCOPE_SUBTREE = 2

Const ADS_PROPERTY_APPEND = 3
Const ADS_PROPERTY_DELETE = 4
Const ADS_PROPERTY_CLEAR = 1 

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 legacyExchangeDN, name, distinguishedName, sAmAccountname, proxyaddresses FROM 'LDAP://OU=lehrer,OU=Benutzer,DC=gymnasium,DC=at' WHERE objectCategory='user'"

Set objRecordSet = objCommand.Execute

objRecordSet.MoveFirst

Do Until objRecordSet.EOF

    'Wscript.Echo objRecordSet.Fields("distinguishedName").Value
	if len(objRecordSet.Fields("legacyExchangeDN").Value)>= 1  THEN
	Wscript.Echo objRecordSet.Fields("sAmAccountname").Value & " -- " & objRecordSet.Fields("Name").Value

	'# falls man das Script nur für einen User testen möchte:  (ACHTUNG: zweites END IF unten einkommentieren)
	'if objRecordSet.Fields("name").Value = "WUT" then
	'Wscript.Echo objRecordSet.Fields("name").Value

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

	Wscript.Echo objRecordSet.Fields("legacyExchangeDN").Value
	wscript.echo len(objRecordSet.Fields("legacyExchangeDN").Value)

			objUser.PutEx ADS_PROPERTY_CLEAR, "msExchHomeServerName", 0
			objUser.SetInfo

			objUser.PutEx ADS_PROPERTY_CLEAR, "legacyExchangeDN", 0
			objUser.SetInfo

			objUser.PutEx ADS_PROPERTY_CLEAR, "homeMDB", 0
			objUser.SetInfo

			objUser.PutEx ADS_PROPERTY_CLEAR, "homeMTA", 0
			objUser.SetInfo

			objUser.PutEx ADS_PROPERTY_CLEAR, "mDBUseDefaults", 0
			objUser.SetInfo

			objUser.PutEx ADS_PROPERTY_CLEAR, "msExchALObjectVersion", 0
			objUser.SetInfo

			objUser.PutEx ADS_PROPERTY_CLEAR, "msExchMailboxGuid", 0
			objUser.SetInfo

			objUser.PutEx ADS_PROPERTY_CLEAR, "msExchMailboxSecurityDescriptor", 0
			objUser.SetInfo

			objUser.PutEx ADS_PROPERTY_CLEAR, "msExchPoliciesIncluded", 0
			objUser.SetInfo

			objUser.PutEx ADS_PROPERTY_CLEAR, "msExchUserAccountControl", 0
			objUser.SetInfo

			objUser.PutEx ADS_PROPERTY_CLEAR, "msNPAllowDialin", 0
			objUser.SetInfo

			objUser.PutEx ADS_PROPERTY_CLEAR, "ShowInAddressBook", 0
			objUser.SetInfo

			objUser.PutEx ADS_PROPERTY_CLEAR, "textEncodedORAddress", 0
			objUser.SetInfo

			wscript.Echo "erfolgreiche geloescht!" & vbcrlf

	'end if
	end if

    objRecordSet.MoveNext

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

per VBScript Einträge im AD aus dem Attribut ProxyAddresses entfernen

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

Es kann vorkommen, dass in historisch gewachsenen Domänen einzelne (oder alle) User Einträge im AD-Attribut “ProxyAddresses” haben, die auf einen alten Exchange / Gmail / etc hinweisen.

Dies ist äußerst hinderlich, wenn man diese Benutzer per Azure AD Connect ins OFFICE 365 übertragen möchte, da dieser Eintrag dazu führt, dass Benutzer kein Outlook-Konto in OFFICE365 bekommen.

Die Fehlermeldung lautet dann:

Mailfehler

 
 
 
 
Benutzername       xyz@domain.at    E-Mail-Adresse  Aliase   Anzeigen nicht möglich. Versuchen Sie es noch mal.
 

Die Lösung ist es nun, die Einträge im Attribut “ProxyAddresses” zu entfernen, was folgendes Script massenhaft erledigen kann:
(als MassenAttributlöscher.vbs speichern und direkt am Domänencontroller ausführen)

On Error Resume Next
Const ADS_SCOPE_SUBTREE = 2
Const ADS_PROPERTY_APPEND = 3
Const ADS_PROPERTY_DELETE = 4
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, sAmAccountname, proxyaddresses FROM 'LDAP://OU=lehrer,OU=Benutzer,DC=gymnasium,DC=at' WHERE objectCategory='user'"

Set objRecordSet = objCommand.Execute

objRecordSet.MoveFirst

Do Until objRecordSet.EOF

    'Wscript.Echo objRecordSet.Fields("distinguishedName").Value
	if NOT objRecordSet.Fields("proxyaddresses").Value = NULL THEN
	Wscript.Echo objRecordSet.Fields("sAmAccountname").Value & " -- " & objRecordSet.Fields("Name").Value

	'# falls man das Script nur für einen User testen möchte:  (ACHTUNG: zweites END IF unten einkommentieren)
	'if objRecordSet.Fields("name").Value = "DRE" then
	'Wscript.Echo objRecordSet.Fields("name").Value

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

	'### zum Löschen aller Einträge in ProxyAddresses folgendes einkommentieren:
	For Each objItem In arrProxyAddresses

					objUser.PutEx ADS_PROPERTY_DELETE, "proxyAddresses", Array(objItem)
					objUser.SetInfo

	Next

	'### zum Einfügen einer zusätzlichen Adresse folgendes einkommentieren:

				' objUser.PutEx ADS_PROPERTY_APPEND, "proxyAddresses", Array("smtp:" & objRecordSet.Fields("sAmAccountname").Value & "@brg-mattersburg.at" )
				 'objUser.SetInfo

	'### zum Auflisten aller Einträge in ProxyAddresses folgendes einkommentieren:
	For x=0 to UBOUND(arrProxyAddresses)
		wscript.echo arrProxyAddresses(x)

	Next

			wscript.Echo "erfolgreiche gelöscht!" & vbcrlf

	end if
	'end if

    objRecordSet.MoveNext

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

Immer Probleme mit dieser Adobe Cloud

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

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