atwork.blog

news and infos about microsoft, technology, cloud and more

DirSync und Proxy Einstellungen

Gerade in großen Umgebungen gibt es neben einigen Firewalls sehr oft natürlich auch HTTP / HTTPS Proxy Server die zur Sicherheit den Verkehr von Clients nach extern überprüfen sollen. Gerade wenn sie Dirsync im Einsatz haben kann das häufig zu Konfigurationsproblemen führen und führt zu einigen Verwirrungen. Das Problem? Ihr Dirsync Server steht im internen LAN und muss aber für die Synchronisation mit dem Azure Active Directory mit dem Internet kommunizieren. Der Firewall Mensch sagt aber "nein - verwendet den Proxy". Es gibt auch Konstellationen, wo das Default Gateway des Servers nicht der Weg ins Internet ist. Ich kenn das so jetzt eher selten, aber hatte zuletzt einen Kunden mit dieser Situation. Die fast Lösung? Normalerweise fangen Admins jetzt immer an wie wild mit Netsh, Proxy Policy oder dgl. rumzubasteln nur um festzustellen das die Firewall trotzdem alles ablehnt und der Proxy nur die Hälfte zu sehen bekommt. Die ganze Lösung? Man mag es kaum glauben, aber etwas versteckt hat DirSync die Möglichkeit bekommen einen Proxy für die Kommunikation nach außen zu setzen. Wichtig: es ist ein unauthenticated Proxy - ansonsten bitte die entsprechenden Ausnahmen setzen. Über die von DirSync mitgelieferte Coexistence-Configuration PSSnapins ist es möglich die aktuellen Proxyeinstellungen des Users auf den Service anzuwenden. Dafür einfach: Add-PSSnapin Coexistence-Configuration Update-MSOLDirSyncNetworkProxySetting ausführen und schon funktioniert das Ganze auch mit Proxy. Was ich leider nicht testen konnte - SSL Interception. Also sollte jemand hier Erfahrungswerte beisteuern können, jederzeit gerne. LG Christoph

Viel Lesestoff für den Sommer und danach-130 freie eBooks

  Microsoft stellt mittlerweile mehr als 130 eBooks zu technischen Themen kostenfrei zum Download zur Verfügung. Das Spektrum des Bücher-Angebots ist breit gefächert und reicht von Windows, Windows Server, Office, Dynamics, PowerShell, System Center, Lync, Azure, Programing, Windows Phone, Deployment, SharePoint, SQL Server, Data Mining, ASP.NET bis zu Virtualization und noch vieles mehr. Eric Ligman hat die Liste in seinem MSDN-Blog aktualisiert, hier ist sie: Largest collection of FREE Microsoft eBooks ever, including: Windows 8.1, Windows 8, Windows 7, Office 2013, Office 365, Office 2010, SharePoint 2013, Dynamics CRM, PowerShell, Exchange Server, Lync 2013, System Center, Azure, Cloud, SQL Server, and much more Alle eBooks sind in englischer Sprache. Die Downloads sind Fachbücher, Resource Guides und es sind auch einige Exoten dabei, wie Lync for Mac, Windows Accessibility, One Note Keyboard Shortcuts, How To Recover That Un-Saved Office Document, Own your space und natürlich Tonnen an Produkt-KnowHow. Viele Books stehen in mehreren Formaten bereit. Thanks Eric for this great collection! Viel Spaß mit den kostenfreien Microsoft eBooks!

Lizenzkosten sparen mit Shared Mailboxen in Office 365

Eine tolle Alternative zu Public Foldern sind sogenannte Shared Mailboxen in Office 365. Diese haben bis zu 10 GB Speicher, kosten jedoch keine Lizenz. Durch Berechtigungen können diese automatisch in Outlook eingebunden werden, können E-Mail Nachrichten empfangen und haben auch sonst viele Funktionalitäten eines Mailaccounts. Wenn Sie nun eine bereits vergebene Mailbox in eine shared Mailbox umwandeln wollen, geht das sehr einfach über PowerShell. Zunächst verbinden Sie sich zum Service: $UserCredential = Get-Credential $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection Import-PSSession $Session Get-MailboxStatistics <Alias> | FL Total* Set-Mailbox -Identity [Alias] -Type "Shared" -ProhibitSendReceiveQuota 10GB -ProhibitSendQuota 9.75GB -IssueWarningQuota 9.5GB Sobald das gesetzt ist, erscheint nach kurzer Zeit im Portal die Mailbox unter den geteilten Ressourcen. Danach können Sie die Lizenz von dieser Mailbox entfernen.

Eine Verteilerliste in Office 365 erstellen, die automatisch alle Mitglieder einer Abteilung enthält

Viele Unternehmen, die von Small Business Server Umgebungen auf Office 365 umstellen, sind es gewohnt, einen Verteiler zu haben, der automatisch an alle Mitglieder des Unternehmens versendet. Aber auch große Unternehmen wollen Verteilerlisten mit bestimmten Kriterien automatisch befüllt haben. Um dies in Exchange Online abzubilden, benötigt man eine Dynamische Verteilerliste.   In der Exchange Administrationskonsole kann man dann bequem eintragen, welche Kriterien die Verteilerliste haben soll und natürlich auch, welche Empfänger ausgewählt werden sollen. Hier kann man dann gleich einschränken, ob nur Mitglieder mit Exchange Postfächern, oder mit externen Mailadressen und vieles mehr selektiert werden sollen. Über Regeln können bereits in der GUI Filter gesetzt werden. Sobald diese Verteilerliste erstellt ist, funktioniert sie auch. Um jedoch zu sehen, welche Mitglieder in der Verteilerliste enthalten sind, verwende ich PowerShell. Ich habe dazu eine ganz einfache Verteilerliste erstellt, die an alle Benutzer mit Exchange Postfächern versendet, ohne weitere Filterkriterien. Zunächst verbindet man sich mit der ExchangeShell: $LiveCred = Get-Credential $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection Import-PSSession $Session Jetzt fragen wir unsere Verteilerliste ab: $all=Get-DynamicDistributionGroup "alle" Get-Recipient -RecipientPreviewFilter $all.recipientfilter Im Ergebnis sehen wir jetzt, dass wir alle UserMailboxen zurück bekommen, also auch Shared Mailboxen bzw. welche, die für Administratoren o.ä. eingesetzt werden. D.h. wir müssen die Dynamische Verteilerliste auf ein weiteres Kriterium einschränken. In meinem Fall habe ich den Firmenname im Feld Department gewählt. Set-DynamicDistributionGroup -identity alle@contoso.com -RecipientFilter {(RecipientType -eq 'UserMailbox') -and (Department -like 'Firma*')} Damit wird der Filter auf jene Personen eingeschränkt, die im Feld Department etwas eingetragen haben. Ein weiteres Beispiel wäre ein Filter auf alle Direktoren und/oder Manager: Set-DynamicDistributionGroup -Identitiy Manager@contoso.com -RecipientFilter {(RecipientType -eq 'UserMailbox') -and (Title -like 'Direktor*' -or Title -like 'Manager*')} Übrigens, Sie können dynamische Verteilerlisten auch gleich über die Shell erzeugen. In diesem Fall würden Sie diesen Befehl verwenden: New-DynamicDistributionGroup -Name "Manager" -RecipientFilter {(RecipientType -eq 'UserMailbox') -and (Title -like 'Direktor*' -or Title -like 'Manager*')} Viel Erfolg bei PowerShell!

RDP Zertifikat setzen mit Windows 2012 R2

Ein RDP Zertifikat setzen ist jetzt grad keine grosse Herausforderung. Gibts ja ein tolles Tool genannt tsconfig.msc - ruft man das auf, kann man auf den RDP Connection Settings einfach das Zertifikat einstellen. Ähm, nein. Unter Windows 2012 R2 gibts kein tsconfig.msc mehr. Gut - wir sagen jetzt mal, alles kein Problem, kann man alles per Policy ja auch konfigurieren. Da gibts einen wirklich guten Blog Eintragwie man das per Policy setzt sogar inklusive hauseigener CA Template Config damit das Ganze auch schön sicher ist. Supa Sache und würd ich jedem empfehlen im Prinzip sogar für alle Server. Das funktioniert natürlich auch für Windows Server 2012 R2. Aber - was, wenn Sie eine Terminal Services Farm mit Connection Broker inklusive IP Redirection konfigurieren wollen. Da ist es nämlich ohne einen Hardware Load Balancer einfach per DNS Round Robin möglich ein Load Balance zu erreichen. Das funktioniert auch recht gut einzig, man hat einen gemeinsamen Namen (like tsfarm.contoso.com) der per DNS auf mehrere Hosts geschickt wird. Verbindet sich der Client dorthin, löst er den Namen auf, verbindet sich auf den Host und ??? JA - bekommt eine Zertifikatsfehlermeldung. Wenn man per Policy wie oben angegeben das Zertifikat verteilt, wird automatisch vom Template der Servername (FQDN) ins Zertifikat als Subject eingetragen. Damit kann man sich per DNS Round Robin nicht auf einen gemeinsamen Namen verbinden. D.h. wir brauchen trotzdem ein Custom Certificate das jetzt leicht zu bekommen ist, aber schwer zu konfigurieren. Ich hab keine GUI gefunden, auch im Servermanager gibt es zwar für RDP Deployment eigene Wizards / Role Based Deployments, aber _dieses_ Zertifikat konnte ich nicht konfigurieren. Aber - es gibt für alles Lösungen und wie bei mir bekannt - meistens hilft ein Script weiter. $pass = ConvertTo-SecureString "PasswordFoThePFXFile" -AsPlainText -Force$thumbprint = (Import-PfxCertificate -Password $pass -CertStoreLocation cert:\localMachine\my -FilePath '\\server\share\certificatewithprivatekey.pfx').thumbprint $path = (Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").__path Set-WmiInstance -Path $path -argument @{SSLCertificateSHA1Hash="$Thumbprint"} Mit diesem kurzen Scripterl kann man ein Zertifikat einfach importieren und per WMI Command (natürlich auch per WBEMTest möglich) als Zertifikat für die TS Settings festlegen. Lustig - das war auch auf einer Diskussion ein Thema und man war der Meinung das Script geht nicht. Leider hat UAC da etwas reingespuckt, also - immer brav als Admin starten! LG Christoph