Zomby blogja

Intune, Windows Licenc nélkül?

Windows Intune

Most olvastam a Server & Cloud Blog-on:

"but we will also make a version of Windows Intune available without rights to Windows Enterprise, thereby lowering the cost for organizations that are not ready to move to the latest operating system."

Elvileg lesz olyan Intune változat, ami nem tartalmazza a Windows Enterprise SA licencet! Ez nagy hír, a Windows Intune egy nagyon jó felügyeleti eszköz, de a Windows licenc miatt relatíve drága volt azoknak, ahol nem volt rá szükség.

 

Lync RTCUniversalGlobalReadOnlyGroup Warning

Felírom magamnak is, hogy később emlékezzek rá, frissítések után a Lync szerveren előfordul, hogy a Enable-CSTopology parancs hibával fut le:

Get Forest State

Warning: Ace DOMAIN\RTCUniversalGlobalReadOnlyGroup; Allow; ReadProperty; None; None

Warning: One or more group access control entries (ACEs) are not ready.

Ilyenkor a megoldás a Forest prep újra futtatása. Sajnos ez már csak PowerShellből fog menni, figyeljünk oda, hogy a megfelelő AD jogosultságokkal rendelkező felhasználóval futtassuk a Lync Server Management Shellből a következő parancsot:

Enable-CsAdForest

Windows 8 nyelv hozzáadása a meglévő telepítéshez

Már letölthető a Magyar nyelvi csomag, a következőképp lehet telepíteni.

  • Nyitni kell egy admin parancssort ( Win+X és A )
  • Ki kell adni a következő paranccsot:
    lpksetup
  • Adjuk meg a hu-hu könyvtárban lévő lp.cab fájlt a telepítőnek.

Természetesen az útvonalat ki kell cserélni az aktuálisra

Office 365 hibakeresés

A Microsoft készített egy saját magunk számára hasznos eszközt amivel a hibák nagy részét meg lehet oldani. Egyenlőre még csak angolul van, mindenképpen érdemes kipróbálni. A hibakerső eszköz az alábbi címen érhető el:

http://community.office365.com/en-us/tools/troubleshooting.aspx

Egy példa, ha pl. a levelek nem érkeznek meg:

 

Update: Még egy példa, ahova el lehet jutni az eszközzel. Mit tegyünk ha visszapattan a levél, hogyan lehet értelmezni:

http://community.office365.com/en-us/wikis/exchange/bounce-messages.aspx 

Windows 8 termékkulcs módosítás - Error 0x8007232B

Előfordulthat, hogy Windows 8 alatt termék kulcsot ( Product Key change ) kell módosítani, hogy telepíteni lehessen a Windows 8 Enterprise változatot. Alapból KMS-el akar működni, ezért az alábbi hibaüzenet:

Windows couldn’t be activated
Go to Control Panel to learn about other ways to activate.
Error code: 
Error description: DNS name does not exists.

A lépések a következők:

  • Win + X és utána A gomb ( Ez indít egy rendszergazdai parancssort )
  • Ha feljön az UAC, engedélyezzük
  • A paracssorba a következőt kell beírni:
     slmgr.vbs -ipk <termekkulcs>

Windows 8

Csak egy gyors jelzés, a Windows 8 letölthető az MSDN-ről.

Update: A fejlesztőknek letölthető egy 90 napos próba, egy gond van vele, hogy 90 nap után lejár és kész, nem lehet frissíteni.

http://msdn.microsoft.com/en-us/evalcenter/jj554510.aspx

Naptár megosztási engedélyek kezelése Powershell segítségével

Előfordul, hogy az ügyfelek csak Outlook Web Appot használnak az Office 365 eléréséhez. Ebben az esetben a naptár megosztásra csak az olvasást tudják beállítani, írási jogokat nem:

Az is lehet, hogy csak egyszerűsíteni szeretnénk az életünket és Powershell-ből szeretnénk megoldani a jogosultságok átállítását.

Az első lépés, hogy telepítjük a Powershell parancsmagot az Office 365-höz. Nem írom le, a helpben részletesen megtalálható:
http://onlinehelp.microsoft.com/office365-enterprises/hh124998.aspx 
http://help.outlook.com/hu-hu/140/cc546278.aspx 

Ezután lépjünk be adminisztrátorként a szolgáltatásba:

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

Ezután van hozzáférésünk az Exchange beállításaihoz.

Add-MailboxFolderPermission -Identity "FelhasznaloA:\Calendar" -AccessRights PublishingEditor -User FelhasznaloB

A FelhasznaloA naptárjára adtunk ezzel teljes jogot a FelhasznaloB-nek.

Pár megjegyzés

  • A lehetséges jogosultságok: Owner, PublishingEditor, Editor, PublishingAuthor, Author, NonEditingAuthor, Reviewer, Contributor, AvailabilityOnly, LimitedDetails 
  • Ha más nyelvet használ a FelhasznaloA, a naptár neve: "FelhasznaloA:\Naptár"
  • Tartományt nem kell megadni a felhasználóneveknél

 

Ugyanez Outlookból:

http://office.microsoft.com/hu-hu/outlook-help/a-naptar-adatainak-megosztasa-HA001230249.aspx 

Összefoglalás a jogokról:

Permission Description
Owner The Owner role gives full control of the folder. An Owner can create, modify, delete, and read folder items; create subfolders; and change permissions on the folder.
Publishing Editor The Publishing Editor role has all rights granted to an Owner, except the right to change permissions. A Publishing Editor can create, modify, delete, and read folder items and create subfolders.
Editor The Editor role has all rights granted to a Publishing Editor, except the right to create subfolders. An Editor can create, modify, delete, and read folder items.
Publishing Author A Publishing Author can create and read folder items and create subfolders but can modify and delete only folder items that he or she creates, not items created by other users.
Author An Author has all rights granted to a Publishing Author but cannot create subfolders. An Author can create and read folder items and modify and delete items that he or she creates.
Nonediting Author A Nonediting Author can create and read folder items but cannot modify or delete any items, including those that he or she creates.
Reviewer A Reviewer can read folder items but nothing else.
Contributor A Contributor can create only folder items and cannot read items.
None The None role has no access to the folder. 

Office 365 wave 15, Lync újdonságok

Office 365 customer preview

Ha valakihez esetleg nem jutott volna el a hír, lehet tesztelni az office 365 új verzióját és persze a hozzá tartozó Office-t is. Ugyanott lehet regisztrálni, ahonnan az Office 2013-at le lehet tölteni.

http://www.microsoft.com/office/preview/en

( Services for business / Office 365 Enterprise / Try It )

Egy tipp:

Azt javaslom regisztráljatok egy Office 365 előfizetést és onnan töltsétek le az Office 2013-t is. Az Office 2013 regisztrációnál az Office 365 előfizetést kell majd megadni ( Business ). Ez telepítéskor nem fog menni, itt csak lépjetek tovább és amikor már fel van telepítve az Office 2012, akkor lehet megadni a hozzáférést.

Pár újdonság a Lync-ből:

  • Skype federáció: Egyenlőre azonnali üzenetküldés, jelenlét és 1:1 audio megy. Jár hozzá majd 60 perc nemzetközi hívás a Skype accountra a Home Premiummal. A skype kapcsolatok felvehetők a Lync-be
  • VDI plugin: VDI és Remote Desktop alatt is lehet használni majd a Lync audio és videót úgy, hogy a helyi gépről hozza át őket.
  • Beszélgetés fülek: Több üzenetváltást, hívást és beszélgető szobát lehet kezelni egy ablakban
  • Lync Web App már támogatja a hangos és video kommunikációt. Akinek nincs Lync kliense ( pl. cégen kívüli ) részt vehet egy Lync konferencián egy kis böngésző plugin telepítése után
  • Lync Hybrid: Olyan mint eddig az Exchange Hibrid konfiguráció volt. Lehetnek felhasználók a felhőben akik a helyi Enterprise Voice-t használják kimenő hívásokra, hívhatják a helyi telefonközpont számait stb...
  • Mobil kliensek: végre lesz hanghívás
  • Lync TáblaPC-n: Láttam is nagyon jól néz ki és használható az új változat

WPC: Office 365 a partnerektől

Jelenleg zajlik Torontóban a Microsoft Worldwide Partner konferenciája, ahol én is a helyszínen vagyok. Az Office divízió vezetőjétől, Kurt DelBene-től kaptunk egy új bejelentést: A jövőben lehetséges lesz a partnereknek közvetlenül számláznia az Office 365-t az ügyfeleknek és a partnerek beépíthetik a szolgáltatás díját a szolgáltatásukba. A program neve: Office 365 Open program.

Ezen felül 23%-ot is el lehet majd érni az első évi visszatérítésnél a partnereknek.

A bejelentésné a DelBene mellett ült Steve Ballmer a MS vezetője, aki kiemelte, hogy dolgoznak már az Office 365 új szolgáltatásain, amelyeket egyszerűbb lesz a partnereknek és a ügyfeleknek bevezetni.

Delegált felügyelet, már essential partnereknek is!

Jó hír az essentials partnereknek: már számukra is elárhető a delegált felügyelet Június 12. napjától!

A delegált felügyelettel gyakorlatilag a saját hozzáférésetekkel tudjátok adminisztrálni az összes ügyelet.

Bővebben:

http://onlinehelp.microsoft.com/hu-hu/office365-partner01/gg243437.aspx 

Email cím hozzáadása terjesztési listához

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ömeges levélküldés a felhőből

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.

  • Microsoft Live@edu 500 címzett naponta
  • Office 365 szakemberek és kisvállalatok számára 500 címzett naponta
  • Office 365 nagyvállalatok számára 1500 címzett naponta

 

 

 É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.

Lync bejelentkezés

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:     

  1. Bekapcsoljuk a loggolást a Lync kliensben ( Eszközök/Beállítások/Általános/Naplózás bekapcsolása a Lync programban )
  2. Megpróbálunk a Lync-ben bejelentkezni
  3. Megnyitjuk a Snooper-el a %userprofile%\Tracing\Communicator-uccapi-0.uccapilog -t
  4. A messages fülön ezt látni:

   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. 

Árcsökkenés!

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:

http://blogs.office.com/b/microsoft_office_365_blog/archive/2012/03/14/new-lower-prices-for-office-365.aspx

BPOS -> Office 365 átállás, jelszavak

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?

A parancsok részletes leírása

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

Tartalom átvétel