blog.atwork.at

news and know-how about microsoft, technology, cloud and more.

Forever Immutable - ID gefällig - oder - Dirsync extended

Tuesday, May 7, 2013 10:01 PM Christoph Wilfing
Mir ist das zuletzt was interessantes passiert – es hat ein wenig mit einer Immutable ID zu tun – siehe Wiki. Also – einfach beschrieben ist eine ImmutableID eindeutig und sollte sich niemals ändern. Das bringt mich auf eine Idee.. wollten sie schon immer mal die Welt aus den Angeln heben und etwas unveränderliches ändern? Jetzt ist die Zeit dafür gekommen. Ich habe zuletzt bei einem Kunden das Problem bei einer frischen ADFS / DirSync Installation als Basis aber eine bestehende Domain ohne onPremise Exchange aber mit bestehendem W14 O365 Account. Also – der Kunde hat halt bisher an lokalen Domain User gehabt plus eine online Identity die getrennt voneinander zu verwalten war. Was letztendlich etwas lästig aber in kleineren Umgebungen ja nicht so dramatisch ist. Trotzdem wollte der Kunde auf ADFS inkl. Dirsync umstellen mit dem Problem – wie genau krieg ich Dirsync dazu einen lokalen User auf einen online User zu matchen und nicht sofort alles kaputt zu machen? Naja – es gibt mal eine offizielle Aussage wie DirSync ein Matching macht wenn man nachträglich synchronisiert. http://technet.microsoft.com/en-us/library/jj863117.aspx Matching functionality 1—GUID match logic. When you reactivate directory synchronization, objects in the on-premises Active Directory are matched with objects in the cloud according to previous directory synchronization GUID (objectGUID) on the cloud objects. When such a match is found, the directory synchronization process makes a GUID match and overwrites the target object data in the cloud objects with the data from the corresponding on-premises objects. Matching functionality 2—SMTP match logic. If directory synchronization does not find a GUID match in the cloud, a process called SMTP match is used. In this process, directory synchronization matches corresponding objects, according to the primary SMTP address. If a target (cloud) object’s primary SMTP address matches a primary SMTP address of an object in the on-premises organization, the data for the on-premises object is used to overwrite the data for the corresponding cloud object. ABER – ganz wichtig… http://support.microsoft.com/kb/2641663/en-us SMTP matching can be used only one time for user accounts that were originally authored by using Office 365 management tools. After that, the Office 365 user account is bound to the on-premises user by an immutable identity value instead of a primary SMTP address. The cloud user’s primary SMTP address can't be updated during the SMTP matching process because the primary SMTP address is the value that is used to link the on-premises user to the cloud user.  Wie man so schön sagt – da gibts jetzt genau EINEN Versuch – wenn der schief geht – hat ma doppelte Accounts. Blöd eher. Aber – ich wäre nicht ich wenn ma das ned mit ein paar zeilen Powershell wieder lösen könnte Also – Ärmel hochgekrempelt und los gehts. Step 1: Durch den fehlgeschlagenen Sync hat man mal einen Account der die Mailbox besitzt und einen Account der gesynct wurde und keine Mailbox besitzt. Meistens leicht zu erkennen am falschen UserPrincipalName. Einen User mit der “original” Domain und einen mit der “@<tenant>.onmicrosoft.com” (hier simuliert). Jetzt muss man mal den falsch gesyncten User löschen – wir müssen leider auch den gelöschten User aus dem Papierkorb löschen, da ja sonst unser User beim Sync wieder gematched wird. (im Papierkorb) Step 2: Jetzt müssen wir unserem DirSync beibringen das es unseren User schon gibt. Nachdem wir aber beim ersten Sync nachlässig waren und damit in der DirSync Datenbank bereits ein User existiert der nicht auf den User im Azure Active Directory gematched wurde, müssen wir das halt.. “von Hand” machen. Im DirSync Client (miisclient.exe – zu finden auf dem DirSync Server im Install Verzeichnis “\%programdir%\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe” einfach alle Accounts auflisten lassen und dann den entsprechendne sourceAnchor beim Searchresult hinzufügen (Rechtsklick | Column Settings). Der SourceAnchor entspricht der ImmutableID des Users den wir versuchen zu synchen. In unserem Online Account ist das aber leider “leer”… na dann.. lasst es uns setzen. Wie man sieht – geht das relativ einfach: Einmal den Sync anstossen im Dirsync und schon wird unser online User mit dem User vom lokalen Directory gematched und überschrieben. Jetzt kommt die klassische Frage – wenn ich jetzt aber 534 User habe und das ned jedesmal einzeln machen will? Ganz simple Powershell kann ja wie bekanntlich mehr. Einfach die Search im DirSync machen – alles markieren und copy / paste in ein Textfile. rauskommt ungefähr sowas: DisplayName,UPN,ImmutableID2013 Test01,2013Test01@2und40.at,m6RSeMTxIEucmy1Z/47Qrg==2013 Test02,2013Test02@2und40.at,eMxejPXflkSPCnK43ju40Q==2013 Test03,2013Test03@2und40.at,t+27mdq4fk+Gf/VxddxB4g==2010 Test01,2010test01@falsch.at,+bWKtuzDCUWFLtXi1gyDDQ==2010 Test02,2010Test02@2und40.at,B5vVE9Ei40mbpzz9MX114Q==2010 Test03,2010Test03@2und40.at,IpIqVbuWPUO7msNU+Tiz5g== Die erste Zeile wird manuell hinzufügt damit wir mit $UserList = Import-Csv -Delimiter ',' -Path .\userlist.txt diese Userliste in ein Object Importieren können. Danach ist es relativ simple die entsprechenden User mit der Azure Active Directory Powershell zu matchen, in etwa so: $UserList | % { Set-MsolUser -UserPrincipalName $_.UPN -ImmutableId$_.ImmutableID } Also – eigentlich nicht dramatisch oder? Wie immer gilt – für alle Schäden und kaputte User Accounts, verlorene Mailboxen oder zerstörte DirSync Installation oder sonstige Datenverluste bin ich weder verantwortlich noch verantwortlich zu machen. Jeder ist seines eigen Powershell Master. LG Christoph
Cloud | Microsoft | Office365 | PowerShell
mehr

Wie Sie Benutzern in Office 365 den Standort und Lizenzen zuweisen

Wednesday, February 6, 2013 7:25 PM Martina Grom
In Office 365 können viele Aufgaben über PowerShell vereinfacht werden. Einige der häufig zu verwendenden Befehle habe ich bereits im Blog beschrieben. Heute geht es um die Anforderung, vielen Benutzern auf einmal einen Verwendungsort zuzuweisen und diesen Benutzern dann auch eine Lizenz zuzuordnen. Nötig ist dies z.B. wenn Sie gerade über DirectorySync viele User in Office 365 synchronisiert haben und dann über PowerShell schnell Lizenzen zuweisen möchten. In der Oberfläche von Office 365 würde dies üben den Benutzerstandort erfolgen. In PowerShell verbinden wir uns zuerst mittels Connect-MsolService zum Online Services Modul. Im nächsten Schritt weisen wir allen Usern die Lokation Österreich zu: Get-MsolUser -All | Set-MsolUser -UsageLocation AT Hinweis: bei vielen Usern kann das schon eine Zeit lang dauern. Um herauszufinden, welche Lizenzen in diesem Tenant zur Verfügung stehen, fragen wir einmal mit Get-MsolAccountSku die aktuellen Lizenzen ab. Tipp: mit Get-MsolAccountSku | Format-Table AccountSkuId erhalten Sie eine Tabelle der Lizenzen. Um nun allen Benutzern die Lizenz A2 für Studenten zuzuweisen, benötigen Sie Get-MsolUser -All | Set-MsolUserLicense -AddLicenses your-tenant-name:STANDARDWOFFPACK_STUDENT Falls Sie jedoch selektieren wollen, z.B. sollen nur Benutzer mit einem UPN, der @edu.meineschule.com enthält, diese Lizenzen bekommen, lautet der Befehl so: Get-MsolUser -All | where {$_.UserPrincipalName -match "@edu.meineschule.com"} | Set-MsolUserLicense -AddLicenses your-tenant-name:STANDARDWOFFPACK_STUDENT Auch hier ein bisschen Geduld, bei vielen Usern kann das schon eine Weile dauern. Im Ergebnis sehen Sie dann, dass viele User Lizenzen zugewiesen haben. Sie sehen also, Massenoperationen mit PowerShell sind schnell erledigt!
Cloud | Office365 | PowerShell
mehr

Windows 8 mit nur einem Klick beenden-oder wie kann ich meinen PC abschalten?

Friday, January 11, 2013 9:04 AM Martina Grom
Eine häufige Frage von Benutzern, die mit Windows 8 zu arbeiten beginnen dreht sich weniger um die Funktionalitäten, wenn Windows läuft, sondern darum, wie man es herunterfahren kann. Für diejenigen, denen ALT+F4 oder Windows+I und Ein/Aus zu umständlich erscheinen, gibt es nun Abhilfe aus der TechNet Gallery. Mit Hilfe eines PowerShell Scripts können Sie nun eine Herunterfahren / Neustarten / Abmelden Kachel auf Ihre neue Benutzeroberfläche zaubern. Dazu laden sie zunächst das Script herunter. Danach entpacken Sie das Script und laden es: Import-Module c:\scripts\CreateWindowsTile.psm1 Mit dem Befehl Get-Help New-OSCWindowsTile -Full können Sie sich alle Optionen des PowerShell Modules anzeigen lassen. Um nun eine Kachel für herunterfahren, Abmelden und Neustart zu erzeugen, tippen Sie einfach New-OSCWindowsTile Viel Erfolg!
Microsoft | Windows | Tools | PowerShell
mehr

Wie die Anmeldung einer mit ADFS federierten Domäne für Office 365 geändert wird

Thursday, December 6, 2012 3:56 PM Martina Grom
In Office 365 sind Anmeldeinformationen flexibel lösbar: man kann eigene Identitäten in der Cloud betreiben, sein Active Directory mittels DirSync syncronisieren oder mittels ADFS Servern eine hybride Lösung mit SSO implementieren. Was passiert jedoch, wenn man eine hybride Lösung wieder auflösen möchte, bzw. diese "zurückbaut". Diesen Fall hatte ich unlängst in einem Projekt, wo der Kunde zwar DirSync und ADFS Server entfernte, jedoch in Office 365 die Information erhalten blieb, dass es sich um eine federierte Domain handelt und so jedesmal bei Anmeldung unter https://portal.microsoftonline.com mit der federierten Domain Office 365 den User zum nicht mehr existierenden ADFS Server schickte. Mittels PowerShell können Sie zunächst den Status Ihrer Domains abfragen, wie immer werden alle Befehle angegeben: $cred = Get-Credential Connect-MsolService -credential $cred Get-MsolDomain Nun erhalten Sie eine Aufstellung aller Domains und deren Status: Name Status Authentication contoso.com Verified Managed fabrikam.com Verified        Managed mydomain.com Verified Federated Sie sehen also, dass die Domain mydomain.com den Status Federated hat. Mit dem Befehl Get-MsolDomainFederationSettings -DomainName mydomain.com können Sie auch die Details der Federation abfragen. ActiveLogOnUri         : https://adfs.mydomain.com/adfs/services/trust/2005/usernamemixed FederationBrandName    : adfs.mydomain.com IssuerUri              : http://adfs.mydomain.com/adfs/services/trust LogOffUri              : https://adfs.mydomain.com/adfs/ls/ MetadataExchangeUri    : https://adfs.mydomain.com/adfs/services/trust/mex NextSigningCertificate : PassiveLogOnUri        : https://adfs.mydomain.com/adfs/ls/ SigningCertificate     : MIIC4j******13x0W5X2fA== Um nun die Domain von Federated zu Manged zu konvertieren, verwenden Sie Set-MSOLDomainAuthentication -Authentication Managed -DomainName mydomain.com Weitere Infos: KB2662960.
Cloud | Office365 | PowerShell
mehr

Microsoft Script Explorer for Windows PowerShell RC

Wednesday, August 15, 2012 9:15 AM Toni Pohl
Microsoft hat vor kurzem den Release Candidate des Microsoft Script Explorer for Windows PowerShell veröffentlicht (siehe PowerShell Scripts mit Script Explorer finden”). Der Script Explorer ist ein Tool zum Finden von PowerShell Scripts zu bestimmten Anforderungen und Themen - eine PowerShell-Suchmaschine!
Microsoft | Tools | Windows | SQL Server | PowerShell | SharePoint | Azure | Developer | Hyper-V | IIS | Office365
mehr

Lust auf PowerShell aus dem Web?

Wednesday, May 30, 2012 9:05 AM Toni Pohl
Kleine Tasks können mit PowerShell Scripts oft recht einfach durchgeführt werden. Vor allem gibt es in PowerShell Commandlets für ganz bestimmte Themen und Szenarien. Mit dem Wissen der richtigen Methode sind viele Aufgaben meist rasch erledigt. Ein fertiges WebService für PowerShell Scripts könnte machen Admin glücklich machen... das liefert Microsoft frei Haus mit dem Script Explorer Webservice!
General | Azure | Cloud | Developer | Microsoft | Tools | PowerShell
mehr