Mai 22

Deaktivieren der Gruppen Funktion in Office 365

Hallo zusammen,

lange habe ich nichts mehr geschrieben. Nun habe ich aber nochmal etwas zum runtertippen gefunden.

Seit dem erscheinen des Groups-Features in Office 365 war mir dies ein Dorn im Auge. Grade wenn man einen Exchange Hybrid Betrieb betreibt führt dies neben unterschiedlichen Adresslisten auch zu Verwirrung und Wildwuchs.

Groups

 

Als diese Funktion freigeschaltet wurde gab es leider keine Option (oder diese war noch nicht Dokumentiert) diese zu deaktivieren. Nun habe ich aber endlich eine Option gefunden.

Als erstes ist es notwendig, sich mit der Exchange Online Powershell zu verbinden.

$LiveCred = Get-Credential

 

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell
-Credential $LiveCred -Authentication Basic -AllowRedirection

 

Import-PSSession $Session

Wenn man sich nun die aktuelle OWA Mailbox Policy anzeigen lässt (get-owamailboxpolicy), gibt es dort einen Parameter der sich „GroupCreationEnabled“ nennt. Dieser sitzt per Default auf true. Somit sind in allen Policies die Erstellung von Gruppen freigeschaltet. Wenn man nun den folgenden Befehl ausführt wird dies Möglichkeit für die Default Policy auf False gesetzt und somit entfernt.

set-OwaMailboxPolicy -GroupCreationEnabled $false -Identity OwaMailboxPolicy-Default

Im Anschluß ist noch die Replizierung abzuwarten und es können dann keine neuen (Cloud-only) Gruppen mehr erstellt werden. Nun muss man sich nur noch für eine Lösung für den bisher stattgefundenen Wildwuchs einfallen lassen. 🙁

 

Aber gut. Dann allen Lesern ein schönes Wochenende.

 

Viele Grüße
Rolf Sayn

 

Aug 29

Update der Exchange Server Updates Liste

Hi zusammen,

nachdem diese Woche wieder Exchange Server Updates für die Versionen 2013, 2010 & 2007 erschienen sind, habe ich heute die Liste mit den Updates auf den aktuellen Stand gebracht.

Dort findet Ihr nun die Links zu den Downloads und den KB Artikeln für das CU6 für Exchange 2013,  das UR7 für Exchange 2010 SP3 und das UR14 für Exchange 2007 SP3.

Kleiner Hinweiß am Rande, mit dem CU6 für Exchange 2013 wurde die Anzahl der möglichen Öffentlichen Ordner wieder massiv erhöht.

Somit viel Spaß beim Updaten.

Viele Grüße

Rolf Sayn

Aug 12

Lizenzierung von Office365 Benutzern auf Basis von AD-Gruppenmitgliedschaft

Hallo zusammen,

heute Stand ich vor der Aufgabe, die Lizenzierung von Office365 Benutzern, auf Basis einer AD Gruppenmitgliedschaft durchzuführen. Es sollten zwei Lizenzoptionen (AccountSkuId) zugewiesen werden. Das Script fragt auch nach der zu Lizenzierenden Gruppe.

Die AccountSKUID kann man über das CMDlet „get-msolaccountsku“ erfahren.Diese setzt man dann in das folgende Script ein. Wichtig auch noch den Benutzernamen und das Passwort eines Office365 Admins mitzugeben. Dann kann man mit dem Script aber schon starten. (Alle Stellen die eine Anpassung erfordern, sind kursiv geschrieben.

 

__________________________________________________________________________________

Import-Module MSonline
$UsageLocation = „DE“
$User = „admin@contoso.com
$PWord = ConvertTo-SecureString –String „Passw0rd“ –AsPlainText -Force
$remcred=New-Object –TypeName System.Management.Automation.PSCredential –ArgumentList $User, $PWord
Connect-MsolService –credential $remcred

$Group = Read-Host „Enter the AD-Group Name which you want to license“

$GroupMembers = (Get-ADGroupMember -Identity $Group | % { get-aduser $_.samaccountname | select userprincipalname } )

$GroupMembers | ForEach-Object {
Try {
Set-MsolUser -UserPrincipalName $_.UserPrincipalName -UsageLocation $UsageLocation
Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -AddLicenses contoso:AccountSkuId1
Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -AddLicenses contoso:AccountSkuId2
Write-Output „Successfully licensed $_.UserPrincipalName“
}
catch {
Write-Warning „Error when licensing $_.UserPrincipalName“
}
}

_____________________________________________________________________________________

 

Viele Grüße

Rolf Sayn

Aug 06

Lync 2013 – Kumulatives Update 5 (August 2014) released

Hi zusammen,

heute wurde das Kumulative Update 5 für den Lync Server 2013 released.

Es wird mal wieder eine Lange Liste an Fehlern adressiert. Die komplette Liste ist wie immer im KB -Artikel zum Update zu finden –> Hier

Den Link zum Download für das CU5 gibt es wie immer hier.

Beim installieren ist wie immer an das Datenbank Update zu denken.

 

Viele Grüße

Rolf Sayn

Mai 28

Updates für Exchange 2013 und Exchange 2010

Hallo zusammen,

heute Nacht hat das Exchange Team das Cumulative Update 5 für Exchange 2013 freigegeben.

Eine Liste mit allen behobenen Problemen findet ihr beim KB Artikel zum Update. Des weiteren gibt es Neuigkeiten bei der Offline Addressbuch Verwaltung. Genaueres dazu findet man in diesem Blogeintrag von Ross Smith IV.

Ebenfalls wurde heute Nacht das Update Rollup 6 für Exchange Server 2010 SP3 released.

Auch hier gilt, eine Liste mit allen Fixes findet man im KB Artikel zum Update.

Die Downloadlinks und auch die Links zu den KB-Artikeln findet ihr natürlich auch noch mal auf meiner Seite für Exchange Server Updates.

 

Somit viel Spaß beim Updaten.

Viele Grüße

Rolf Sayn

Mai 24

Lync Server 2013 Front End Server auf Windows Server 2012 R2

Hallo zusammen,

 

in den letzten Wochen habe ich lange nach einer Lösung für ein Problem mit Lync Server 2013 auf Windows Server 2012 R2 gesucht. Ohne Frage, eine Supportete Installation seit dem Kumulativen Update Oktober 2013.

Das ganze äusserte sich augenscheinlich erst darin, das nach der Migration von Usern auf den neuen Lync Pool (mit Windows Server 2012 R2 als OS) die Adresslisten leer waren.

Nach genauerer Untersuchung fiel auf, das im Eventlog auf dem neuen Front End Server die Event IDs 32402 und 61045 protokolliert wurde. Nach eingehender Recherche fand ich folgenden KB Artikel im Technet: Event IDs 32402, 61045 are logged in Lync Server 2013 Front End servers that are installed in Windows Server 2012 R2

Dies passte also ziemlich genau auf die Problem die wir hatten. Es passte auch das wir den Unified Contact Store von Exchange 2013 in dieser Umgebung deaktiviert hatten.

Grund für das ganze ist eine Änderung in Windows Server 2012 R2 beim Umgang mit gecachten TLS Sitzungen.

 

Workaround dafür ist das setzen eines Registry Keys.

Unter:

HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel

ein neues D-Word (32-bit) erstellen mit dem Namen EnableSessionTicketund dieses mit dem Wert 2 versehen.

Im Anschluß die Lync Management Shell starten und stop-csWindowsService ausführen. Im direkten Anschluß dann mit start-csWindowsService die Lync Server Dienste wieder starten.

Im Prinzip kann diesen Registry Workaround also auf jeden Lync Frontend (bzw. auch Standard Edtion) Server nach der Installation ausführen.

 

Viele Grüße

Rolf Sayn

Apr 23

Exchange 2013 Wartungsmodus

Hallo zusammen,

heute gibts es mal wieder einen Eintrag über eine Neuerung in Exchange 2013 und zwar den Wartungsmodus( engl. Maintenance Mode). Für mich ein Feature welches lange überfällig war. Für die Installation von Updates im Cluster eine wirklich gute und hilfreiche Funktiondie sehr einfach zu handhaben ist.

Wie man genau beim aktivieren und deaktivieren des Wartungsmodus vorgeht, zeige ich anhand einer Exchange 2013 SP1 Aktualisierung.

Bevor man mit dem eigentlichen Setup starten kann muss man, im Falle dessen das ein UM Language Pack installiert ist, dieses erst entfernen. Hier zum Beispiel das deutsche UM-Language Pack.

Dies wird mit folgendem PS (Powershell) Befehl durchgeführt:

c:\Disks\exchange2013installationfiles\setup.exe /RemoveUMLanguagePack:de-DE

Ist die Deinstallation abgeschlossen beginnen die üblichen Schritte zur vorbereitung des Schemas, des Active Directories und der Domäne.

 C:\Disks\exchange2013sp1\Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

Wie immer wichtig, die Active Directory Replikation abzuwarten, da es sonst bei den nächsten Schritten zu Problemen kommen kann. Natürlich kannst man Replikation auch forcieren.

C:\Disks\exchange2013sp1\Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms

 

C:\Disks\exchange2013sp1\Setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms

Zwischen den beiden Schritten wieder Replikation abwarten bzw. überprüfen.

Nun ist es an der Zeit, den Server den man updaten möchte in den Maintenance Mode zu versetzen, damit dort keine aktiven Verbindungen mehr aufgebaut werden. Im ersten Step der HubTransport Dienst.

set-ServerComponentState $env:COMPUTERNAME -Component HubTransport -State Draining -Requester Maintenance

Direkt danacht teilen wir mit, dass der HubTransport Dienst bei ankommenden Anfragen mit einem Redirect antwortet und somit auf einen anderen Server verweist.

 

Redirect-Message -Server $env:COMPUTERNAME –Target exchange02.contoso.com

Ebenfalls wichtig, die Replikation der Datenbanken im DAG anzuhalten, da die Datenbanken auch dem Update unterliegen. Hier wird der Clusterknoten im DAG angehalten und alle Datenbanken sofort verschoben. Auch die automatische Aktivierung der Datenbankkopien wurde deaktiviert.

Suspend-ClusterNode $env:COMPUTERNAME

Set-MailboxServer $env:COMPUTERNAME -DatabaseCopyActivationDisabledAndMoveNow $True

 

Set-MailboxServer $env:COMPUTERNAME -DatabaseCopyAutoActivationPolicy Blocked

Nun ist es an der Zeit, den restlkchen Diensten mitzuteilen, dass keine Verbindungen mehr angenommen werden dürfen bzw. diese in den Maintanence Mode zu schalten.

Set-ServerComponentState $env:COMPUTERNAME -Component ServerWideOffline -State Inactive -Requester Maintenance

Nun kann man das eigentliche Update durchführen. Entweder, klassisch, per GUI oder per Powerhsell.

C:\Disks\exchange2013sp1\Setup.exe /m:Upgrade /IAcceptExchangeServerLicenseTerms

Wenn das Update dann nach geraumer Zeit abgeschlossen ist, sollte nun einen Reboot durchgeführt werden.

Nun heißt es, alle Dienste aus dem Maintenance holen und wieder alles in „Production“ setzen.

Set-ServerComponentState $env:COMPUTERNAME -Component ServerWideOffline -State Active -Requester Maintenance

Auch die Replikation der Datenbanken wird nun wieder gestartet und die Autoaktivierung der Datenbanken wieder eingeschaltet.

Resume-ClusterNode $env:COMPUTERNAMESet-MailboxServer $env:COMPUTERNAME -DatabaseCopyActivationDisabledAndMoveNow $False

 

Set-MailboxServer $env:COMPUTERNAME -DatabaseCopyAutoActivationPolicy Unrestricted

 

Nun nun noch den Transport Dienst wieder aus der Wartung nehmen.

Set-ServerComponentState $env:COMPUTERNAME -Component HubTransport -State Active -Requester Maintenance

 

Zum Abschluß nochüberpüfen ob alles wieder im Status „Active“ ist.

Get-ServerComponentState $env:COMPUTERNAME | Format-Table Component,State –Autosize

Alle Komponenten sollten “Active” als Status haben.

ComponentState

Jetzt noch schnell der Check ob der Clusternode auch wieder „UP“ ist.

´

Get-ClusterNode $env:COMPUTERNAME | Format-List

 

Clusternode

Somit fertig. Abschließend kann ich einen Reboot wärmstens empfehlen, da ich nun schon mehrfach das Problem hatte, dass der HubTransport Dienst nicht zuverlässig aus dem Wartungsmodus in den Betriebsmodus gewechselt hat. Dies kann man aber zuverlässig durch einen Reboot lösen.

Nun kann man noch das UM Language Pack wieder installieren. Und schon hat man seinen Exchange Server über den Wartungsmodus auf einen neuen Versionsstand angehoben.

Sollten noch Fragen zum Wartungsmodus offen sein, immer her damit.

 

Viele Grüße

 

Rolf Sayn

Mrz 26

Exchange 2013 SP1: MAPI over HTTP

exchange

 

Hallo zusammen,

 

seit der Veröffentlichung des Service Packs 1 (CU4) für Exchange 2013 steht auch der Outlook Anywhere (RPC/HTTP) „Nachfolger“ in den Startlöchern und ein den Exchange Admins bekannter Protokollname kehrt indirekt zurück. Seit der Einführung von Exchange 2013 wurde MAPI als direktes Protokoll zwischen Exchange und Outlook ja nicht mehr unterstützt und es konnte nur noch „Outlook Anywhere“ (RPC/HTTP) genutzt werden.

MAPI over HTTP hat ein paar entscheidende Vorteile gegenüber dem bei Outlook Anywhere verwendeten RPC over HTTP. Zum einen wird die Bindung an die Server RPC Schnittstelle gelöst. Nach meiner Erfahrung waren die RPC/HTTPS Verbindungen nicht immer so ganz Problemfrei. Zum anderen geht man damit wieder einen Schritt weiter zu einem Client Verbindungsprotokoll. Eigentlich alle Client Verbindungen laufen inzwischen per HTTPS (mal abgesehen von IMAP, SMTP & POP3). Dies macht nicht nur das Troubleshooting einfacher, sondern auch den Aufbau von großen Exchange Server Farmen mit Load Balancern und auch die Konfiguration der Load Balancer wird einfacher. Aber das bleibt auch nicht der einzige Benefit.

Das Wiederverbinden einer Outlook Connection geschieht innerhalb einer westenlich kürzeren Zeitspanne, da „nur“ eine HTTPS Verbindung hergestellt werden muss und keine RPC Verbindung. Dies betrifft unter anderem wechseln von LAN zu WLAN oder WWAN Verbindung und das „Aufwachen“ des PCs und Outlook aus dem Ruhezustand. Weiterhin wird eine Verbindung nicht mehr Abhängig von der Netzwerkgeschwindigkeit hergestellt, da diese Session basiert ist.

Allerdings ist MAPI over HTTP ausschließlich Outlook 2013 SP1 Clients vorbehalten. Bisher gibt es seitens Microsoft keine Aussage dazu ob dies Nachträglich auch noch für Outlook 2010 verfügbar gemacht wird. Somit funktioniert MAPI over HTTP aktuell nur zwischen Exchange Server 2013 SP1 und Outlook 2013 SP1 Clients. Outlook 2007 und Outlook 2010 müssen somit akutell erstmal weiter mit Outlook Anywhere arbeiten.

Per Default ist MAPI over HTTP übrigens nach der Installation des SP1 für Exchange Server 2013 nicht aktiviert. Dies muss mit ein paar simplen Befehlen per Powershell gemacht werden.

Im ersten Schritt muss das neue MAPI Virtual Directory konfiguriert werden.

Set-MapiVirtualDirectory -Identity „Mail\mapi (Default Web Site)“ -InternalUrl https://mail.sayn.local/mapi -ExternalUrl https://mail.sayn-web.de -IISAuthenticationMethods Negotiate

Auch hier ist natrülich wieder drauf zu achten, dass das Webserverzertifikat für den Exchange Server die entsprechenden Namen enthält.

Im direkten Anschluss kann man dann MAPI over HTTP für die komplette Organisation freischalten.

Set-OrganizationConfig -MapiHttpEnabled $true

An was man auch denken sollte, im Falle des Publishings bzw. des Einsatzes von Load Balancern, dass die Konfig eventuell angepasst werden muss. Grade beim Publishing muss man das Directory „/mapi“ nun mit in das Regelwerk aufnehmen.

Sobald nun der Outlook 2013 SP1 Client das nächste Mal erfolgreich, per Autodiscover, die Einstellungen abruft (auch hier ist Autodiscover wieder sehr wichtig und bei Exchange 2013 quasi unverzichtbar) erhält er auch die Informationen über die Möglichkeit sich per MAPI over HTTP zu Verbinden.

Ob die Verbindung mit dem Exchange per MAPI over HTTP einwandfrei funktioniert kann man hervorragend per Powershell testen. Dies geht ganz einfach mit folgendem Befehl.

Test-OutlookConnectivity -RunFromServerId SaynMail -ProbeIdentity OutlookMapiHttpSelfTestProbe

Alternativ gehts auch über den Outlook Verbindungsstatus. Dort müsste im Feld „Protokoll“ anstatt RPC/HTTP dann MAPI/HTTP stehen.

Wer dann testet wie schnell Outlook die Verbindung zum Exchange herstellt will nur ungern wieder auf RPC umsteigen. Also ich finde, dass sich MAPI over HTTP wirklich, als die bessere und schnellere Lösung etablieren wird.

Somit viel Spaß beim Implementieren von MAPI/HTTP mit Exchange 2013 SP1.

Nachtrag:

Für alle Exchange Server die nicht unter Windows Server 2012 R2 laufen, ist es erforderlich das .Net Framework 4.5.1 zu Installieren. Ohne dies kann MAPI over HTTP nicht sauber funktionieren. Nähere Informationen dazu im Technet Artikel unter Prerequisites.

 

 

Viele Grüße

 

Rolf Sayn

 

Mrz 21

Lync Hybrid mit Shared Domain Space

lync2013

Hallo zusammen,

 

die letzten Tage hatte ich bei einem Kunden das erste Mal eine Lync Hybrid Bereitstellung zu konfigurieren. Dabei galt es die SIP Domain für On-Premise und in der Cloud gleich zu halten.

 

Dabei bin ich direkt auf mehrere Schwierigkeiten gestoßen und eine ordentliche Anleitung wie man das ganze macht habe ich auch nicht gefunden, da im Technet ein entscheidender Punkt fehlt.

Aber nun gut.  Gestartet bin ich ganz normal mit dem folgenden Technet Artikel „Configuring an On-Premise Deployment for Hybrid with Lync Online

Der Tenant wurde bereits entsprechend konfiguriert (Vorteil: Beim gleichen Kunden habe ich bereits eine Exchange Hybrid Bereitstellung durchgeführt). Dementsprechend sind DNS Settings, Domain Verification, ADFS Implentierung und AzureAD Sync schon eingerichtet und funktionsfähig.

Also habe ich damit begonnen, auf dem Lync Server das Azure AD Powershell Module zu installieren.

Im nächsten Step habe ich dann die Access Edge Konfiguration durchgeführt wie im Technet beschrieben.

Set-CSAccessEdgeConfiguration -AllowOutsideUsers 1 -AllowFederatedUsers 1 -UseDnsSrvRouting

 

New-CSHostingProvider -Identity LyncOnline -ProxyFqdn „sipfed.online.lync.com“ -Enabled $true -EnabledSharedAddressSpace $true -HostsOCSUsers $true -VerificationLevel UseSourceVerification -IsLocal $false -AutodiscoverUrl https://webdir.online.lync.com/Autodiscover/AutodiscoverService.svc/root

Als nächstes habe ich dann das Lync Online Module für die Powershell installiert (Hier zu finden).

In der Folge sollte man sich nun auch wie folgt mit der Lync Online Powershell verbinden können. (Wichtig hierbei: Keine Lync Management Shell verwenden, sondern die Server Powershell und diese administrativ ausgeführt)

Import-Module LyncOnlineConnector

 

$cred = Get-Credential

 

$CSSession = New-CsOnlineSession -Credential $cred

 

Import-PSSession $CSSession -AllowClobber

 

Sollte es hierbei zu Verbindungsproblemen kommen, so dass sich nicht mit der Lync Online Powershell verbunden werden kann, kann es daran liegen das ein Proxy dazwischen steht. Dementsprechend machte es in meinem Fall hier Sinn, das der Server per https (443) direkt ohne Proxy ins Internet durfte. Danach funktionierte auch das Verbinden mit der Lync Online Powershell einwandfrei. Wer mehr sehen möchte dem lege ich beim Befehl

$CSSession = New-CsOnlineSession -Credential $cred -verbose

 

 

den Verbose Parameter ans Herz. Damit kann ich eher sehen in welcher Phase die Verbindung nicht zu stande kommt.

In meinem Fall kam noch ein weiterer Parameter zum Tragen, da alle Autodiscovereinträge auf die On-Premise Bereitstellung zeigen. Somit muss ich dafür sorgen das die Verbindung mit der „Onmicrosoft.com“ Domäne hergestellt wird. Übrigens gibts dazu auch einen KB Artikel.

$CSSession = New-CsOnlineSession -Credential $cred -verbose -OverrideAdminDomain „contoso.onmicrosoft.com“

Nachdem auch dies gelöst war konnte nun der Online Tenant für die Hybrid Bereitstellung konfiguriert werden. Dazu musste in der nun offenen Lync Online Powershell Session der folgende Befehl ausgeführt werden:

Set-CsTenantFederationConfiguration -SharedSipAddressSpace $true

 

 

 

Prinzipiell sind wir mit der Lync Online und Lync On-Premise Konfiguration jetzt fertig. Auch wenn es nach dem Technet geht sind keine weiteren Schritte mehr durchzuführen. Auch die Migration von Usern per Powershell kann nun erfolgreich, wie im Technet dargestellt, durchgeführt werden. Allerdings gibt es dort noch einen kleinen Haken.

Seit der Einführung der Office 2013 Server gibt es für die gegenseitige Authentifzierung OAuth. Das funktioniert nicht nur zwischen den On-Premise Servern sondern auch in die Cloud und ist hier Elementar wichtig. Als erstes muss der Lync On-Premise Server ein gültiges öffentliches Zertifikat besitzen dem vertraut wird.

Im folgenden muss noch ein Trust mit dem Office 365 Authorization Server und eine Trusted Application eingerichtet werden. Dies ist im Technet auch beschrieben, allerdings an einer ganz anderen Stelle –> Hier

Dabei musste ich hier in unserem Fall das folgende Script in der Lync Online Powershell noch ausführen.

$TenantID = (Get-CsTenant -Filter {DisplayName -eq „contoso.com“}).TenantId

$sts = Get-CsOAuthServer microsoft.sts -ErrorAction SilentlyContinue

if ($sts -eq $null)
{
New-CsOAuthServer microsoft.sts -MetadataUrl „https://accounts.accesscontrol.windows.net/$TenantId/metadata/json/1“
}
else
{
if ($sts.MetadataUrl -ne  „https://accounts.accesscontrol.windows.net/$TenantId/metadata/json/1“)
{
Remove-CsOAuthServer microsoft.sts
New-CsOAuthServer microsoft.sts -MetadataUrl „https://accounts.accesscontrol.windows.net/$TenantId/metadata/json/1“
}
}

$exch = Get-CsPartnerApplication microsoft.exchange -ErrorAction SilentlyContinue

if ($exch -eq $null)
{
New-CsPartnerApplication -Identity microsoft.exchange -ApplicationIdentifier 00000002-0000-0ff1-ce00-000000000000 -ApplicationTrustLevel Full -UseOAuthServer
}
else
{
if ($exch.ApplicationIdentifier -ne „00000002-0000-0ff1-ce00-000000000000“)
{
Remove-CsPartnerApplication microsoft.exchange
New-CsPartnerApplication -Identity microsoft.exchange -ApplicationIdentifier 00000002-0000-0ff1-ce00-000000000000 -ApplicationTrustLevel Full -UseOAuthServer
}
else
{
Set-CsPartnerApplication -Identity microsoft.exchange -ApplicationTrustLevel Full -UseOAuthServer
}
}

Set-CsOAuthConfiguration -ServiceName 00000004-0000-0ff1-ce00-000000000000

Und im direkten Anschluß daran funktionierte nun auch derautmatische Login mit den Clients in Lync Online, obwohl alle DNS Records für die Kundendomain, auf die On-Premise Server zeigen.

Wichtiger Nachtrag:

Damit die User sich aber auch ohne Probleme einloggen können ist es erforderlich, erst alle User für Lync in der On-Premise Bereitstellung zu aktivieren und im Anschluß in die Cloud zu verschieben.  Sonst endet die Client Anmeldung, am Edge Server, immer mit dem Fehler 403 Forbidden. Nicht vergessen, nach der Lync Aktivierung On-Premise, die Windows Azure AD Replikation abwarten!

 

Ich hoffe dies hilft dem ein oder anderen bei der zukünftigen Breitstellung einer Lync Hybrid Lösung.

 

Viele Grüße

 

Rolf Sayn

 

 

Feb 26

Exchange 2013 SP1 alias CU4 released

Hallo zusammen,

ebenfalls hat das Exchange Team, gestern abend, das Exchange 2013 SP1 (alias CU4) freigegeben.

Darin enthalten sind, neben vielen neuen Features, natürlich wieder auch die Bugfixes. Mehr zu den neuen Features in den nächsten Tagen. (Exchange 2013 Edge, Outlook Mapi-HTTP, uvm.)

Der offizielle Blogeintrag des Exchange Teams ist hier zu finden: Exchange Team Blog

Den Link zum KB Artikel und zum Download gibts hier: Exchange Server Updates

Übrigens wurde auch das SP1 für Office 2013 und für Sharepoint 2013 gestern freigegeben.

Viele Grüße

Rolf Sayn