blog.atwork.at

news and infos about microsoft, technology, cloud and more

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

Microsoft Produkt-Updates im Sommer

Auch in der Sommerzeit gibt es eine Reihe an interessanten Updates und Neuerungen. Im Juli wurden unter anderem diese Microsoft-Produkte aktualisiert, hier ein kurzer Überblick. Windows 8.1 Enterprise Preview Version. Seit Ende Juli ist der Download der Windows 8.1 Enterprise Preview verfügbar. Im Windows Blog finden Sie die Neuerungen der Enterprise-Version beschrieben, darunter der neue Windows To Go Creator, die Start Screen Control, Neuerungen in DirectAccess und BranchCache und vieles mehr. Das Microsoft Assessment and Planning Toolkit (MAP) ermöglicht es, Ihre IT Infrastruktur zu inventarisieren und verschiedene Migrationen für die Plattformen Windows 8, Windows 7, Office 2010 und Office 365, Windows Server 2012 und Windows 2008 R2, SQL Server 2012, Hyper-V, Microsoft Private Cloud Fast Track und Windows Azure durchzuführen.     Das MAP Toolkit besteht aus dem Microsoft_Assessment_and_Planning_Toolkit_Setup.exe (inkludiert das Installation-Paket mit Tool und SQL LocalDB.), einer readme_en.htm (Voraussetzungen und Installation), dem MAP_Sample_Documents.zip (Beispiel-Reports) und dem MAP_Training_Kit.zip (Beispiel-Datenbank und Anleitungen mit verschiedenen Übungsszenarien). Hier geht's´ zum Download Microsoft Assessment and Planning Toolkit. UE-V 2.0 Beta: Mit User Experience Virtualization können Benutzer ihre gewohnten Apps und Einstellungen auf verschiedene Geräte verwenden. Die Beta unterstützt Windows 8 und Windows 8.1 Store-Apps und Line of Business Apps. Die verbesserte Synchronisation kümmert such um die Technik. Derzeit ist die Beta über Microsoft Connect beziehbar. Zuvor muss eine Umfrage beantwortet werden: Signup for User Experience Virtualization 2.0 Beta. App-V 5.0 SP2: Mit Microsoft Application Virtualization (App-V) können Applikationen virtuell ausgeliefert werden, genauso als wären sie lokal auf dem eigenen Computer installiert. Das Microsoft App-V Team Blog informiert in Betas for App-V 5.0 SP2 and UE-V 2.0 now available über die wesentlichen Neuerungen. Hier geht es zu den Application Virtualization Foren. Die Beta kann über Microsoft Connect und eine Umfrage bezogen werden: Sign up for Microsoft Application Virtualization 5.0 SP2 Beta Hinweis: UE-V 2.0 und App-V 5.0 SP2 werden als Teile der zukünftigen Version des Microsoft Desktop Optimization Pack (MDOP) ausgeliefert. Beide Produkte sind aber jetzt als eigene Beta-Versionen vorab testbar und unterstützen Windows 8.1 Preview. Bereits hier im Blog kurze beschrieben wurde die 3D-Visualisierung mit Bing Maps mit Power Map Preview for Excel 2013, das zuvor unter dem Codenamen "GeoFlow" bekannt war. Hier geht es zum Download. In Excel 2013 wurde auch Microsoft Power Query for Excel 2013 vorgestellt. Es ist ebenso ein Add-In für Self-Service Business Intelligence, das die Abfrage von Datenquellen ermöglicht und stark vereinfacht. Im Exchange Server 2013 RTM Cumulative Update 2 stecken einige Fixes seit dem letzten Cumulative Update 1 for Exchange Server 2013. Hier geht's zum Download des Cumulative Update 2 for Exchange Server 2013 (KB2859928). Ganz neu ist auch PowerShell 4.0 Preview, wir haben PS4 Preview hier im Blog bereits Anfang Juli kurz vorgestellt. Besonders für Web-Entwickler ist Internet Explorer 11 Developer Preview interessant, siehe auch unser Artikel in codefest.at. Last but not least der Hinweis auf den neuen Download von Windows Server 2012 R2 Preview, siehe auch Jetzt testen: Windows Server 2012 R2 Preview verfügbar hier im Blog. Viel Spaß mit Windows 8.1 Preview, Windows Server 2012 R2 Preview und den neuen Produkt-Updates!

PowerShell 4.0 Preview

Sommerzeit ist Urlaubszeit. Zeit zum Entspannen, Lesen und Neues ausprobieren, wozu man sonst kaum Zeit findet. Technikbegeisterte finden in dieser Zeit genügend spannende Themen, in die man sich vorab einlesen und Neues ausprobieren kann, wie zum Beispiel Windows PowerShell. PowerShell 4.0 Preview besitzt viele neue Funktionen und wird im Paket des Windows Management Framework 4.0 Preview installiert.

Office 365 Änderung der SMTP Proxyadressen bei einer Verteilerliste

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.

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

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

Wie Sie Benutzern in Office 365 den Standort und Lizenzen zuweisen

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!

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

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!

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

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.