Gebrauchte Lizenzen – eine echte Alternative zu Open Source

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

Bei steigender Budgetknappheit ist es nahe liegend, dass nebst der Kosten für Hardware und externes Consulting auch jene für Lizenzen in den Fokus rücken.

Selbstverständlich ist hier die Verwendung von OpenSource-Betriebssystemen eine veritable Alternative.
Meine jahrzehntelange Erfahrung im Bereich der Server-Administration, aber auch im direkten Kontakt mit Endbenutzern zeigen mir aber, dass die Kostenersparnis nur dann eintritt, wenn eine weitreichende Akzeptanz seitens der User vorhanden ist.

Dies inkludiert die Bereitschaft zur Aneignung neuer Kompetenzen in Eigenregie. Sobald diese Bereitschaft fehlt, kann der Schuss schnell nach hinten losgehen:
Die Schulungskosten steigen, die Motivation und Arbeitsleistung nimmt ab.

Oft scheitert die Idee des Umstiegs auf Linux-Betriebssysteme aber auch einfach an Spezialanwendungen, die Windows als Betriebssystem fordern.

Eine Lösung für die Problematik kann hier sicherlich in der Anschaffung von gebrauchten Lizenzen liegen.
Die Kosten der Anschaffung sinken – bei gleichzeitiger Akzeptanz der User, da sie mit der gewohnten Umgebung weiter arbeiten können.

Hinsichtlich der Legalität dieser Lösung gibt es bei Einhaltung einiger Tipps keinerlei Bedenken – es sind genügend Erkenntnisse der Höchstgerichte vorhanden!

Beachtet werden sollte lediglich, dass die Lizenzen von etablierten und seriösen Unternehmen erworben werden.

Empfohlen kann hier sicherlich die Firma USC mit Sitz in Deutschland werden, die sich seit Jahren als kompetenter Partner in Lizenzfragen einen guten Namen in der Fachpresse erworben hat.

Nebst dem übersichtlichen und umfangreichen Webshop für gebrauchte Software-Lizenzen finden sich auf der Website auch noch ein paar Tipps, wie man seriöse von unseriösen Angeboten unterscheiden kann.

Ein Blick auf deren Angebot sowie die Preisliste lohnt sich in jedem Fall!

Posted in Office 365, Software, Windows 7, Windows 8, Windows Server 2008 | Leave a comment

KMS für Office 2016

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

Die Konfiguration des KMS für die Lizenzierung von Office 2016 unterscheidet sich durch nichts von der bereits erfolgten Anleitung für Office 2013.

Bevor sich die Aktivierung starten lässt, ist (zumindest für Server2008R2) ein Update zu installieren, das einen Reboot erfordert (

Die Abfrage, ob der Key erfolgreich hinterlegt wurde bzw. wie viele Clients aktuell über den Schlüsselverwaltungsdienst aktivert werden, erfolgt mit:

C:\Windows\System32\slmgr.vbs -dlv 98EBFE73-2084-4C97-932C-C0CD1643BEA7

Posted in Active Directory, Key Management Service (KMS) | Leave a comment

User per VBScript aus dem AD in eine .csv exportieren für MAHARA-Import

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

Der Massenimport via .csv von Usern in MAHARA ist (vor allem, wenn man auf das deutsche Language-Pack umgestellt hat) voll der Pein und Trauer…

Anbei ein Script, dass ausgewählte Schüler anhand ihrer Mitgliedschaft zu einer OU in einer CommandShell ausgibt, die man dann nur noch kopieren muss in eine .csv und importieren…

Speicher als “maharaExport.vbs” und in einer Commandshell mit
cscript maharaExport.vbs
ausführen lassen…

'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 

'### hier die gewünschte OU auswählen ######
course = "3A,3B,3C,3D,3E"

courseArr = split(course,",")

'Wscript.Echo "Benutzername;Passwort;E-Mail;Vorname;Nachname;Studenten-ID"
Wscript.Echo "username,password,email,firstname,lastname,studentid"
UserCounter = 20170001

for i = 0 to UBOUND(courseArr)
	objCommand.CommandText = "SELECT name, distinguishedName, sAmAccountname, mail, givenName, SN FROM 'LDAP://OU=" & courseArr(i) & ",OU=Schueler,OU=Benutzer,DC=hak-neusiedl,DC=local' WHERE objectCategory='user'"

	Set objRecordSet = objCommand.Execute

	objRecordSet.MoveFirst

	Do Until objRecordSet.EOF

		Wscript.Echo  chr(34) & objRecordSet.Fields("sAmAccountname").Value & chr(34) & "," & chr(34) & "ASDFASDF" & chr(34) & "," & chr(34) & objRecordSet.Fields("mail").Value & chr(34) & "," & chr(34) & objRecordSet.Fields("givenName").Value & chr(34) & "," & chr(34) & objRecordSet.Fields("SN").Value & chr(34) & "," & chr(34) & UserCounter & chr(34) '& "," & courseArr(i)

		objRecordSet.MoveNext
		UserCounter = UserCounter+1
	Loop

next
Posted in Active Directory, Scripts, VBScript | Leave a comment

Kurzzusammenfassung: OFFICE 365 inkl Mail für NEUE SchülerInnen

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

Damit ich selbst nicht vergesse (und nur dafür):

  1. User im AD anlegen
  2. Kontrollieren, ob am Reiter “Konto” der Benutzeranmeldename auch auf die richtige Domain lautet
  3. Mailadresse per Script hinterlegen direkt im AD
  4. User mit Azure Connect syncen
  5. Usern per Script die Lizenz zuweisen sowie das Land
Posted in Azure, Exchange, Office 365 | Leave a comment

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

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 | Leave a 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