Előfordul, hogy egy terjesztési listához hozzá kell adni egy új címet. Sajnos az Exchange kezelőpulton, csak megnézni lehet, de szerkeszteni nem. Két megoldás maradt:
- Powershell
- Kibővíteni az Exchange sémát és hozzáadni az Exchange Management Console-hoz.
A következő powershell paranccsal lehet hozzáadni egy új emailcímet egy meglévő disztribúciós csoporthoz:
Set-DistributionGroup -Identity Distribution_Group_Name -EmailAddresses ((Get-DistributionGroup Distribution_Group_Name).EmailAddresses += "newemail@contonso.com")
Ahol:
Distribution_Group_Name a terjesztési lista neve
newemail@contonso.com az email cím amit hozzá szeretnénk adni.
Az új email cím nem lesz az alapértelmezett, csak egy új alias.
Többször előfordult már a kérdés, hogy milyen korlátok között lehet leveleket küldeni a felhőből. A dokumentációban részletesen le vannak írva a limitek, itt csak megismétlem a benne foglaltakat. Mivel a szolgáltatások folyamatosan változnak ezért csak a jelenlegi ( 2012.04.06 ) állapotot tudom megosztani, később érdemes a szolgáltatási leírásokat megnézni, mert változhat:
Címzettekre és a feladókra vonatkozó korlátozások:
|
Korlátozás |
Érték |
|
Címzettek száma – a Címzett, Másolatot kap és Titkos másolat mezőkben megadható címzettek maximális száma. |
500 címzett |
|
Üzenetküldés gyakorisági korlátozása – egy levelezési ügyfélből egy perc alatt küldhető e-mail üzenetek maximális száma. A felhasználói fiók azonosítja az ügyfélprogramot. |
30 üzenet/perc |
|
Címzett gyakorisági korlátozása – egy felhőalapú postaládából 24 óra alatt küldött e-mailek címzettjeinek maximális száma. Miután elérte a korlátot, a rendszer nem tud üzenetet küldeni a postafiókból, amíg a korlát alá nem kerül azon címzettek száma, akiknek az elmúlt 24 órában küldött üzenetet. A címzettszám-korlátozás a szervezeten belüli és kívüli címzetteknek küldött üzenetekre vonatkozik. További információ: A tömeges e-mail és a napi címzettszám korlátozásai. |
|
Érdemes elolvasni "A tömeges e-mail és a napi címzettszám korlátozásai" című részt is a dokumentációban, részletesen le van írva az összes információ, példákkal demonstrálva.
Egy partnerünk ügyfelénél jelentkezett a probléma: Nem tudtak a felhasználók bejelentkezni a Lync Online -ba. Bármit próbáltak nem engedte be őket. Első körben kértem tőlük egy kliens logot. Ilyenkor be kell kapcsolni a loggolást a kliensben.
A következő eszközöket használtam az probléma analizálásához:
Az előbbi nem feltétlenül kell, a Lync kliens Communicator-uccapi-0.uccapilog néven a %userprofile%\Tracingkönyvtárba lerakja a debug log fájlt.
A példában egy felhasználó szerepel, aminek az Office 365 bejelentkezési neve keresztnev@zomputerkft.onmicrosoft.com , az elsodleges email cime: vezeteknev.keresztnev@zomputerkft.onmicrosoft.com ennek a későbbiekben még lesz jelentősége.
A lépések:
A téglalapok helyén a bejelentkezési név látszik.
401 Unauthorized. Ez azt jelenti, tudott a kliens csatlakozni a szerverhez, de nem engedi be, tehát a szerveroldalon van a "probléma". Még előtte megnéztem részletesen a logot (Open Notepad and Seek nevű gomb ). Tud kapcsolódni a szerverhez és kommunikálni ( nem az összeset idézem be, csak a lényeget:
QueryDNSSrv - DNS Name[_sip._tls.domain.hu] ( nincs utána query failed )
SECURE_SOCKET: security negotiation has completed successfully
A szerveroldal:
Azzal kezdtem, hogy a https://portal.microsoftonline.com oldalon megnéztem, hogy van-e Lync kliens licenc hozzárendelve a felhasználóhoz és rendben engedélyezve van-e. Itt nem találtam problémát.
A Lync alapesetben saját címet használ, ami a címtárban van eltárolva. Az Office 365 esetében azt történik, hogy az elsődleges SMTP címet másolja át egy folyamat SIP címmé a háttérben. Az SIP címet powershellel tudhatjuk meg egy felhasználóról:
Set-ExecutionPolicy RemoteSigned
$cred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $cred -Authentication Basic –AllowRedirection
Import-PSSession $Session
get-mailbox keresztnev@zomputerkft.onmicrosoft.com | fl Emailaddresses
A $Session kezdetű sor az -AllowRedirection-al ér véget, sajnos a blog motor így tördeli.
A SIP: résznél van megadva a Lync bejelentkezési név. Az SMTP: nagybetűvel az elsődleges email cím, ha minden jól meg ez szinkronizálódik automatikusan a SIP névre.
Tehát ebben az esetben a Lync kliensben az alábbiakat kell beállítani:
bejelentkezési cím: SIP: cím ( példában: vezeteknev.keresztnev@zomputerkft.onmicrosoft.com )
Felhasználónév: Felhasználónév az Office 365 portálon ( példában: keresztnev@zomputerkft.onmicrosoft.com )
Jelszó: az office 365 jelszó
A probléma az volt, hogy a belső sip név nem egyezik meg a bejelentkezési névvel, mert az elsődleges email cím különbözik az Office 365 bejelentkezési névtől. Általában ezt nem engedi a rendszer - nekem is powershellel kellett megerőszakolni - , de pl. BPOSban ezt még engedte és migrációkor nem változott meg.
Azt javaslom, hogy az ilyen jellegű problémák elkerülésére, hogy az Office 365 felhasználónév egyezzen meg a felhasználó elsődleges email címével. Ez nem csak ebben az esetben, de pl. Sigle Sign On esetén is különös jelentősége van. Persze lehet mást használni, de mindek dolgozzon feleslegesen az ember fia...
Lábjegyzet:
A SIP protokollról ( wikipedia ):
A Session Initiation Protocol (SIP) egy internet-kommunikációs protokoll két vagy több résztvevő közötti kommunikációs kapcsolat felépítésére. A protokollt pontosan az RFC 3261 (korábban RFC 2543) szabvány írja le. A protokoll egyre inkább szabványossá válik az Internet-telefóniában (VoIP használatában).
Ezt a protokoll-t használja a Lync kliens is kommunikációra a szerverrel, természetesen vannak benne egyedi részek, de a Lync szerver érti a SIP protokollt és tud is kommunikálni a Media Gateway-en keresztül más ilyen protokollt használó szerverekkel. Ez utóbbi egyébként még nem működik a Lync Online-al, ha fog akkor rá tudjuk majd kötni a telefont vonalunkat is a Lync-re.
Jó híreim vannak! Nem tudom mennyien vettétek észre vagy hallottatok róla, de március 14-től 20%-al csökkentek a közép és nagyvállalati ( E ) csomagok díjai:
A Microsoft már teljes gőzzel elkezdte a BPOS felhasználókat Office 365-re költöztetni. Az átállás során legfontosabb, hogy minden felhasználónak meg kell változtatnia a jelszavát az átállás ELŐTT (!). Ha nem így tesznek, lesz olyan aki nem tud belépni a rendszerbe akinek lejárt a jelszava. A legfonosabb, hogy az admin felhasználó jelszavát is meg kell változtatni. Annál nincs kellemetlenebb, ha nem tudtok belépni adminként és mivel hétfőn mindenki a supportot hívja aki elfelejtette, ezért a support segítségével a jelszó átírás nagyon sokáig is eltarthat! Szerencsére nekem ezt mások tapasztalatából sikerült megtanulni.
Egyérszt érdemes írni a felhasználóknak, hogy változtassák meg, másrészt le lehet ellenőrizni, hogy mindenki megváltoztatta-e a Get-MSOnlineUser Powershell parancs segítségével. Ha esetleg szeretnénk mi megváltoztatni egy felhasználó jelszavát, meg lehet tenni Set-MSOnlineUser paranccsal.
Hogyan lehet a ezeket a parancsokat kiadni?
Fontos: az eszközből a legfrissebb változattal láthatjuk a jelszóról az információt, de nem lehet csak frissíteni az előző változatot, előbb le kell szedni az előzőt. Részletes információ
Azt a változatot kell letölteni az eszközből, amelyik ugyanolyan mint az office a gépen ( 32 vagy 64 bit )
Frissítés:
Példa powershell parancs, azoknak a felhasználóknak a listája, akik 30 napnál régebben változtatták meg a jelszavukat:
Get-MSOnlineUser -Credential $Cred -enabled | where {$_.PasswordLastSetDate –lt [datetime]::now.adddays(-30)} | ft Identity, PasswordLastSetDate
Másik példa, akik nem változtatták meg 30 napja a jelszavukat, mi változtassuk meg nekik Valtoztassmeg. -ra:
Get-MSOnlineUser -Credential $Cred -enabled | where {$_.PasswordLastSetDate –lt [datetime]::now.adddays(-30)} | Set-MSOnlineUserPassword -Password "Valtoztassmeg." –Credential $Cred –ChangePasswordOnNextLogon $true
A héten az MVP Summit-on vagyok kinn Redmondban, így közvetlenül lehetőség nyílt a Microsoft csapattal találkozni.
Az egyik ügyfélnél érdekes kérdés merült fel. Beleszámít-e a limitekbe a Sharepoint saját helyek mérete. Alapesetben úgy gondoltam igen, de az Office 365 csapattól azt az információt kaptam, hogy nem számít bele a quotákba!
megj.: A Sharepoint saját hely a felhasználók külön személyes webtárhelye. Gyakorlatilag egy kis személyes sharepoint, ahova dokutentumokat lehet feltölteni, megosztani, naptárat, feladatlistákat, blogot készíteni. Egyszerűbbé teszi a cég többi részével való kapcsolattartást, információ megosztást.
Ha az ADFS-t be szeretnénk állítani, powershell-t kell használni. Ahhoz, hogy a powershell megtalálja az ADFS 2.0 szervert, meg kell adni neki az ADFS szerver nevét:
Set-MsolAdfscontext -Computer adfs.cegnev.local
Ha nem az ADFS szerveren futtatjuk a powershellt, akkor van erre szükség. ( Pl. Windows 2008-on fut az ADFS) Az ADFS szerveren alapból nincs a WinRM beállítva, hogy fogadja a távoli kéréseket, ezért az alábbi hibaüzenetet kapjuk:
Set-MsolADFSContext : The connection to adfs.cegnev.local Active Directory Federation Services 2.0 server failed due to invalid credentials.
Ebben az esetben engedélyezni kell a távoli WinRM hozzáférést (admin jogosultsággal):
winrm quickconfig
Nem sokára készülünk az első áttérésre BPOS-ról, Office 365-re a tapasztalatokat egy későbbi postban majd leírom.
Ami a kinti MVP-k talpasztalata alapján látszik, hogy a legtöbb gond a jelszó változtatással van. Fontos, hogy senkinek a jelszava ne járjon le, főleg a rendszergazdai (!), különben hétfőn a túlterhelt amerikai helpdesk, csak nagyon lassan tud reagálni, akár napokig eltarthat egy jelszó módosítás.
Fontos tehát, hogy felhívjuk a felhasználók figyelmét a jelszó módosításra, még az áttérés előtt. Összeszedtem a jelszó módosításához szükséges információkat:
Segítség a jelszó változtatásához:
http://www.microsoft.com/online/help/hu-hu/helphowto/b0003c05-eecb-427c-b9ee-139ed00861f7.htm
A jelszó megváltoztatása Mac rendszerű számítógép esetén:
http://www.microsoft.com/online/help/hu-hu/helphowto/cabbee88-3610-40b8-a2df-d0f0956180bb.htm
A jelszót a vállalati portál webhelyen is módosíthatjátok. A jelszónak a Vállalati portál webhelyen történő módosításához kattintsatok a Jelszó módosítása hivatkozásra a lap jobb felső sarkában. Ekkor haladéktalanul jelentkezzetek ki a Bejelentkezési alkalmazás alkalmazásból, majd jelentkezzetek be újra az új jelszó használatával.
A vállalati portál címe: https://home.emea.microsoftonline.com
Most kaptam a tippet, hogy készült egy igényes tervezési útmutató a Sharepoint Onlinehoz. Első ránézésre jónak tűnik, főleg azoknak, akik még nem használták a Sharepoint-ot fejleszői szemmel, viszont szeretnék jól kihasználni a lehetőségeket az ügyfeleknél.
Segít a bevezetésben és útmutatást ad, hogyan vezessük be a Sharepoint-t.
A dokumentáció magyar nyelven itt elérhető.
Van egy wiki új oldal, ahol összegyűjti a Microsoft az office 365 frissítéseit és újdonságait. Érdemes nézni, mert egy helyre összegyűjtve, máshol nehezen található meg ez az információ.
http://community.office365.com/en-us/w/office_365_service_updates/default.aspx
Pl. nekem is újdonság volt, hogy decembertől lehet Lync Online találkozót, már a webről is kezdeményezni:
részletes ismertető:
Megjelent a Lync mobil kliens, végre!
Szerveroldalon van szükség változtatásra, ha helyi szerverünk van, dióhéjban telepíteni kell a CU4 frissítést, telepíteni/beállítani a Mobility és Autodiscover szolgáltatásokat, beállítani milyen portokon figyeljenek, változtatni a külső valamint belső tanúsítványotkat és végül a reverse proxy-t beállítani.
Szerencsére Office 365-el egyszerűbb a helyzet:
- P csomag esetén, nincs teendő itt automatikusan beállítódik, ha az Office 365 a DNS szerver
- E csomagnál, ha saját domaint használunk: Fel kell venni a DNS szerverbe egy lyncdiscover.domain.hu CNAME rekordot, ami a webdir.online.lync.com-ra kell, hogy mutasson.
- E csomagnál, ha *.onmicrosoft.com domaint használunk: A Lync mobil kliensben a bejelentkezésnél ki kell kapcsolni az "Auto-detect services"-t és az "External Discover URL"-t a https://meet.lync.com/Autodiscover/autodiscoverservice.svc/Root címre kell beállítani
Egy jó hír: A Microsoft kiadott egy új sign in klienst, amely már figyelmeztet a jelszó változtatásra, 2 nappal a lejárat előtt. Ha eddig valaki csak OWA-t használt, neki jelzett az OWA, de pl. Outlook 2010 nem jelzett.
Alapból 90 naponta lejár a jelszó.
Az új kliens letölthető az Office 365 portálról.
Megjelent, lehet tölteni a béta változatú modult az SBS essentials szerverhez ami az Office 365-ös kapcsolódást segíti elő. A blogon le vannak írva a tulajdonságai mint például az Office 365-t már innen is elő lehet fizetni vagy a hálózati fiókjainkból egyszerűen tudunk Office 365 fiókokat csinálni. Mégis amit kiemelnék az, hogy lehetővé teszi a jelszó szinkronizációt a helyi szerver és az Office 365 között.
Egy ügyfélnél üzemeltük be a Lync-et és elkezdték használni a konferencia szolgáltatást is. A Lync Attendee kliens való arra, hogy akinek nincs Lync kliense, hozzá tudjon kapcsolódni egy konferenciához, amit egy cégen belülről - ahol van Lync infrastruktúra - indítottunk. Tipikusan egy külső cég, ahhonnan hozzá szeretnének a konferenciához csatlakozni. Az Attendee kliens felhasználói (user level) változatának telepítéséhez nincs szükség rendszergazdai jogra.
Az ügyfélnél jelezték, hogy nem működik az egyik partnerüktől a csatlakozás és nagyon fontos lenne.
Alapesetben a Lync Attendee közvetlenül próbál kapcsolódni, ha ez nem sikerül az IE proxy beállításait használja és úgy csatlakozik. Ebben az esetben azért nem működött, mert a proxy authentikációt használtak a partnernél és ez nem támogatott. A kerülő megoldás az lett, hogy kivételt kellett definiálni a proxy szerverben: a sip.microsoft.com címre ne kérjen a proxy authentikációt.
Ismét egy jó hír: Az egyszeri bejelentkezés használata esetén, eddig minden UPN végződéshez külön ADFS szerver(farm) volt szükséges, ami több UPN végződést használó cégnél jelentős plusz költség lehetett. Mostantól elég egy szerver(farm):
Multiple Issuer Support
Previously, Microsoft Office 365 customers who require single sign-on (SSO) by using AD FS 2.0 and use multiple top level domains for users' user principal name (UPN) suffixes within their organization (for example, @contoso.us or @contoso.de) are required to deploy a separate instance of AD FS 2.0 Federation Service for each suffix. After you install this Update Rollup on all the AD FS 2.0 federation servers in the farm and follow the instructions of using this feature with Office 365, new claim rules will be set to dynamically generate token issuer IDs based on the UPN suffixes of the Office 365 users. As a result, you do not have to set up multiple instances of AD FS 2.0 federation server to support SSO for multiple top level domains in Office 365.
|
A ZOMPUTER vezetője vagyok, rendszermérnök, a kezdetektől, 2009 óta foglalkozom a Microsoft felhőszolgáltatásaival. Több száz ügyfélnél összesen több mint 50 ezer felhasználó felhős bevezetésében vettem részt a világ 25 országában. Rendszeresen tartok felhős előadásokat a partnereknek. 2010 óta vagyok Office 365 MVP, amely címmel a világon 3.-ként tüntettek ki. |
