Office 365 – Changing last name of a user [EN]

User’s last name change was never a trivial change for us. There are so many places and systems, that have to be updates. Some require to change the name, some even require to create a new user and delete old one. With the on-premises Exchange we were used to just rename the user in AD (leaving its username (pre-Win2000 UPN) the same) and then create new mail alias and make it primary. Recently i had to do this for a synced Exchange Online user and that was “fun”. For the most part it worked fine. But i’m already developing a habit, that sometimes with MS cloud services you just have to wait for things to start working. Say you just setup new OneDrive user and try to share a file. It doesn’t send sharing notification emails? Try next day. It should work then.. Read More

Office 365 – Creating mailboxes [EN]

I have read some pretty recent article, that you almost must still have an on-premises Exchange installation to manage mailboxes in Exchange Online after you have migrated to Office 365. I have also heard that in order to have a new shared mailbox, you have to first create a regular one and then convert it. Well, some of these things might worked this way in the past and some might be just a matter of convenience. But everything is much simpler now. Although, we are still in the Hybrid mode and some things might change once we finally get rid of our on-premises Exchange.

To create a shared or room mailbox you just do that – go to EAC (Exchange admin center in Office 365 portal), go to shared or resources and create a shared mailbox (assign an address and permissions for users who will use this shared mailbox) or a room. When saving new shared mailbox it shows me a warning that it failed to replicate it. But it actually creates it and you can open it via OWA pretty soon. It took 15-20 minutes for it to actually appear in Outlook of a user having permissions to it. Same goes for the rooms. It takes some time. Longer than with on-premises Exchange, but it eventually appears in Outlook. Read More

Office 365 – Deleting users with the same UPN and Display Name [EN]

This is not a usual issue and in my case happened only once during some experimentation. But it still can happen. We have our AD objects synchronized into Azure AD via Azure AD Connect service. When you delete a user in your local AD, after a synchronization it is moved into Deleted users container in Azure AD (Admin center > Users > Deleted users). You can even restore a user via graphical interface in Office 365 admin center. Though i haven’t tried this, as this might not play well with our setup. But you can’t delete users from Deleted users in there. They will disappear after a 30 days period. If you still need to remove a deleted user right away, there is a PowerShell command for that. To do this you have to install Azure AD PowerShell Module, which i have mentioned here.

Read More

Office 365 – PowerShell Zoo [EN]

When i started digging deeper into some aspects of Office 365 i have discovered an interesting and a bit weird (in my opinion) thing. It wasn’t a surprise that some advanced changes are only possible via PowerShell (Microsoft is pushing its shell for many years). But there is no unified, single PowerShell module to manage all the services. You almost have to install and use a separate module for every service. Some of them have different procedures to login. That’s a jarring experience. I will try to describe a few of them that might be useful. Especially when dealing with support, which often asks for an output for some PShell commands on your tenant. Personally i install them all on the same server running Azure AD Connect, as none of my workstations were running 64-bit OS at the moment (and many of these modules, if not all, require x64) and i decided to keep everything related to Office 365 in one place. Read More

Office 365 – Dealing with spam [EN]

Microsoft and its partners advertise Exchange Online and as having one of the best spam filtering. Well, every email service brags about it. But in reality things are not so good. Prior to switching our incoming and outgoing email traffic to Exchange Online we were using a local hosted solution. Well, we are still kind of using it as not all mailboxes have been migrated yet. But all the filtering is done on the cloud side now. Hosted solution consists of Exchange 2013 server and IronPort firewall/anti-spam. This is managed by a service provider and we do not have control of it (aside of creating mailboxes and tweaking some minor stuff). We had a number of filtering rules created for us by our providers. It wasn’t perfect. IronPort seems to not be that flexible. But as we have switched to Exchange Online the hell broke loose.. Well, not that bad actually. But we certainly saw the increase of spam. And sometimes it allowed emails with just a link to “learn how to please your girlfriend” to come through. Well, i wouldn’t call SUCH filtering as a first class service 🙂 Read More

Office 365 – moving mail aliases in the synchronized environment [EN]

If you have used an on-premises Exchange server before, then moving aliases is a trivial task. But, if you are synchronizing your AD information into Azure AD (e.g. with Azure AD Connect service), so you could assign Office 365 licenses and services to your users, then things become a little bit trickier. As mail aliases and main addresses are the attributes of your internal AD users and the information is only synced in one direction (from your on-premises AD to Azure AD). So, you can’t add or change aliases in the Exchange Online administration center for the existing mailboxes. This change has to be applied in your AD environment and then synced to Azure AD. This can be achieved by opening the AD user properties window and going into Attribute Editor tab (if it is not there, you have to first enable View > Advanced Features in your Active Directory Users and Computers snap-in). In that tab you have to find the ProxyAddresses entry, mark it and press the Edit button. Then you can add or remove aliases. Alias is added in the form of smtp:address@domain.tld. User’s main address starts with a capitalized SMTP part. When you add an alias address in here, it won’t automatically appear in Exchange Online. You have to wait for the synchronization with Azure AD to occur. When using Azure AD Connect automatic synchronization occurs every 30 minutes. You can also do a manual sync with this PowerShell command:

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta

Read More

Office 365 – paÅ¡to aliasų perkėlimas sinchronizuotoje aplinkoje [LT]

Jeigu jums teko naudoti vidinį (on-premises) Exchange serverį, paÅ¡to aliasų kÅ«rimas ir perkėlimas atrodo trivialus dalykas. Tačiau, jeigu savo vidinio AD turinį sinchronizuojate į Azure AD (pvz. su Azure AD Connect servisu), kad galėtume savo vartotojams suteikti Office 365 licencijas ir paslaugas, tai yra Å¡iek tiek keblesnis dalykas. Kadangi paÅ¡to aliasai, kaip ir pagrindiniai adresai, yra jÅ«sų vidinių AD vartotojų savybės (“attributes”) ir visa informacija sinchronizuojama tik į vieną pusę (iÅ¡ vidinio AD į Azure AD). Todėl Exchange Online administravimo panelėje negalima iÅ¡trinti ar sukurti aliaso esamoms dėžutėms. Å is pokytis turi bÅ«ti atliktas jÅ«sų AD sistemoje ir po to sinchronizuotas į Azure AD. Atlikti tai galima atidarius AD vartotojo kortelę ir nuėjus į Attribute Editor skirtuką (jei jo nerodo, pirmiausiai reikia Active Directory Users and Computers panelėje įjungti View > Advanced Features). Å iame skirtuke reikia paspausti ant eilutės ProxyAddresses ir paspausti Edit mygtuką. Tuomet galima trinti ar pridėti aliasus. Alias pridedamas tokiu bÅ«du: smtp:adresas@domenas.tld. Pagrindinio adreso pradžia yra iÅ¡ didžiųjų raidžių – SMTP. Pridėjus aliasą AD vartotojo kortelėje jis iÅ¡kart nepradės veikti Exchange Online sistemoje. Pirmiausiai turi įvykti sinchronizacija į Azure AD. Kai naudojamas Azure AD Connect servisas, ji vyksta kas 30 minučių automatiÅ¡kai. Taip pat ją galima paleist rankiniu bÅ«du su tokia PowerShell komanda:

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta Read More

Office 365 – Skype for Business and regular Skype [EN]

Most probably this won’t be important for those who are doing migration to Office 365 services consistently and in full scale. Because DNS records for all services are mentioned when first configuring new Office 365 tenant and creating a special DNS record to prove your ownership of a domain. But as we only needed to assign Office ProPlus licenses at first we have skipped creating additional records. Later, after receiving Skype for Business (SfB) licenses, we have decided to test communication with external SfB and regular Skype contacts. It failed. Although it was enabled in the SfB admin center. But it still was giving an error that some policy is blocking such communication (not a very helpful error message btw). It turned out hat we needed a few special DNS records on our domain to make it work. Examples can be found at Office 365 Admin Center > Settings > Domains > domain.tld. Read More

Office 365 – Skype for Business ir paprastas Skype [LT]

Tikriausiai Å¡is dalykas nebus aktualus tiems, kas perėjimą prie Office 365 paslaugų daro nuosekliai ir pilnai. Nes pirmą kartą prijungiant savo domeno vardą yra raÅ¡oma apie specialius DNS įraÅ¡us visoms paslaugoms, tame tarpe ir Skype for Business (SfB). Bet kadangi pradžioje mus domino tik priskirti Office ProPlus licencijas (kitų tuo metu neturėjom) buvo pridėti tik tie įraÅ¡ai, kurių reikėjo patvirtinti savo domeno nuosavybę ir suriÅ¡ti jį su Office 365 tenant’u. Vėliau, kai jau turėjom SfB licencijas, nusprendėm pabandyt ar pavyks iÅ¡ SfB kliento susisiekti su paprasto Skype vartotojais. Nepavyko. Nors Office 365 – SfB administravimo panelėje įjungėm leidimą bendrauti su iÅ¡oriniais kontaktais (tai apima ir kitus SfB ir paprasto Skype kontaktus). Tačiau bandant paraÅ¡yti kokiam nors Skype naudotojui gaudavome klaidą, kad neva politikos neleidžia tokio dalyko (nelabai naudingas klaidos praneÅ¡imas beje). Pasirodo trÅ«ko DNS įrašų mÅ«sų domene. Ä®rašų pavyzdžiai rodomi Office 365 Admin Center > Settings > Domains > domenas.tld lange. Read More

Office 365 – organizacijų iÅ¡gelbėjimas? [LT]

Jau beveik metus savo darbovietėje bandome, diegiame ir po truputį migruojame į šias vis dar naujoviškai atrodančias paslaugas. Planuoju pradėti trumpų straipsnių seriją su patarimais ir įžvalgomis pagrįstomis mano patirtimi su šia Microsoft paslauga-produktu. Bet pirmame įraše norėjau iš pradžių pasidalinti savo įspūdžiais ir tam tikromis abejonėmis.

Office 365 pasirodė kaip sprendimas organizacijoms atsikratyti galvos skausmo prižiūrint savo infrastruktūrą ir auginant savo IT personalą (ir skaičiumi ir kokybiškai). Na, negaliu pateikti tikslios citatos iš MS, kad būtent tokia buvo pagrindinė idėja, bet toks susidaro įspūdis domintis šiomis paslaugomis, skaitant naujienas, bendraujant su tiekėjais. Aišku, dar vienas postūmis tam buvo gamintojo noras pereiti prie stabilesnį pelną teikiančio prenumeratos modelio. Ant popieriaus viskas atrodo puikiai. Nereikia nei savo serverinės, nei sutarčių su vietiniais duomenų centrais, nei mokėti keliems vietiniams IT specialistams prižiūrintiems sistemas. Tereikia tik užsakyti licencijas, priskirti jas vartotojams ir viskas. Kokios nors paprastos kontorėlės su keliais darbuotojais dirbančiais su Office ir paštu atveju tai visai įmanoma. Ir netgi nereikia tokiu atveju turėti savo IT specialisto. Kuris nors vadybininkas ar pats vadovas galėtų užsiimti licencijų užsakymu. Aišku, didesnės kompanijos jau turi tam tikrą vidinį ūkį, kurio taip paprastai neatsisakysi ir į debesiją neiškelsi. Bet Office 365 lyg ir turėtų nuimti kažkiek aptarnavimo krūvio. Read More