Predavanje, koje se je kao i obično moglo pratiti putem MS Live Meeting-a, je bilo ciljano ka budućim administratorima sustava, s posebnim naglaskom na upravljanje identitetima u oblaku i interno. Također, bilo je nešto malo riječi o migraciji korisnika iz on-prem sustava u cloud.

Da ne duljim, trial verziju pronađite na www.office365.com, a MS LiveMeeting snimku predavanja pogledajte u filmiću ispod

Hvala Marinu Frankoviću za konverziju i upload videa

U prikazanom videu pratimo tri scenarija. Ayla koja je na poslovnom putu u Johannesburgu, Shannon, Aylina kći koja rješava zadaću i Quina u Hong Kongu.

Više o viziji možete pročitati na www.microsoft.com/office/vision, a do tad, uživajte u videu!

U zadnjih mjesec dana, ekipa iz MS Exchange tima nas je uveselila s nekoliko zanimljivih dokumenata.

Prvi od njih koje bi istaknuo dokument koji opisuje MS Exhange protokole koji se koriste za komunikaciju s drugim proizvodima, kao i dodatke na industrijske standarde protokola koji su implementirani u Exchange-u. Poveznica na dokumentaciju se nalazi ovdje.

Idući set dokumeata opisuje protokole i standarde koji su podržani od strane Exchange-a i Outlook-a, te njihovu korelaciju s industrijskim standardima, odnosno RFC dokumentacijom. Poveznica se nalazi ovdje.

Za kraj, dokumentacija koja opisuje promjene u Active Directory shemi koja se primijenjuje prilikom proširenja za potrebe instalacije određene iteracije Exchange sustava. Tako su opisane promjene od Exchange 2003 verzije do Exchange 2010 SP2 verzije. Poveznica na navedenu dokumentaciju se nalazi ovdje.

Predavanja će se odvijati u tri smjera i to poslovni smjer, razvojni smjer i ITPro smjer. Predavači su kao i dosadašnjih godina renomirani stručnjaci i Microsoft MVP-jevi iz Hrvatske, Bosne i Hercegovine, Engleske i Njemačke.

Organizatori su osigurali poseban popust za kotizaciju članovima Microsoft Community zajednice od 40%, za prijave do 13.9.2011. pa požurite! Puna cijena kotizacije je 700 Kn + PDV. Također, do 13.9.2011. traje “early bid” s 30% popusta na cijenu kotizacije.

Više o samoj konferenciji možete saznati na www.mobilityday.com

CARNet svojim članicama nudi prilagođenu Linux distribuciju koji dečki održavaju i kreiraju za potrebe visokoškolskih ustanova. Što one nude? Paaaa… Osnovnu funkcionalnost – mail i podršku za AAI @ EduHr. I to je skoro pa sve…

AAI @ EduHr je izuzetno koristan studentima i mi ga koristimo za različite servise i aplikacije interno, ali studenti ih koriste i za ostale pogodnosti, napose jeftiniji pristup Internetu, bilo preko žice ili bez iste.

Mail? Pa, to je malo drugi par rukava. Out of the box se dobiva rudimentalna e-mail funkcionalnost. Sjećam se kad sam ja još bio na faxu, kad se je koristio PINE za čitanje maila, nakon nekog vremena smo dobili webmail… Squirell se je zvao i bio je pravo otkrivenje… Covjece, pristupas mailu preko Web preglednika i ne moras se spajati terminalom! To je bilo otkrivenje… Prije jednog desetljeća, plus minus… I guess what? Taj isti webmail je u ovom CARNetovom paketu. Jup, možete ga sami zamijeniti s nekim drugim rješenjem koje ćete samostalno održavati i upravljati njime. Ali, svi koji me znaju, znaju i moje mišljenje i pogled na Linux filozofiju, a bome i činjenicu da bi znao upisati “ls” u shell – i tu bi stao

No, da li postoji neka alternativa svemu ovom? Pa, postoji, dobra je i besplatna i zove se MS Live @ EDU.

Live @ EDU je usluga namijenjena obrazovnim ustanovama i vrlo je slicna onome sto dobivate s klasicnim Live računom… Ali, ima toga još…

Ja sam ovu uslugu otkrio prije dvije godine, ako se ne varam i postala mi je izuzetno zanimljiva. Naime, po meni glavna prednost usluge je mail sustav, upravo ovaj koji me je najviše smetao u CARNet implementaciji. Naime, kod Live @ EDU-a je mail sustav baziran na Exchange-u… Može li čovjek poželjeti bolje? Gotovo sve funkcionalnosti čiste Exchange implementacije su dostupne i u Live @ EDU-u.To znači da je, pogotovo meni, administracija uvelike olakšana, a doživljaj samih korisnika je doveden na profesionalnu razinu – onakvu kakva se koristi u poslovnim okruženjima.

Osim samog maila, i Exchange-a, s Live @ EDU-om korisnici dobivaju i druge Live funkcionalnosti, poput Sykdrive-a, Live Messanger-a, Live Mesha i ostalih Live usluga.

No, kako rekoh, ipak postoji benefit za obrazovne ustanove. Korisnici dobivaju mailbox veličine 10 GB! Korisnici dobivaju SkyDrive veličine 25 GB! Imaju Office Live! To je nešto što obični, klasični Live useri nemaju!

Implementacija Live @ EDU u Algebra obrazovnoj grupi

Tamo negdje, prije godinu i pol – dvije smo bili u fazi reorganizacije poslovanja, internih, eksternih servisa i usluga, prvotno smo odlučili na Live @ EDU migrirati Algebru. Interno koristimo MS Exchange, no kako ja volim razdvajati internu, sterilnu okolinu, od vanjske, odlučili smo da naše predavače nećemo smjestiti na naš interni Exchange sustav. Nakon razmatranja opcija, odluka je pala da će se predavači smjestiti na Live @ EDU, razdvojeni u posebnoj SMTP domeni, pošto nam je mail sustav bio primarni razlog migracije i razdvajanja.

Pokrenuo sam postupak prijave za Live @ EDU, koji je poprilično jednostavan, u obliku čarobnjaka s osnovnim pitanjima o ustanovi, nakon čega je uslijedlo vrijeme potrebno za validaciju, odnosno ajmo reči, dokazivanje da imamo pravo na korištenje usluge. Naravno, kako smo edukacijska ustanova, odnsono grupa, proces je bio relativno brzo gotov. Live @ EDU nije namijenjen samo studentima/polaznicima, već i zaposlenicima i suradnicima, tako da nije bilo razloga zašto uslugu ne iskoristiti.

Idući korak je bio kreiranje domene u sutavu, podešavanje odgovarajućih DNS zapisa i otvaranje korisnika, distribucijskih grupa i po želji prilagodba sučelja. Ovdje moram pohvaliti MS ekipu jer je cijeli sustav, cijeli produkt ili skup produkata uključenih u Live @ EDU iznimno dobro dokumentiran i objašnjen, nije bilo nikakvih problema prilikom otvaranja. Često puta sam se do sad zapitao da li bi sustavom mogao upravljati netko tko nema administrativnog iskustva, netko tko ne zna što je MX zapis i slično i uvijek sam zaključio – bi! Zaista, izuzetno puno objašnjenja, čarobnjaka, uputa, video uputa koje krajnjem korisniku omogućavaju jednostavan rad.

Naravno, meni se iskreno nije dalo otvarati nekoliko stotina korisničkih računa ručno, nego sam za tu priču iskoristio CSV uvoz podataka, kojime mi je bilo omogućeno jednostavno otvaranje potrebnih korisničkih računa.

Jedini zadatak nakon toga je bio informirati korisnike o promjenama, o načinu pristupa svojem korisničkim računu. Tu nije bilo nekih prevelikih problema, što me je iskreno začudilo. Bilo je nekoliko postavljenih pitanja, ali večina ljudi se je snašla u uputama i pronašla ono što su tražili, a to je bili primarno kako konfigurirati neku od mail aplikacija za korištenje. Čak se je i onim tvrdokornim Apple ili Linux korisnicima stvar svidjela jer webmail (OWA) radi uredno s IE-om, Firefoxom i Safariem. Korisnici su osim toga dobili i push mail, putem Exchange ActiveSync tehnologije, tako da su mailove mogli primati na svojim mobitelima bilo putem EAS-a ili putem klasičnog POP3/IMAP4 pristupa.

Nakon toga je uslijedio završni touch, odnosno brendiranje samog sustava, postavljanje custom linkova i sustav je bio u upotrebi, u punom pogonu.

Ono što me je tad iznenadilo je činjenica da je Live @ EDU radio na novim verzijama Exchange-a, tako da su korisnici imali OWA-u tek koja je službeno kasnije predstavljena.

I stvar je radila!

Visoka škola za primijenjeno računarstvo i Live @ EDU

Nakon što smo prebacili Algebru na sustav, naravno, počelo se je nametati pitanje, a zašto ne bi i VŠPR? He, zašto?

Ako se sjetite onog Linuxa s početka priče, e upravo je on razlog… Naime, naravno nikome nije cilj tjerati ljude, studente, profesore, kolege da imaju jedno korisničko ime za Infoeduku, forum i ostalo (u stvari njihov AAI @ EduHr identitet), te drugo za pristup mailu, odnosno Live @ EDU sustavu.

U tom trenutku sam počeo tražiti načine kako to objedinit. Live @ EDU se može sinkronizirati s lokalnim AD-om, korištenjem alata OlSync, odnosno Outlook Live Directory Sync. Super, odlično, ali ja nemam AD sa korisničkim podacima, nego imam AAI @ EduHr. E, to ne ide…

Super! Ajmo dalje gledati… Da li neki lokalni AD mogu sinkati s AAI @ EduHr-om? Mooooggguuuu, ali…

Testirao sam bio cijelu priču, AAI @ EduHr se sinka s lokalnim AD-om, koji se sinka s Live @ EDU-om. Stvar ide, ali… Ne znam da li ste kao admin ikad imali feeling, onaj feeling, da kad nesto upogonite, da ipak nesto tu onak, ne stima. Mene je strah, bilo tad a strah me je i danas kad pogledam to dvostruko sinkanje da nest bu puklo, da se neće odraditi kako spada, da će se krivo sinkati i šta ja znam. Da, to je feeling samo, ali, it just aint feelin’ right! Jednostavno, previše je točaka prekida u cijeloj priči i odustadoh od toga.

No, kako ćemo onda? Ne iskoristiti ovako predobru stvar samo zbog mog feeling-a? Nakon razgovora s Dekanom i Upravnim vijećem je odlučeno kako ćemo ipak implementirati Live @ EDU, ali s ručnim sinkom podataka. Naravno, navedeno je zahtjevalo određene promjene u samom Infoeduka sustavu (sustav digitalne referade), što znači developerski posao, što znači čekanje jer ovo nije prioritet. Ali, dočekao sam taj developerski posao i čekao samo pogodan trenutak za migraciju.

Migracija je planirana ovog ljeta. Naravno, večina ljudi je na godišnjem, predavanja, ispiti i sve studentske, ali i profesorske i asistentske ljepote su završile i bacio sam se na posao.

Sam VŠPR je otvoren prije podosta vremena u sustavu i koristila ga je nekolicina entuzijasta studenata i profeosra za testiranje i otkrivanja blagodati samog sustava, što je značilo da je taj inicijalni korak odrađen davno u prošlosti i trebalo je napraviti korak naprijed.

Na internom forumu VŠPR-a sam upitao studente kakav žele username, da li u obliku koji sad imaju (iprezime, npr. ipavlekovic – smells like Linux, right?) ili ime.prezime. Iako je pobijedio oblik ime.prezime (hehe…), ipak na kraju sam se odlučio za Linux like koji ljudi već koriste… Zašto? Pa jednostavno je – naučili su na to, zašto im kreirati još jedan username koji moraju pamtiti.

Isčupani su podaci o korisnicima (Ime, Prezime, username, lozinka) iz Infoeduke i prebačeni u Excel. Odlično. Sad je od Excela bilo potrebno napraviti CSV koji prima sam Live @ EDU. Naime, podržan je import korisnika iz CSV datoteke, što sam već prije bio iskoristio i za Algebru. Sam format datoteke je izuzetno prilagodljiv (treba čitati upute) i ja sam napravio ovako:

FirstName,LastName,Name,Password,Username,EmailAddress,alias,DisplayName,Company
Pero,Perić,pperic,Z@p0rk@,pperic,pperic@racunarstvo.hr,pperic,Pero Perić @ Računarstvo,Visoka škola za primijenjeno računarstvo

Svih 300-ak korisnika je bilo u toj CSV datoteci i import je mogao početi. Sveukupno je trajao nekih 15-ak minuta, te je u navedenom periodu otvoren Live ID za svakog korisnika, otvoren korisnički mailbox i napravljen provisioning Live usluga za korisnika. Cool! Prvi korak gotov.

No, dobio sam to da mi korisnici nemaju primarnu e-mail adresu oblika ime.prezime@racunarstvo.hr, nego iprezime@racunarstvo.hr, a bome nije bilo ni aliasa za ime.prezime@racunarstvo.hr… Brrrrr… Previše podsjeća na Linux! Moram to promijeniti! Kako, a ne! Ručno!

Yea, right! Sva sreća da znam ponešto o Exchange-u, te sva sreća da Live @ EDU može koristiti EMS (Exchange Management Shell). Nije mi trebalo puno vremena za napraviti skriptu, koja će proletjeti po drugoj CSV datoteci koja je sadržavala username korisnika i njegov alias u obliku željene e-mail adrese.

To je izgledalo nekako od prilike ovako:

- CSV datoteka:

Username,EmailAddress_Alias,alias
pperic@racunarstvo.hr,pero.peric@racunarstvo.hr

- EMS skripta

import-CSV aliasi.csv | for-each { set-mailbox –identity $_.Username –WindowsEmailAddress $_.EmailAddress_Alias }

U skripti sam iskoristio parametar WindowsEmailAddress koji se prema dokumentaciji ne koristi od strane Exchange-a, ali mi je koristio jer je postavio primarnu SMTP adresu na oblik iz CSV datoteke, a ostavio je i alias stare mail adrese.

Migracija mailboxa

Zadnji korak u migraciji je bio seljenje mailboxa sa starog sustava na Live @ EDU. Naravno, i tu je MS olakšao stvari i omogućio uvoz korisničkih mailboxa s različitih mail sustava. Podržane su MS Exchange verzije 2003 naviše ili IMAP4 import podataka.

Kako smo mi prije imali Linuxoidni mail sustav, naravno import je rađen korištenjem IMAP4 protokola.

Kao i kod svakog drugog importa, potrebno je napraviti CSV datoteku u kojoj su sadržani username i password korisnika na starom sustavu, te e-mail adresa na novom sustavu.

Primjer CSV datoteke koju sam ja koristio je:

EmailAddress,UserName,Password
pperic@racunarstvo.hr,pperic,L0z1nk@

Migraciju je moguće poreknuti bilo preko EMS-a ili preko ECP (Exchange Control Panel). Ja sam odabrao ovu drugu opciju, naravno Pokreće se čarobnjak u nekoliko koraka, gdje je potrebno specificirati parametre ishodišnog poslužitelja (naziv ili IP adresu, te port), nakon čega se radi provjera spajanja, i po potrebi odabir mapa koje neće biti uključene u uvoz. U idućem koraku se odabire CSV datoteka s korisnicima i import može početi!

Iz mog primjera je vidljivo kako sam ja imao datoteku sa svim korisničkim podacima (uključujući i lozinku), a MS je u dokumentaciji pripremio primjere konfiguracije IMAP4 sustava, ukoliko nemate lozinke korisnika, za najčešće IMAP4 sustave.

Sam proces importa je dosta zanimljiv. Čovjek bi očekivao kako će se import napraviti jednom i gotova priča. No, nije tako… Import je proces koji će inicijalno napraviti uvoz podataka iz korisničkih ishodišnih sandučića, te će svakih 24h ponovno provjeravati i uvoziti promjene. Poprilično cool stvar. Također, ukoliko kod inicijalnog uvoza sustav naiđe na problem, grešku to će vam javiti. Tog korisnika neće uvesti u proceduru, nego vi, naknadno njega možete dodati i on ulazi u import proces.

Taj import proces može trajati koliko god vama paše, a korisnicima će uvoziti svaka 24 sata podatke sa starog mail sutava. To je i više nego dovoljno za promjenu svih parametara, poput DNS promjena (MX, SRV i TXT) i slično. Kad ste spremni, potrebno je okončati proces uvoza, čime će Live @ EDU poslijednji put napraviti uvoz podataka sa starog sustava.

Tako sam i ja napravio… Nakon toga su korisnici imali sve svoje mailove iz starog sutava, te su studenti, predavači, djelatnici i suradnici bili migrirani na Live @ EDU sustav, koristeći sve blagodati koje sustav svojim korisnicima pruža.

Ostaje za napraviti

Sustav je upogonjen i radi, ali volio bi to još malo upicaniti… Volio bi omogućiti studentima Singe Sign-on, tako da se oni prijave u sustav digitalne referade, te tamo imaju link na e-mail koji će im automatski otvoriti njihov Live @ EDU poštanski sandučić. No, taj proces uključuje dva developerska tima koji su full zauzeti, tako da nisam siguran koliko ćemo brzo ovo obistiniti. A nešto sam načuo, da će se sutudenti na Live @ EDU moći autenticirati s AAI @ EduHr identitetom, ali otom potom…

Iako je sama filozofija implementirana vec u MS Outlook 2003, u potpunosti je zazivjela upravo s MS Exchange 2007 i MS Outlook 2007 sustavima.

Što u stvari omogućuje Autodiscover?

To je tehnologija ili skup njih koji krajnjem korisniku omogućuju automatsku konfiguraciju korisničkog računa Exchange sustava.U idealnom poslovnom svijetu, korisnik na domenskom računalu, prijavljen sa svojim domenskim podacima pokreće prvi puta MS Outlook koji će se automatski konfigurirati za rad s MS Exchange-om. Upravo je ova funkcionalnost implementirana u MS Outlook 2003 koji je konfiguracijske podatke pročitao iz Active Directory-a i na taj način konfigurirao Outlook bez intervencije i potrebe korisnika ili administratora. No, isti taj Outlook 2003 je donio novu mogućnost korištenja tehnologije Outlook Anywhere (odnosno, tad poznatog RPC over HTTP/S proxy-a) koji je omogućavao korisnicima koji nisu spojeni na domensku mrežu, bez potrebe VPN-a rad s Outlook-om, odnsno Exchange sustavom. Isto tako, sve više i više su se počele koristiti tehnologije mobilnog pristupa poštanskom sandučiću gdje je korisnik samostalno morao konfigurirati postavke svog Exchange računa. I to je sve normalno funkcioniralo do trenutka promijene konfiguracije korisničkog Exchange računa. Korisnik, ako nije bio spojen u domensku mrežu s računalom koje je član domene, morao je svu konfiguraciju ponovno napraviti,

Same tehnologije ne MAPI pristupa korisničkom mailboxu (EAS – Exchange Active Sync i RPC over HTTP/S) su uzimale sve više i više poklonika i korisnika, te je s MS Exhange 2007 predstavljen novi koncept autokonfiguracije korisničkih postavki. Naravno, novopredstavljeni Autodiscover je primarno EWS (Exchange Web Service) funkcionalnost, ali zbog potrebe koegzistencije sa starim klijentima (Outlook 2003 i raniji) je zadržana funkcionalnost otkrivanja postavki putem Active Directory-a. Klijenti MS Outlook 2007 i ostali kompatibilni klijenti će, između ostalog pokušati pronaći konfiguraciju spajanjem na EWS Autodiscover gdje će pronaći odgovarajuću konfiguraciju. To omogućuje EAS i Outlook Anywhere klijentima također transparentnu automatsku promjenu konfiguracije klijenta u slučaju potebe kad se promijeni konfiguracija samog Exchange sustava.

Kako radi Autodiscover?

Pošto je Autodiscover funkcionalnost dio CAS uloge (Client Access Server), ona je u stvari virtualni direktorij u IIS-u na CAS serveru.

Postoje dva scenarija korištenja Autodiscovera:

• Računala koja su članovi domene (domain member computer) – Outlook 2007 i viši
1. Nakon pokretanja Outlooka, on će kontaktirati AD i dohvatiti SCP (Service Connection Point). SCP sadrži dvije informacije serviceBindingInformation koji sadrži URL CAS servera s Autodiscover informacijama (npr. https://CAS1.igorp.local/autodiscover/autodiscover.xml), te keywords koji sadrži AD Site kojem SCP pripada, a to je najčešće i AD Site samog CAS servera
2. Outlook će kontaktirati dobiveni URL i dohvatiti XML datoteku s konfiguracijom koju će nakon toga primijeniti istu na korisnički e-mail profil
• Računala koja nisu članovi domene – Outlook 2007 i viši, EAS uređaji
1. Nakon pokretanja aplikacije, ona će pokušati kontaktirati AD za pretragom SCP-a koji neće postojati. Aplikacija tad pokušava na četiri načina dohvatiti postavke, kontaktirajući domenu SMTP e-mail adrese koju je korisnik specificirao (u primjeru nazivdomene.com)
• POST metodom na https://nazivdomene.com/Autodiscover/Autodiscover.xml
• POST metodom na https://autodiscover.nazivdomene.com/Autodiscover/Autodiscover.xml
• GET metodom na http://autodiscover.nazivdomene.com/Autodiscover/Autodiscover.xml
• pretragom SRV zapisa u DNS-u _autodiscover._tcp.nazivdomene.com. Navedeni rezultat će vratiti FQDN servera na kojem se nalazi Autodiscover, te će aplikacija pokušati napraviti POST metodu na dobiveni FQDN (npr. https://mail.nazivdomene.com/Autodiscover/Autodiscover.xml)
2. Ukoliko jedna od četiri metode pretrage bude uspješna, aplikacija će primijeniti dobivene postavke na e-mail profil korisnika

Naravno, za ispravno funkcioniranje Autodiscovera, korisničko računalo/uređaj mora vjerovati certifikatu koji je konfiguriran na IIS-u CAS servera, kako bi se uspješno mogao konfigurirati. Također, digitalni certifikati moraju sadržavati puni FQDN servera na kojem se nalazi Autodiscover postavka.

Nakon kontaktiranja Autodiscover EAS servisa, aplikacija prima XML datoteku s odgovarajućom konfiguracijom.

Primjer Autodiscover XML datoteke Outlook klijenta:

<?xml version="1.0"?>
<Autodiscover xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<User>
<DisplayName>Igor Pavlekovic</DisplayName>
<LegacyDN>/o=IgorpNET/ou=First Administrative Group/cn=Recipients/cn=igor</LegacyDN>
<DeploymentId>ad7d3192-fdaa-4859-b97b-13c0ad0fb614</DeploymentId>
</User>
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<Protocol>
<Type>EXCH</Type>
<Server>exchange.igorp.local</Server>
<ServerDN>/o=IgorpNET/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=exchange</ServerDN>
<ServerVersion>738180DA</ServerVersion>
<MdbDN>/o=IgorpNET/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=Exchange/cn=Microsoft Private MDB</MdbDN>
<ASUrl>https://exchange.igorp.local/EWS/Exchange.asmx</ASUrl>
<OOFUrl>https://exchange.igorp.local/EWS/Exchange.asmx</OOFUrl>
<OABUrl>http://exchange.igorp.local/OAB/5ab89ff6-c0a0-4d68-bc9c-a02e87944e21/</OABUrl>
<UMUrl>https://exchange.igorp.local/EWS/UM2007Legacy.asmx</UMUrl>
<Port>0</Port>
<DirectoryPort>0</DirectoryPort>
<ReferralPort>0</ReferralPort>
<CertPrincipalName>msstd:ext-exchange.igorp.net</CertPrincipalName>
<PublicFolderServer>exchange.igorp.local</PublicFolderServer>
<AD>DC.igorp.local</AD>
<EwsUrl>https://exchange.igorp.local/EWS/Exchange.asmx</EwsUrl>
<EcpUrl>https://exchange.igorp.local/ecp/</EcpUrl>
<EcpUrl-um>?p=customize/voicemail.aspx&amp;exsvurl=1</EcpUrl-um>
<EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1</EcpUrl-aggr>
<EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;</EcpUrl-mt>
<EcpUrl-ret>?p=organize/retentionpolicytags.slab&amp;exsvurl=1</EcpUrl-ret>
<EcpUrl-sms>?p=sms/textmessaging.slab&amp;exsvurl=1</EcpUrl-sms>
</Protocol>
<Protocol>
<Type>EXPR</Type>
<Server>ext-exchange.igorp.net</Server>
<ASUrl>https://ext-exchange.igorp.net/EWS/Exchange.asmx</ASUrl>
<OOFUrl>https://ext-exchange.igorp.net/EWS/Exchange.asmx</OOFUrl>
<OABUrl>https://ext-exchange.igorp.net/OAB/5ab89ff6-c0a0-4d68-bc9c-a02e87944e21/</OABUrl>
<UMUrl>https://ext-exchange.igorp.net/EWS/UM2007Legacy.asmx</UMUrl>
<Port>0</Port>
<DirectoryPort>0</DirectoryPort>
<ReferralPort>0</ReferralPort>
<SSL>On</SSL>
<AuthPackage>Basic</AuthPackage>
<CertPrincipalName>msstd:ext-exchange.igorp.net</CertPrincipalName>
<EwsUrl>https://ext-exchange.igorp.net/EWS/Exchange.asmx</EwsUrl>
</Protocol>
<Protocol>
<Type>WEB</Type>
<Port>0</Port>
<DirectoryPort>0</DirectoryPort>
<ReferralPort>0</ReferralPort>
<Internal>
<OWAUrl AuthenticationMethod="Basic, Fba">https://exchange.igorp.local/owa/</OWAUrl>
<OWAUrl AuthenticationMethod="Basic, Fba">https://webmail.igorp.net/owa/</OWAUrl>
<Protocol>
<Type>EXCH</Type>
<ASUrl>https://exchange.igorp.local/EWS/Exchange.asmx</ASUrl>
</Protocol>
</Internal>
</Protocol>
</Account>
</Response>
</Autodiscover>

Primjer Autodiscover XML datoteke EAS klijenta:

<?xml version="1.0"?>
<Autodiscover xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/mobilesync/responseschema/2006">
<Culture>en:us</Culture>
<User>
<DisplayName>Igor Pavlekovic</DisplayName>
<EMailAddress>igor@igorp.net</EMailAddress>
</User>
<Action>
<Settings>
<Server>
<Type>MobileSync</Type>
<Url>https://ext-exchange.igorp.net/Microsoft-Server-ActiveSync</Url>
<Name>https://ext-exchange.igorp.net/Microsoft-Server-ActiveSync</Name>
</Server>
</Settings>
</Action>
</Response>
</Autodiscover>

Kao što je vidljivo iz dva gornja primjera, aplikacija dobiva čitav set konfiguracijskih parametara za pristup korisničkom mailboxu, ali i ostalim EWS servisima (OWA, ECP, VoiceMailbox i sl.).

Aplikacije koje koriste Autodiscover funkcionalnost će primijenjivati i provjeravati Autodiscover postavke i to:

• Prilikom kreiranja novog e-mail profila u Outlook-u
• Periodički kako bi provjerili za promjene, kao i prilikom pokretanja aplikacije
• Ukoliko se promijeni mrežna veza

Konfiguracija Autodiscover funkcionalnosti

U večini situacija, nakon same instalacije Exchange sustava biti će potrebno jednostavno konfiguriranje Autodiscover servisa. To podrazumijeva:

1. Konfigurirati vanjske nazive, odnosno FQDN-ove koji se koriste za pristup različitim Exchange servisima putem odgovarajućeg čarobnjaka ili cmdleta za:
• Outlook Anywhere
• Offline Address Book (OAB)
• Unified Messaging
• Exchane Web Services
2. Konfiguraciju SSL certifikata s odgovarajućim nazivima za pristup. Za pristup iz interne domenske mreže, SSL certifikat mora imati FQDN CAS servera u svojim postavkama. Za pristup iz ostalih mreža, SSL certifikat mora imati ili naziv domene u svom nazivu ili autodiscover.nazivdomene.com u svom nazivu.
3. Potrebno je za klijente iz ne-domenske mreže omogućiti HTTPS ili HTTP pristup CAS serveru. Navedeno se najčešće izvodi metodom Reverse HTTP/S proxy-a, što je jednostavno moguće korištenjem MS TMG-a koji u sebi već ima pripremljene čarobnjake za objavu Autodiscover servisa
4. U internom DNS sustavu je potrebno provjeriti da li postoji zapis za FQDN CAS Exchange servera na kojem se nalazi Autodiscover servis. U vanjskom DNS sustavu je potrebno konfigurirati, ovisno o odabranom načinu objave Autodiscovera jedan ili više od navedenih zapisa:
• HOST A zapis nazivdomene.com koji upućuje na IP adresu na kojoj je dostupan Exchange CAS
• HOST A zapis autodiscover.nazivdomene.com koji upućuje na IP adresu na kojoj je dostupan Exchange CAS
• SRV zapis
• Service: _autodiscover
• Protocol: _tcp
• Port Number: 443
• Host: FQDN servera na kojem je dostupan Exchange CAS

Ovime je osnovna funkcionalnost konfiguracije završena, te i interni i vanjski klijenti mogu koristiti Autodiscover funkcionalnost. Ista se može testirati na dva načina:

1. Outlook klijentom:
1. Nakon pokretanja Outlook klijenta koji je konfiguriran s Exchange računom, potrebno je u Notification dijelu statusne trake Windows-a kliknuti desnom tipkom miša, pritom držeći CTRL, na ikonu Outlook-a koja će otvoriti prošireni izbornik u kojem je potrebno odabrati Test E-mail AutoConfiguraion

   

2. Nakon otvaranja novog prozora, potrebno je upisati e-mail adresu i po potrebi lozinku, te će aplikacija pokušati dohvatiti postavke s odgovarajućeg Exchange EWS servera:
   

   Nakon dohvaćanja rezultata je moguće pregledati sam rezultat, originalnu XML datoteku, kao i zapisnik pretrage konfiguracije

2. Osim korištenja Outlooka, moguće je koristiti i Microsoft Remote Connectivity Analyzer koji ima mogućnost validacije Autodiscover funkcionalnosti za Outlok i EAS aplikacije

Napredna konfiguracija Autodiscover funkcionalnosti

U određenim situacijama će biti potrebno napraviti naprednije konfiguracije Autodiscover servisa, kako bi se zadovoljile potrebe specifičnih Exchange okruženja.

Modifikacija SCP AD zapisa

Standardno će nakon instalacije Exchange CAS servera biti potrebno modificirati SCP AD zapis kako bi pokazivao na ispravnu adresu Autodiscover servisa. Navedena promijena se radi putem cmdleta Set-ClientAccessServer te ju je potrebno napraviti za svaki CAS server. Primjer:

Set-ClientAccessServer –identity “nazivCASServera” –AutoDiscoverInternalUri https://FQDN.igorp.local/autodiscover/autodiscover.xml

Dodatno je moguće koristiti parametar –AutoDiscoverSiteScope kako bi se specificirali AD Site-ovi za koje će se primijenivati određeni SCP zapis.

Nakon promjene SCP zapisa, potrebno je pričekati replikaciju promjena prema AD-u i prema svim domain kontrolerima.

Kreiranje novog Autodiscover virtualnog direktorija

Ukoliko iz bilo kojeg razloga nije zadovoljavajuća standardna konfiguracija Autodiscovera u “Default Web Site-u”, moguće je kreirati novi virtualni direktorij u drugom IIS site-u, koji naravno može imati sasvim drugačiju IIS konfiguraciju. Valja napomenuti kako nije moguće promijeniti naziv direktorija niti sam naziv XML datoteke s konfiguracijom, te su oni uvijek \autodiscover\autodiscover.xml

Virtualni direktorij je moguće kreirati jedino putem EMS-a korištenjem cmdleta New-AutodiscoverVirtualDirectory. Primjer:

New-AutodiscoverVirtualDirectory -WebSiteName "autodiscover.igorp.net" -WindowsAuthentication $true

Korištenje Autodiscover funkcionalnosti nakon Cross-forest preseljenja korisničkog mailboxa

Kod preseljenja korisničkog mailboxa iz jednom foresta u drugi, korisnik neće standardno moći korisitti Autodiscover funkcionalnost, s obzirom da je njegova aplikacija (Outlook/EAS) konfigurirana s postavkama starog/ishodišnog foresta, a njegov mailbox se u stvari nalazi u novom forestu.

Tome je moguće doskočiti na način da se u ishodišnom forestu za korisnika kreira “Mail kontakt”.

Uzmimo u primjer da se korisnički mailbox premjestio iz foresta igorp.local u forest igorp.onmicrosoft.com. Korisnik je u ishodišnom forestu imao e-mail adresu igor@igorp.net, a u destinacijskom ima primarnu mail adresu igor.pavlekovic@igorp.onmicrosoft.com. Foresti moraju međusobno imati uspostavljeno vjerovanje. Tad je potrebno u ishodišnom igorp.local forestu kreirati novi mail kontakt. Npr.

New-MailContact -ExternalEmailAddress ‘SMTP:igor.pavlekovic@igorp.onmicrosoft.com’ -Name ‘Igor Pavlekovic’ -Alias ‘igor’ -OrganizationalUnit ‘igorp.local/Users’ -FirstName ‘Igor’ -LastName ‘Pavlekovic’

Nakon pokretanja aplikacije (npr. Outlook), ista će kontaktirati Autodiscover servis u konfiguriranom igorp.local forestu tražeći postavke za mail adresu igor@igorp.net s korisničkim imenom i lozinkom igorp.local foresta. Autodiscover servis će odgovoriti s XML datotekom, koja će u sebi sadržavati akciju “redirectAddr” kojom će aplikacija pokušati dohvatiti Autodiscover postavke nove e-mail adrese. U našem primjeru odgovor će izgledati kao:

<?xml version="1.0" encoding="utf-8"?>

<Autodiscover xmlns="http://schemas.contoso.com/exchange/autodiscover/responseschema/2006"><Response xmlns="http://schemas.contoso.com/exchange/autodiscover/outlook/responseschema/2006a">

<Account>

<Action>redirectAddr</Action>

<RedirectAddr>igor.pavlekovic@igorp.onmicrosoft.com</RedirectAddr>

</Account>

</Response></Autodiscover>

http://support.microsoft.com/kb/2540222

—–

Nakon instalacije .NET hotfixa KB

2449742 (MS11-028) postoje problemi s pokretanjem alata za upravljanje Exchange 2010 sustava.
Prve dodatne informacije su dostupne na EHLO blogu http://bit.ly/ffqn48

Izgleda da su pogodjeni samo sustavi instalirani na W2K8 serveru dok W2K8R2 nije pogodjen! To je preliminarna informacija!

Vise informacija uskoro!

Kao i poslijednjih nekoliko godina sama konferencija je podijeljena u dva dijela:

• tehnološka konferencija Microsoft WinDays11 Technology 4.4.-7.4.2011.
• poslovna konferencija WinDays11 Business 7.4.-8.4.2011.

Na WinDaysima će se prezetnirati i neki novi proizvodi, poput Lync Servera, Office 365, Windows Azure, SQL Azure i mnogih drugih.

Posebno bi istaknuo predavanja koja obavezno morate posjetiti, između ostalih (predavanja su po redoslijedu, da ne bi bilo zabune)

• Office 365 – produktivnost u oblaku – 4.4. u 15h @ Dvorana 8 – Igor Pavleković
• Probijanje neprobojnog – 4.4. u 15:10h @ Dvorana 5 – Robert Petrunić
• Čeka li nas oblačna budućnost – 5.4. u 11:20h @ Dvorana 5 – Marin Franković
• Od skice do komunikacije – 5.4. u 15h @ Dvorana 8 – Igor Pavleković
• Oblačno vrijeme na klijentskoj strani – 6.4. u 16:20h @ Dvorana 4 – Robert Petrunić

Naravno, ovo su samo izdvojena predavanja, tako da nikako nemojte propustiti još kolege Tomislava Poljaka, Tomislava Bronzina, Tomice Kaniškog, Tonina Filipovića, Scotta Schnolla i mnogih drugih…

I evo, još jedna vijest koju sam danas saznao, naime, Microsoft me je odlučio ove godine nagraditi sa statusnom nagradom Microsoft Most Valuable Professional: Exchange Server.

Moram napomenuti kako MVP status nije certifikat koji se dobiva tehničkim znanjem određenog područja, već je to statusna nagrada koja se daje istaknutim pojedincima tehničke zajednice za njihovo dijeljenje ekspertize s ostalima. Više o samoj nagradi možete vidjeti ovdje.

Još jednom bi se ovim putem htio zahvaliti kolegama, prijateljima i suradnicima koji su me preporučili, nominirali i podržali za navedenu nagradu. Velika HVALA!

I naravno, ovim putem čestitam i kolegici Željki Knezović i Iliji Brajkoviću na obnovi njihovih MVP titula!

Predavanje će se odviti 4.4.2011. s početkom u 17:00 po našem vremenu. Da, na žalost, sudionicima Windays konferencije se ovo predavanje kosi sa samom konferencijom, ali što se može

Detelje, kao i registraciju je moguće vidjeti na ovoj adresi.

Ispravljeno je podosta otkrivenih problema od RU2, što od strane korisnika, što od interno od strane Microsofta.

Više informacija i download je omogućen s web lokacija:

Update Rollup 3 za MS Exchange 2010 SP1 – trenutno onemogućen
Update Rollup 3 za MS Exchange 2007 SP3

Napomena za Forefront korisnike
Kako bi se izbjegao problem nemogućnosti automatskog pokretanja Exchange servisa Information Store i Transport, prije primjene RU3 na Exchange poslužitelju je potrebno iz komandne linije pokrenuti nadedbu “fcsutility /disable”, te nakon primjene RU-a ponovno omogućiti Forefront naredbom “fcsutility /enable”.

Razlog onemogućavanja distribucije RU3 za MS Exchange 2010 SP1
Nakon distribucije RU3 za MS Exchange 2010 SP1 korisnici Blackberry okruženja su počeli prijavljivati probleme duplanja dolaznih i odlaznih poruka na Blackberry uređajima. Iz navedenog razloga je RU3 povučen iz optiacija do trenutka utvrđivanja i ispravljanja problema s RIM-om. Microsoft preporučuje korisnicima koji su primijenili RU3, a nemaju navedenih problema nek slobodno nastave korisiti RU3, a korisnicima koji su iskusli navedeni problem neka kontaktiraju MS Support kako bi se problem riješio.

U malo izmijenjenom rasporedu, dana 10.3.2010. je održana kombinirana ITPro i Sharepoint users grupa.

Na grupi sam održao predavanje na temu MS Lync 2010 komunikacijskog sustava. Opis predavanja je bio:

MS Lync 2010 je novi naziv za prethodnu verziju, MS Office Communications Server. Na predavanju će biti predstavljeni noviteti, načini implementacije, održavanja i sigurnosti koji su se promijenili od prethodnih verzija. Također, na predavanju će biti predstavljeni novi klijenti koji prate sam sustav.

 Grupa se održava jednom mjesečno u prostorijama Microsoft Hrvatska, a više informacije je dostupno na adresi www.mscommunity.org

Link na jučerašnju prezentaciju je dostupan na adresi http://bit.ly/itpro_lync

DAG-ovi se temelje na log-shipping metodi koja je uvelike redizajnirana u Exchange 2007 verziji, te u Exchange 2010 sustavu služi kao okosnica visoke dostupnosti mailbox serverske uloge. Storage groupe su sad stvar prošlosti, a baze nisu toliko usko vezane uz sam server, nego uz organizaciju

Još jedna velika novost je da Exchange serveri u DAG-u mogu na sebi kolocirati ostale uloge (HUB, CAS, UM), te se isto tako visoka dostupnost može aktivirati u bilo kojem trenutku, a ne samo za vrijeme instalacije, kao što je to bio slučaj s prethodnim verzijama.

Ovaj demo u obliku videa je podjeljen u dva dijela – kreiranje DAG-a, te se u drugom dijelu konfiguriraju baze za korištenje u DAG-u.

Uživajte!

P.S. U drugom videu je pokazivač miša malo time-shiftan, ali nadam se da nećete zamjeriti!

Click here to view the embedded video.

Click here to view the embedded video.

U tom novom OCS-u (OK, Lync-u) ima podosta novosti. Potpuno novi klijent, novi serverski pristup. Dosta je toga za ovdje nabrojati.

Što se povijesti tiče, naznake nekih funkcionalnosti sežu još i u Exchange 2000 u kojem je postojala neka naznaka IM-a. Nakon toga se pojavljuje MS Live Communications Server, koji je po mom osobnom mišljenju bio sam usputna stanica do MS Office Communications Servera 2007. Isti je RTM-an sredinom 2007 godine, a godinu dana kasnije je najavljena R2 verzija, koja je po mom osobnom mišljenju danas i najprihvaćenija.

No, rekao bi da su to sve bile usputne točke do današnjeg proizvoda – Microsoft Lync servera.

Sjećam se jednog od glavnih punch-pointova na predavanju kojeg sam držao s kolegom Petrunićem na Mobility Day-u 2007 godine – OCS nije “PBX killer”. Jedna od glavnih poruka koju mogu reći za Lync – on je PBX killer, ako vi to želite.

Neke od novosti koje su dostupne s novim Lync-om su:

• potupno novi klijent – Microsoft Lync 2010
  • jedna aplikacija za sve: IM, prisutnost, audio i video, glasovnu komunikaciju i web konferenciranje
  • jedan set kontakata za sve Office aplikacije
  • integracija s MS Outlook-om i MS SharePoint-om
• Enterprise glasovna komunikacija
  • potpuna PBX funkcionalnost
  • integracija s postojećim proizvodima i uslugama
  • podrška za različite IP i USB uređaje
  • poboljšana redundancija u podatkovnim centrima, ali i u manjim poslovnicama (Survivable Branch Appliance)
  • upravljanje bandwidthom i QoE-om korištenjem Call Admission Controla, QoS markinga i dinamičkom prilagodbom temeljem medija prijenosa
• Alati za deply i upravljanje
  • PowerShell
  • grafički alat za upravljanje temeljen na Silverlight-u
  • poboljšana sigurnost i administracija temeljem Role-based Access Control-a (RBAC)
  • podrška za virtualizaciju, večine serverskih uloga
  • poboljšanja u podršci za prilagodbu (developerske priče…)

Što se same serverske topologije i uloga tiče, tu nije došlo do nekih velikih promjena – sve su one tu, neke poboljšane, konsolidirane no nema nekih prevelikih promjena.

Ako sad vičete: hoću to – reći ću stop!

Opet se vraćam u povijest i mojeg susreta s OCS-om. Odlučio ja to naučiti i krenuo skidati dokumentaciju. Prvi dokument na koji sam nabasao se je zvao, nešto u stilu “Roadmap to documentation”. Uglavnom, dokument o OCS dokumentaciji. Krenuo skidati sve to ja i poslao na prinatnje. Za par dana me je kraj stola dočekala hrpica visoka odokativno pola metra. Nice!

Sam deployment laba sam radio kad sam imao vremena. Ali, sve u svemu mislim da je trajao nekih 2 mjeseca prije no što smo dobili funkcionalno okruženje. Danas stvari idu nešto jednostavnije. Naime, ekipa u MS-u svijesna činjenice koliko je OCS u stvari zahtjevan za konfiguraciju i pripremu je napravila jedan alat. Radi se o Microsoft Lync Server 2010, Planning Tool (RC). Naime, to je alat koji je u obliku čarobnjaka, a pomaže Vam u izradi topologije, planiranju servera, IP adresa, servisa, DNS-a, certifikata, ma u stvari svega što vam je potrebno kako bi uspješno kreirali i konfigurirali okruženje za Lync.

Slika prikazuje primjer iz Planning Tool-a za konfiguraciju DNS zapisa

Ono što mi se posebno kod ovog alata sviđa su detaljni izvještaji o konfiguraciji DNS-a, Firewalla, certifikata. Zaista, ako se slijepo slijede preporuke alata, Lync će biti upogonjen na poprilično jednostavan način. Pogotovo, ako se uzme u obzir činjenica, da se napravljena topologija može eksportirati i nakon toga importirati u alat pod nazivom Topology Builder.

Prilikom same instalacije Lync-a, biti će potrebno pokrenuti Topology Builder, koji je isto tako alat u obliku čarobnjaka, koji je zadužen za kreiranje topologije vašeg Lync okruženja. Nakon što u njega upišete sve potrebne podatke, ti podaci se pohranjuju u predefiniranu bazu podataka i oni se u stvari koriste za rad poslužitelja. Kod OCS-a je priča bila da su se podaci upisivali tijekom same setup procedure u razno-razne čarobnjake. Ovdje, ne samo da imate jedan alat kojim to možete napraviti, nego čak podatke iz faze planiranja kreirane Planning Tool-om možete koristiti u setup-u.

Odgovor na to pitanje je u stvari drugo pitanje: kako je certifikat izdan?
- ako se radi o certifikatu izdanom od strane Enterprise Certification Authority-a, a ovisno o konfiguraciji samog predloška certifikata, isti će vjerojatno biti pridodan kao property user objekta AD-a i biti će dostupan korisniku

No, što ako je certifikat izdan od strane 3rd party CA, poput recimo certifikata za autentikaciju na nekim WEB servisima ili certifikata izdanog za digitalni potpis?

Opet imamo dvije opcije: certifikat može biti pohranjen na nekom vanjskom štićenom mediju, poput recimo smart-kartice ili USB tokena – tad nema problema, medij se priključi na računalo, odradi se predautentikacija (najčešće PIN ili otisak prsta) i eto pristupa certifikatu. No, takvi uređaji su često puta skupi, pa se onda i ne koriste u širokoj primjeni.

OK, dakle, ostaje pitanje što je sa soft certifikatima, koji uključuju korisnički privatni ključ. Opcija odlaksa u Active Directory Users and Computers konzolu, te importiranja certifikata u “Published Certificates” tabu neće proći… PFX datoteku tamo nije moguće importirat. Jes, možete importirati cert, ali bez privatnog ključa i onda ništa od toga, odnosno autentikacija na servisu Vam neće raditi.

Naravno, moje iduće razmišljanje je bilo, pa kreirat ću roaming profil, u sklopu kojeg će biti uključen i dotični certifikat iz odgovarajućeg store-a, no ne bi vjeroavli to ne radi Barem meni nije proradilo. Znam da smo imali problema s time i ranije, prilikom recimo imiđiranja računala. Izgleda da je Cert store štićen, između ostalog i SID-om računala na neki način i eto problema. Istina, nisam baš previše istraživao kako su certovi u stvari štićeni, pa ako netko ima želju podjeliti – be my guest.

No, na svu sreću, našao sam rješenje. Gdje? Naravno, u GP-u

User Configuration\Policies\Windows Settings\Security Settings\Public Key Policies\Certificate Services Client – Credential Roaming

Priča kaže ovako. Proširivanjem AD sheme (W2K3, W2K8 ovo ima standardno) se dodaju nova atributa koja su potrebna za pohranu podataka o vjerodajnicama (ovo je u stvari credentials riječ… OK, obečajem, neću više) , a to su:

• ms-PKI-DPAPIMasterKeys – sadrži master ključeve za enkripciju
• ms-PKI-AccountCredentials – objekte poput certifikata, privatnih ključeva, zahtjeva za certifikatima
• ms-PKI-RoamingTimeStamp – timestamp zadnje promjene

Važno je napomenuti kako je za sigurno korištenje potrebno AD okruženje u kome su DC poslužitelji bazirani minimalno na W2K3 SP1 sustavu. Tome je tako, pošto je u toj verziji OS-a implementirana mogućnost dodatne zaštite određenih atributa od mogućnosti čitanja/prikazivanja ostalim korisnicima.

Credential roaming je omogućen na računalima od Windows XP SP2/Windows Server 2003 SP1 na više, s time da je na XP-u i W2K3 OS-ovima potrebno implementirati update, koji je dostupan s MS Support stranica KB907247

Ajmo vidjeti sad koje postavke postoje u sklopu GP-a vezanog za Credential Roaming:

• Maximum tombstone credentials life in days – nakon što određenom certifikatu istekne valjanost, nakon koliko dana će on biti uklonjen iz AD-a. Valja voditi računa o vrijednost koja će se ovdje specificirati. Naime, ako uzmemo za primjer situaciju korisnika koji se je u prošlosti logirao na dva računala, te se na oba zbog Credential Roaminga nalaze njegovi certifikati. No, u poslijednjih 90 dana se je korisnik logirao samo na jedno od tih računala, a certifikat je istekao prije 60 dana. Na tom računalu će certifikat biti izbrisan, kao i u samom AD-u. No, ako se korisnik logira na drugo računalo (nakon 90 dana) na njemu će postojati istekli certifikat i dalje. Kad korisnik na tom računalu napravi logoff, cert će se ponovno kopirati u AD, a time i na ostala računala na koja se korisnik logira nakon toga!
• Maximum number of roaming credentials per user – koliko se za svakog korisnika može pohraniti certifikata
• Maximum size (in bytes) of a roaming credentials – kolika je maksimalna veličina jednog pohranjenog credentiala. Također, valja voditi računa o ukupnoj veličini user objekta. Naime, ako je dopušteno (standardno) 2000 credentiala, od kojih je svaki 65 KB dolazimo do računice kako user objekt može narasti do 130 MB!!
• Roam stored usernames and passwords – samo ime kaže. Valja napomenuti kako navedena postavka vrijedi samo i isključivo za verzije Windowsa od Viste na više

Valja napomenuti slučaj da se probije bilo koja maksimalna veličina ili količine credentiala, sam sustav roaminga vjerojatno neće raditi, tako da o tome valja voditi računa prilikom definiranja postavki!

Pojednostavljeno, stvari funkcioniraju na slijedeći način:

1. Domenski korisnik se logira na domensko računalo. Radi se komparacija Local store-a i podataka u AD-u. Bilo kakva razlika se ili povlači na klijentsko računalo u Local store korisnika ili se šalje u AD.
2. Proces roaminga će se također dešavati u slijedećim situacijama: reboot računala, lockanje računala, local user switch, te svakih 8 sati

E sad, o čemu valja voditi računa prilikom implementacije:

• nemojte koristiti i roaming user profile i credentials roaming – moguće je da će se desiti nepredviđeni problemi u sinkronizaciji podataka
• nemojte koristiti mandatory user profile i credentials roaming – iako ne postoji neki službeni razlog zašto, ipak vam ne preporučujem mješanje ovih dviju tehnologija
• ako koristite proces auto-enrollmenta user certifikata od strane Ent CA-a, vodite računa da se taj GP izvršava nakon GP-a za Credential Roaming. Razlog je jednostavan. Ako se je korisnik logirao na računalu A, te se je tamo desio auto-enrollment, certifikat će biti uključen u Roamingu. No, kad se korisnik logira na računalo B, a auto-enrollment se desi prije roaminga, korisniku će biti izdan dupli certifikat bez razloga

I evo, za kraj, primjer izgleda user objekta, odnosno propertija kojem je omogućen Credential Roaming:

Dakle, zanimljiva priča – jedan sustav koji održavam, kliknem spajanje remote dekstopom na taj server (W2K3 Ent. Edt.), a kad ono crni ekran… Nula bodova, ništa… Samo žuta traka na vrhu s podacima o serveru

Lagano, WTF! Naravno u toj situaciji se čovjeku, koji boluje od sigurnosne paranoje po glavi počnu rojiti razno-razne misli o urotama, hakerskim napadima, exploitima, root-kitovima koje je možda netko na stroj posatvio. Uglavnom, pređem mišem preko ekrana (ok, pokazivačem miša), a kad se tamo strelica pretvori u ravnu crtu, kursor, kao da se nalazi iznad teksta i spremna je za označavanje teksta. OK, znači, tamo ima nečeg samo to ne vidim. Kako RDP radi po principu prijenosa slike, jasno mi je da ja u stvari ne vidim sliku logon ekrana, ali tamo ipak ima nešto. Super, živ je! Sjetim se da je na stroju postavljen disklejmer s upozorenjem kako se pristupa privatnom sustavu. Lupim ENTER i šta mi se pokaže? Ovo:

(slika je montirana, ali you got the point)

OK, skužim da mi blinka kursor na mjestu gdje bi se trebao upisati username – i upišem ga. Tab, upis lozinke i ENTER. Ekran se malo okrene, kao, i narančasto-plava traka počne teći… OK, nešto se dešava. Za nekoliko trenutaka dobijem normalan desktop i kao da se ništa nije desilo. Ajmo opet… Logoff, RDP i opet isti scenarij… Sve crno…

Google je naš prijatelj, i skužim da se nije nikakva mračna sila nadvila nad taj jadan server, nego da je to poprilično učestala pojava ?!?! Dapače, i na MS Supportu postoji KB vezan uz to (KB555840). U KB-u piše da se pokuša isključiti Bitmap caching na RDP klijentu, no to mi nije pomoglo. Promijeniti MTU… Yea, right Opet ništa… Guglam dalje i naiđem na rješenje. Rješenje predlaže resetiranje nekih registy ključeva koji se odnose na palete boja. Hmmm… Pogledam ključeve, zaključim da nije ništa opasno i primijenim. Log Off, RDP ponovno i guess what? Stvar funkcionira!!

Stoga, ako se itko ikad od Vas nađe u ovakvoj situaciji, prođite po KB-u gore nabrojanom, a ako ne uspije – ovo treba importirati u registry (ma, znate kako se to radi, ne?):

Windows Registry Editor Version 5.00

[HKEY_USERS\.DEFAULT\Control Panel\Colors]
"ActiveBorder"="212 208 200"
"ActiveTitle"="10 36 106"
"AppWorkSpace"="128 128 128"
"Background"="102 111 116"
"ButtonAlternateFace"="181 181 181"
"ButtonDkShadow"="64 64 64"
"ButtonFace"="212 208 200"
"ButtonHilight"="255 255 255"
"ButtonLight"="212 208 200"
"ButtonShadow"="128 128 128"
"ButtonText"="0 0 0"
"GradientActiveTitle"="166 202 240"
"GradientInactiveTitle"="192 192 192"
"GrayText"="128 128 128"
"Hilight"="10 36 106"
"HilightText"="255 255 255"
"HotTrackingColor"="0 0 128"
"InactiveBorder"="212 208 200"
"InactiveTitle"="128 128 128"
"InactiveTitleText"="212 208 200"
"InfoText"="0 0 0"
"InfoWindow"="255 255 225"
"Menu"="212 208 200"
"MenuText"="0 0 0"
"Scrollbar"="212 208 200"
"TitleText"="255 255 255"
"Window"="255 255 255"
"WindowFrame"="0 0 0"
"WindowText"="0 0 0"

Alat je koncipiran tako da upišete za pojedine servise odgovarajuće parametre, te će se alat pokušati spojiti i validirati postavke. Alat to može napraviti za:

• Exchange ActiveSync
• ActiveSync AutoDiscover
• Exchange Web services
• Microsoft Office Outlook Connectivity
• Internet Email

Ono što mi se na prvi pogled nije svidjelo je činjenica da se mora upisati korisničko ime i lozinka u večini slučajeva, no što sad? Za potrebe testiranja možete otvoriti dummy mailbox s željenim postavkama i njega koristiti za testiranje. Također, veliki plus za cijelu stvar je korištenje SSL-a za enkripciju podataka. Thumbs up!

Alat je dostupan na adresi https://www.testexchangeconnectivity.com

Naravno, ovaj alat ne zamijenjuje dokumentaciju koju je potrebno, jel, pročitati prije svakog deploymenta, no može itekako poslužiti kao šalabahter.

Alat je dostupan na adresi Exchange Server 2010 Deployment Assistant.

Uredno sam poinstalirao sve potrebne preduvjete, još jednom patchirao, napravio upgrade scheme, pripremu foresta i domene, te pokrenuo instalaciju OCS-a. Sve je kao uredno prošlo, no na kraju instalacije Setup meni kaže failed. Wtf? Krenuo pregledavati logove, te u deployment logu, pod zadnjom točkom “Check product ID” on meni javi grešku:

Ništa, reko, ajmo probat rebootat stroj, pa pokušati još jednom ponovno. Ponovno ista greška.

U tom trenutku sam totalno bio zaboravio (naravno) da je tamo negdje u 10. mjesecu izdan patch koji rješava probleme u CryptoAPI-u, a koje mogu dovesti do spoofinga (detalji…). No, primjenom tog patch-a na OCS serveru, dešava se jedna jako zanimljiva stvar – OCS Server počinje misliti kako je njegov Trial istekao Da, ne bi vjerovali, OCS je prestao raditi kod nas upravo zbog tog problema. Inače, greška koju ćete dobiti izgleda od prilike ovako:

The evaluation period for Microsoft Office Communications Server 2007 R2 has expired. Please upgrade from the evaluation version to the full released version of the product.

Naravno, nećete moći startati servis i…. Pripremite se na pozive korisnika

Uglavnom, u čemu je problem – u navedenom patchu, i u jednoj i u drugoj situaciji. No, koje je rješenje? Deinstalirati patch? Hmmm… Pa, da, to je rješenje, no nikako nije best practice. Orginalni problem je objavljen pod KB-om 974571, te je članak relativno nedavno revidiran i dodan je hotfix za OCS sustave koji su pogođeni navedenim problemom. Dakle, nema deinstalacije, nego instalacije i to hotfixa! Patch je preporučljivo instalirati nakon Security Update-a 974571, no prije samog restarta… Ako se pak server reboota, potrebno je ručno startati servise nakon primjene hotfixa.

Ajmo ljudi, zapatchirajte Vaše sustave!

Teoretski gledano, CA je u stvari jedna baza podataka koja sadrži informacije o certifikatima koji su izdani, povučeni ili čekaju na izdavanje. Naravno, u pozadini cijele priče se nalazi servis koji je zadužen da se certifikati izdaju kako spada, da se vodi računa o objavljivanju povučenih certifikata i slično. No, opasnost je velika, ukoliko se nešto netočno ili brzopleto napravi, da cijela infrastruktura koja ovisi o CA servisima jednostavno prestane funkcionirati, zbog recimo nedostupne lokacije CRL-a (Certificate Revocation List).

Microsoft je naravno na svojim stranicama objavio dokument koji opisuje dva moguća scenarija – migracija i upgrade. Migracija podrazumijeva fizičku zamjenu servera, doku upgrade podrazumijeva nadogradnju samog operacijskog sustava (recimo, upgrade s MS Windows Server 2003 na MS Windows Server 2008 R2). Sam dokument je dostupan na ovoj adresi.

Proces migracije, koji sam spomenuo na početku, je poprilično jednostavan, te ću ga u kratim crtama ovdje i opisati. Za početak je potrebno napraviti backup postojećeg CA. Backup je moguće napraviti na dva načina: korištenjem System State-a ili direktnim backupiranjem iz same CA konzole. Pošto se radi migracija, a System State nije nešto na čemu se može birati što će se pohraniti ili ne, tad ta opcija nije primijenjiva. Ostaje opcija samostalne pohrane iz CA konzole. Po izboru, pohranit će se sama CA baza, te će se eksportirati i odgovarajući CA cartifikat. Osim navedenog, potrebno je pohraniti i registry sekciju konfiguracije, koja se nalazi na lokaciji HKLM\SYSTEM\CurrentControlSet\Services\CertSvc. Nakon toga navedeni vodič sugerira da se deinstalira servis CA na starom serveru, no ja Vam to ne bi preporučio – ne još. Jednostavno iz Services konzole (ili na bilo koji drugi način) stopirajte CA servis kako ne bi bio aktivan, no da ga ipak po potrebi možete reaktivirati ukoliko nešto pođe po zlu. Nakon toga, na novom straju instalirajte željeni OS, te napravite instalaciju role AD Certificate Services. Pokrenut će se wizard koji će vas pratiti kroz sam proces. Wizard je isti kao da radite instalaciju novog CA (to zaista i radite), ali vodite računa da prilikom upita o korištenju novog ili postojećeg CA certifikata odabere – postojeći, gdje ćete odabrati .p12 datoteku koja je kreirana prilikom backupa CA. Nakon toga imate, de-facto stari CA, ali potrebno je još napraviti restore podataka, kako bi dobili u njemu podatke sa starog servera. Nemojte također zaboraviti importirati registry postavke, u kojima je potrebno zamijeniti FQDN-ove starog servera s novim. Moja preporuka Vam je da u svakom trenutku vodite računa i pregledavate logove, kako bi eventualne probleme mogli otkloniti za svaki korak posebno, a ne u slučaju da vam ih se nekoliko nagomila. Za kraj ostaje provjeriti AD ovlasti, te testirati da li CA radi očekivano. Po meni je tu najkritičnija provjera objave CRL-a, pošto ukoliko on nije dostupan, niti klijenti neće moći raditi provjeru povlačenja certifikata, a to bi kod pojedinih servisa moglo uzrokovati nefunkcioniranje! Također, vodite računa, ukoliko niste koristili standardne postavke objave CRL-a, da su sve lokacije na kojima su liste objavljene dostupne klijentima, te da novi CA na navedene lokacije može objavljivati nove CRL-ove.

Sve u svemu gledano, proces nije toliko zahtjevan koliko se čini, te se sve lijepo može napraviti jednu večer ili preko vikenda

Zašto sam uopće nestao? Pa, iskreno, koliko god glupo zvučalo – nisam imao vremena… Negdje prije ljeta mi je istekao hosting, a bio sam prelijen ga obnoviti (nije bilo tako baš jednostavno kao ostaviti broj kreditne kartice)…

No, eto, to je totalno nebitno zato jer sam se ponovno vratio, te se nadam da ću vas uveseljavati svojim postovima, komentarima i savjetima… Pa, živi bili i vidjeli da li ću imati snage, volje i živaca za pisanje i održavanje ovoga? Ali, gledajući svoje kolege, prijatelje, suradnike, ne bi trebalo biti tako teško! Nadam se!