blog.atwork.at

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

Office 365 Dirsync Passwort Synchronisation

Monday, July 1, 2013 5:48 PM Christoph Wilfing
Gerade für kleine Unternehmen die trotzdem in den Genuss von Online Services kommen wollen gibt es jetzt eine interessante Erweiterung. Die neueste Version des Directory Synchronisation Tools kann jetzt auch Passwörter synchronisieren. Man fragt sich – wer braucht das schon. Aber die Frage lässt sich leicht beantworten!
Cloud | DirSync | Office365 | Windows
mehr

Office 365 Änderung der SMTP Proxyadressen bei einer Verteilerliste

Thursday, June 6, 2013 6:58 PM Martina Grom
Fast wäre es mir passiert und ich hätte dieses Thema ein drittes Mal in einem Blogartikel beschrieben: eine Domain will und will nicht aus Office 365 entfernt werden. Um eine Domain aus Office 365 zu entfernen, helfen diese beiden Artikel: Domain aus Office 365 per PowerShell entfernen (18.04.2013) Office 365 oder: wie entferne ich eine Domain aus dem Service (16.09.2011) Heute war ein Tenant jedoch besonders hartnäckig: obwohl bereits alle User geändert wurden, gelöschte Benutzer aus dem Papierkorb entfernt wurden, Verteilerlisten korrigiert wurden ließ sich die Domain trotzdem nicht entfernen. Dabei hatte ich doch schon "alles gemacht". Die Ursache war eine Mail-Enabled Sicherheitsgruppe, wo die Domain noch als Proxyadresse hinterlegt war. Mittels folgender Befehle melden Sie sich bei den Exchange Online Cmdlets an und setzen die Proxyadresse der Verteilerliste: $LiveCred = Get-Credential $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection Import-PSSession $Session -AllowClobber Set-DistributionGroup -Identity NAMEDERDL -EmailAddresses smtp:myname@contoso.onmicrosoft.com Nach kurzer Zeit erscheint dann der zweite Name nicht mehr in der Gruppenabfrage und Sie können die Domain entfernen. Wollen Sie das gleiche bei einer Person erreichen, bitte die Schritte wie hier beschrieben durchführen. Im wesentlichen funktioniert es genauso, nur ersetzen Sie das Set-Distributiongroup durch Set-Mailbox.
Cloud | Office365 | PowerShell
mehr

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

Office 365 Lizenzen mit PowerShell ändern

Friday, May 3, 2013 5:54 PM Martina Grom
Massenoperationen in Office 365 werden immer über PowerShell ausgeführt. Ich habe bereits vor einiger Zeit beschrieben, wie man vielen Benutzern auf einmal einen Standort und eine Lizenz zuweist. Bei den aktuellen Live@Edu Migrationen zu Office 365 erhalten alle Benutzer ja zunächst einmal jene Lizenz, die sie bereits vorher hatten: Exchange Online. Im A2 Plan von Office 365 sind jedoch auch SharePoint Online und Lync Online sowie die Office Web Apps für Studierende, Lehrer und Schüler kostenlos enthalten, deshalb sollte man den Studenten auch jene Lizenzen zuordnen, die Ihnen diese Rechte auch gibt. Nun ist es aber so, dass es ja unterschiedliche Account SKU's für Lehrer, Schüler und Alumnis gibt. Die Herausforderung liegt also darin, der Lizenzgruppe, die bisher Exchange Online Plan 1 für Schüler und Studenten hatten nun die Lizenzen Microsoft Office 365 Plan A2 für Studenten in einem Schritt zuzuweisen. In PowerShell verbinden wir uns zuerst mittels Connect-MsolService zum Online Services Modul. Um herauszufinden, welche Lizenzen in diesem Tenant zur Verfügung stehen, fragen wir einmal mit Get-MsolAccountSku die aktuellen Lizenzen ab. Um nun allen Benutzern die Lizenz A2 für Studenten zuzuweisen und gleichzeitig die Exchange P1 Lizenz zu entfernen, benötigen Sie Get-MsolUser -all | Where {$_.Licenses.AccountSkuId -contains "your-tenant-name:EXCHANGESTANDARD_STUDENT"} | Set-MsolUserLicense -AddLicenses "your-tenant-name:STANDARDWOFFPACK_STUDENT" -RemoveLicenses "your-tenant-name:EXCHANGESTANDARD_STUDENT" Falls Sie jedoch selektieren wollen, z.B. soll nur ein Benutzer mit einem bestimmten UPN diese Lizenzen bekommen, lautet der Befehl so: Get-MsolUser -UserPrincipalName admin@contoso.com | Where {$_.Licenses.AccountSkuId -contains "your-tenant-name:EXCHANGESTANDARD_STUDENT"} | Set-MsolUserLicense -AddLicenses "your-tenant-name:STANDARDWOFFPACK_STUDENT" -RemoveLicenses "your-tenant-name:EXCHANGESTANDARD_STUDENT" Bei vielen Usern kann dieser Vorgang schon eine Weile dauern. Achtung: bitte immer in einem Schritt eine Lizenz zuweisen und wegnehmen, da es sonst zu Nebeneffekten kommen kann.
Office365 | Cloud
mehr

OfficeApps entwickeln-Teil 6 Seller Dashboard mit Office 365 Abonnement verknüpfen

Friday, April 26, 2013 9:15 AM Toni Pohl
Wie in OfficeApps entwickeln-Teil 5 Wie bekommen ich meine App in den Office Store” beschrieben, werden Apps für Office und SharePoint 2013 im SellerDashboard in den Office Store von Microsoft eingestellt. Im SellerDashboard gibt es seit April eine Neuerung: Beim Hinzufügen einer neuen App prüft das Dashboard, ob mit dem verwendeten Microsoft Konto eine gültige Office 365-Lizenz verknüpft ist. Wie man diese verknüpft, zeigen wir hier.
App | Developer | Microsoft | Office | SharePoint | Office365
mehr

Domains aus Office 365 per Powershell entfernen

Monday, April 22, 2013 8:00 PM Martina Grom
Wer kennt das nicht? Es wird ein Office 365 Demoaccount geöffnet, Domains verifiziert und die Trial läuft dann ab. Das Account wird vergessen und nach einiger Zeit möchte man die Domain wieder in Office 365 hinzufügen. Office 365 wird sich beharrlich weigern mit dem Hinweis, dass diese schon hinzugefügt wurde. Wo ist sie bloß? In diesem Fall sind 2 Dinge extrem hilfreich: 1. ein gutes Gedächtnis (und sich an den domainname.onmicrosoft.com) erinnern oder 2. ein Partner mit Delegated Admin Rechten Erinnert man sich an seine onmicrosoft-Domain und kann sich anmelden, können die Domains wie weiter unten erklärt entfernt werden. Erinnert man sich nicht und man hat einen Partner mit Delegated Admin Rechten, kann dieser in seine Administration einsteigen und die "verlorenen" Domains suchen und entfernen. Ich kann es nur jedem Office 365 Benutzer immer wieder empfehlen: tragen Sie den Partner Ihres Vertrauens auch als Delegierten Administrator ein, das erspart Ihnen den einen oder anderen Supportanruf. Jeder Cloud Accelerated Partner kann dieses Service anbieten. Normalerweise entfernt man Domains über die Oberfläche: Domain anklicken und entfernen. Ist die Domain als Standarddomain eingetragen, muss diese zuerst unter den Firmendaten auf die *.onmicrosoft.com geändert werden. Zusätzlich müssen natürlich alle User und Gruppen ebenfalls entfernt werden. Doch was, wenn dies nicht geht, weil die Firmendaten nicht aufrufbar sind? Dann hilft - wie immer: PowerShell. Zuerst in das Service verbinden. Connect-MsolService Dann zunächst die Standarddomain neu setzen: Set-MsolDomain -Name contoso.onmicrosoft.com -IsDefault Und schon kann die Domain entfernt werden: Remove-MsolDomain -DomainName contoso.com Alles wieder gut. This is for you, Adis.
Cloud | Office365
mehr

Office 365-das passiert beim Wechsel von Office 365 zu Office 365

Monday, April 15, 2013 3:08 PM Martina Grom
Office 365 befindet sich derzeit ja wieder ein einer heißen Phase: alle Abonnenten werden von der "alten" Version - also jener Version, die auf den Servern 2010 basiert auf die neue Version (The new Office 365), die auf Servern 2013 basiert, umgestellt. Im Gegensatz zum letzten Umstieg, wo der Transition Einmaleins Artikel ebenfalls am 8. April entstanden ist läuft der Umstieg dieses Mal ohne wenig Umstellungsaufwand und vorbereitende Aufgaben der Administratoren ab. Trotzdem ergeben sich einige Fragen, deshalb hier einmal der Umstiegszyklus zusammengefasst inkl. einiger Tipps & Tricks, wie Sie sich vorbereiten können. Zunächst einmal: niemand muss sich vor dem Update fürchten! Ganz im Gegenteil, erhalten Sie jetzt alle neuen Funktionen der neuesten Serverprodukte und sind damit auf dem aktuellen Stand! Die Benachrichtigungen In den Benachrichtigungen erhalten Sie Informationen zur Umstellung. Sie erhalten je nach Tenant- und Clientkonfiguration 2-5 E-Mails. Manche sind auf Deutsch, andere sind auf Englisch, abhängig von Ihrer Tenanteinstellung. Wichtig ist, dass die Enduser keine Umstellungen machen müssen an ihren Clients oder den mobilen Endgeräten (sofern sie auf den aktuellen Versionen sind). 1. Mail mit Info zum Update 2. Mail etwa 20 Tage später mit Fertigstellung des Updates Benachrichtigungen bei kleinen Unternehmen: Benachrichtigungen bei großen Unternehmen: Zeitplan der Vorbereitung und nötige To Do's vor und während dem Upgrade Für die Vorbereitung Ihrer User sollten Sie diese mit der neuen Benutzeroberfläche vertraut machen und auf das Update hinweisen. Grundsätzlich empfehle ich, die MX Records zu überprüfen und gegebenenfalls anzupassen. Die Anpassung finden Sie im Administrationscenter unter den Domain Einstellungen, wo Sie die DNS Records abrufen können. Nach dem Update erhalten Sie gegebenenfalls weitere Informationen, je nachdem, wie Ihre Clientkonfiguration aussieht. Darunter fallen Informationen zu Mac Arbeitsstationen mit Entourage oder Office für Mac 2008, Informationen zu Windows XP. Informationen zu Office 2010 Updates, SharePoint Upgrade und Infos zum neuen Lync Client. Falls diese E-Mail nur Infos zur neuen Anmeldeseite enthält haben Sie schon alle erforderlichen Voraussetzungen. Hier ein paar Beispiele, wie Ihre E-Mail aussehen könnte: Nach dem Upgrade: Upgrade der Website für SharePoint Online Update des Lync Clients Upgrade der Office Version Und natürlich eine Feedback Mail: Tipps und Tricks zur Transition Wir haben bemerkt, dass die nochmalige Kontrolle und gegebenenfalls Anpassung der MX-Records Probleme bei der Umstellung vermeidet, insbesondere, wenn Sie Mailbox Weiterleitungen verwenden. Update der MX Records bei MX Record auf *.global.frontbridge.com Der Domain MX-Record ist bei Office 365 Benutzern so eingestellt: Derzeitiger Eintrag: contoso.at        MX preference = 0, mail exchanger = contoso-at.mail.eo.outlook.com Neuer Eintrag: contoso.at        MX preference = 0, mail exchanger = contoso-at.mail.protection.outlook.com Sollten Sie Ihr Outlook geöffnet haben, müssen Sie es schließen, damit die Änderungen der Mailbox wirksam werden. Wir haben beobachtet, dass manche Clients hier ein bisschen länger brauchen, um über Autodiscover ihre Mailbox zu finden. Hier bitte etwas Geduld (und vielleicht den Rechner neu starten, die MX Einträge kontrollieren und mal sehen, was Autodiscover im Client sagt). Das SharePoint Dienstupgrade führt dazu, dass auch die Office Web Apps aktualisiert werden. Bitte darauf achten, dass Sie Ihren Browser auf Internet Explorer 8 oder höher aktualisieren! Bei sehr stark angepassten SharePoint Online Seiten können noch weitere Anpassungen nötig sein, bitte dazu hier nachlesen. Nützliche Links Update der MX Records bei MX Record auf *.global.frontbridge.com Dienstupgradecenter für Unternehmen Neuigkeiten zur Outlook Web App Neuigkeiten zu Skydrive Pro Neuerungen zu Lync Online Neuerungen zu Webkonferenzen über den Browser Office 365 Dienstupdates für Unternehmen Aktualisierte Datenschutzoptionen für Administratoren Vorbereitungsemail für Endbenutzer Systemanforderungen Willkommens-Kit und Updateressourcen für kleine Unternehme (P-Plan) Office 365 Dienstupdatecenter für Unternehmen (E-Plan) Haben Sie sonst noch Fragen bzw. Probleme beim Update? Einfach hier in den Kommentaren hinterlassen, wir helfen gerne.
Cloud | Office365
mehr

OfficeApps entwickeln-Teil 4 SharePoint Authentifizierung verwenden

Thursday, April 4, 2013 9:05 AM Toni Pohl
Das Osterwochenende war mit dem Winterwetter perfekt geeignet, vorm PC zu sitzen und sich mit Lernen und Code zu befassen – wie Weihnachten, nur stand Osterjause statt Kekse auf dem Programm. Und natürlich Visual Studio, SharePoint 2013. Ein Thema, mit dem ich mich nach längerer Zeit wieder näher befasst habe, ist die Entwicklung von SharePoint 2013 Apps und zwar mit der dafür erforderlichen Authentifizierung.
ASP.NET | App | Developer | Microsoft | SharePoint | Office365
mehr

Wie Sie von Exchange Online Protection mit einem On-Premises Server zu Office 365 wechseln

Tuesday, April 2, 2013 7:29 PM Martina Grom
Exchange Online Protection ist das Antispam- und Antivirenservice von Microsoft, welches auch viele Kunden mit ihren On-Premises Exchange Servern verwenden. Das hat viele Vorteile, garantiert Exchange Online Protection (EOP, vormals FOPE, vormals EHS) ja 100% Mailvirenschutz und 98% Spamschutz. Lange Jahre begleitet mich dieses Produkt nun schon und egal wie es gerade heißt, es ist einfach immer noch sehr sehr gut. Wenn man jedoch seinen eigenen Mailserver (endlich) aufgibt und zu Office 365 wechselt, sind hierbei ein paar Schritte zu beachten. Zunächst einmal würde ich vorbereitend die TTL des MX Records bereits eine Woche vor dem Wechsel auf 5 Minuten stellen (oder 1 Minute). Den eigentlichen Umstellungszeitpunkt wähle ich dann immer entweder gegen Wochenende oder Abends oder an einem Feiertag, damit sicher gestellt ist, dass hier wenig Mailtraffic erfolgt. Dann im FOPE Administration Center anmelden und im Menüpunkt Verwaltung / Domänen die Domain deaktivieren die in Zukunft über Office 365 verwaltet wird. Danach wechseln Sie zum Punkt deaktivierte Domänen und löschen die Domain komplett aus FOPE . Ich warte dann immer rund 30 Minuten um sicher zu gehen, dass die Änderungen überall durchgeführt werden. (Keine Sorge, in dieser kurzen Zeit gehen Mails nicht sofort als unzustellbar zurück). Wenn Sie jetzt erst Ihr Office 365 Account eröffnen, können Sie in diesen 30 Minuten das Office 365 Abo kaufen und die Domain hinzufügen, validieren und die MX-Records ändern. Sobald diese validiert werden, haben Sie Office 365 und EOP im Einsatz! Wichtig: FOPE wird ab April 2013 in EOP integriert, bzw. die Services werden ab April konsolidiert. Für Administratoren bedeutet das, dass die Verwaltung einfacher wird, da damit auch EOP über https://portal.microsoftonline.com verwaltet werden kann. Für Kunden, die bereits Office 365 verwenden erfolgt die Umstellung im Rahmen der Transition zu Office 365 W15. Bei Kunden mit einem On-Premises Mailsystem erfolgt die Transition ab dem 3. Quartal 2013. Die FOPE Einstellungen werden automatisch in EOP auf Office 365 umgestellt. Alle Kunden erhalten mindestens 30 Tage vorher eine Info bezüglich der Transition.
Office365 | Microsoft | Security | Cloud
mehr