The Smile-IT Blog » Blog Archives

Tag Archives: Collaboration

Skype-for-Business (Lync) on 1und1

Some time ago I promised to add a post about how to configure all the Lync DNS records on 1und1 (if in case you are hosting your domain there – might however be, that the information applies to other DNS providers as well).

Well … as time flies, 1und1 obviously has improved their domain management portal, hence all that “fancy stuff”, we originally did in order to make it work, is void now, and the best and pretty straight forward explanation on how to do it rightly can be found in the Office365 support pages.

Be happy and enjoy (I am and did – and it works perfect for us)


Published by:


OR: How to successfully migrate from POP to an Office365 mailbox, when your hoster doesn’t support you!

Yes, @katharinakanns was right, when she recently said, I’d bother with Office365 to get all our IT stuff migrated onto it. Sounds ridiculous, maybe, but it’s 2 domains, 2 mailboxes, a bunch of subdomains, aliases used all around the net, etc. etc. etc. … and we’d like to merge that all into one place.

Before you read on, this one here is – since long – something more down to earth again, so get ready for some bits and bytes 🙂

What’s this about?

These days I started to setup our Office365 tenant to serve both our single-person businesses as well as become the place for joint collaboration (and maybe more lateron). One thing in this that bothered me indeed a bit beyond normal was OneDrive – but that’s a different story to come … Another pretty interesting process was the domain migration. And even though umpteenth blogposts already tell the way to take from different angles, we ran into one bit that wasn’t just to solve by a click. I’ll share a few straight forward steps with domain migration here; but I’ll also share some hints beyond.

1. Know your hoster/provider

The domain you want to migrate into Office365 will most probably be managed by some ISP (like e.g. “” or any other hoster; one whom you trust, maybe). Out of our experience, I’d suggest you get in touch with the support hotline of your hoster first and make sure

  • (a) whether editing DNS records for your domain is possible for you yourself (e.g. by some web interface) and (!) to which extent
  • (b) how accurately the hotline reacts in case of problems
  • (c) whether they can help in case of any failure over the weekend (one would want to have a business mailbox up and running on Monday morning, I guess)

I had to migrate 2 domains, one of which was with a hoster not allowing editing DNS myself but reacting swiftly to support requests and executing them just perfectly. The other one allowed editing the DNS by me but only let me enter TXT and MX records (no CNAME records – at least not for the primary domain). Or to be precise: The self-service web interface would let me do that but clearly stated that any existing records for this domain would become invalid by this step – and I wasn’t too sure whether this might run us into troubles with our business website …


The warning about deactivating existing records


Note: The second was "" and they do not offer any possibility of doing anything else in terms of DNS than what is provided for self service. I tried really hard with their support guys. No(!) way(!).

2. How migration works when your ISP cooperates

To begin with, it would of course be possible to simply move DNS management from the ISP to Office365. In that case, all the ISP would have to do is changing the addresses of the name servers managing the respective domain. We didn’t want that for several reasons, hence went for the domain migration option, which is actually pretty straight forward.

The Office365 domain management admin console is totally self-explanatory in this, and there’s umpteenth educational how-to-posts. The keyword is – surprise(!) – “Domains” and you just follow step 1-2-3 as suggested.

Office365 admin console - the place to start off into domain migration

Where you start: Office365 admin console

One can either start at the “Email address” section here (if there’s not yet any custom domain managed within the tenant) or by “Domains” further below:

  1. Office365 wants to know whether the domain is yours. Therefore Office365 shows you a TXT DNS record in the first step, which you have to forward to your hoster to be entered as part of “your” DNS. If you’re able to enter that yourself this step is accomplished in no time. Otherwise it depends simply on the response time of the support line. BTW: DNS propagation in general may take up to 72 hours as we know – however, in reality I didn’t experience any delay after having received the confirmation that the TXT has been entered. I could forward to step 2 instantly.
  2. With step (2) Office365 changes any user’s name that you want to make part of the then migrated domain. Essentially that’s a no-brainer, but an Office365 user currently can only send eMails being identified with exactly this username. Receiving goes by multiple aliases which can be configured separately in the user management console; but sending always binds to the username (there’s ways around this as well – but that’s again a different story). Hence, it is worth some consideration which users you click in this step.
  3. Proceeding to the next step equals stepping into the crucial part; after this change is completed your eMail, Lync and – if chosen – website URL will be redirected to Office365. Admittedly, in both cases I only chose “eMail and Lync” for migration, which means that the website remained with the ISP – for now … As the penultimate step after having chosen the services that you want to switch over, Office365 gives you a list of records that need to be entered as DNS records with your domain.

Let’s have a brief look into those DNS records as they are the ones that eventually bring your migration to life:

  • MX records: This is, normally, one record that identifies where the eMails with the domain in question shall be routed to (to: name@yourdomain.tld). No rocket science here and getting that into your DNS shouldn’t be a bummer, really.
  • CNAME records: The most important of these is the “autodiscover” record. I’d argue this to be the “most compulsory” one. Not having “autodiscover” set into the DNS of your domain means that any eMail client will not be able to discover the server for the respective user automatically, i.e. users will “pull their hair out” over trying to configure their mail clients for their Office365 Exchange account. In all honesty, I actually was not able to find a possibility to figure out the correct mail server string for outlook for our users as it contains the mailboxID (being a GUID@domainname.tld; if anyone of you out there knows one, can you please drop your solution as a comment). So, without the “autodiscover” record, you’ll be pretty lost, I think – at least with mobiles and stuff … The other CNAME records are for Lync and Office365 authentication services. Here‘s a pretty good technet article listing them all.
  • The SPF TXT record helps preventing your domain being used for spam mailing
  • And finally, 2 SRV records are for the Lync information flow and enabling SIP federation

[update] Here’s some hints on how we got Lync to work for our accounts, but for eMail, of all the records above the MX would be fully sufficient; I’d just once more emphasize “autodiscover”, as this caused us some headache, because …

3. What do you do, if your ISP does not add “autodiscover”?

As explained above, one’s in bad shape, if an ISP refuses to add the “autodiscover” CNAME record demanded by Office365 for a custom domain. In the case of “1und1” this was exactly what ran us into troubles. However, there’s a pretty simple solution to it, but to begin with – here’s some things that don’t work (i.e.: you don’t need to dig for them):

  • Enter CNAME records into the respective PCs hosts file: Normally a hosts file can be used locally to replicate a DNS – but only for resolving names to IPs, not for CNAMEs.
  • Install a local DNS server: Might work, but seemed like some more work. I didn’t want to dive into this for one little DNS record.
  • Find out the mailbox server for manual configuration: Well – as said above: I didn’t succeed in due course.

Finally @katharinakanns found the – utterly simple – solution by just asking the world for “autodiscover 1und1“. So here’s what probably works with any petulant ISP:

  • create a subdomain named “autodiscover.yourdomain.tld” with your ISP (normally, every ISP allows creation of unlimited subdomains)
  • create a CNAME record for this new subdomain and enter “” as its value/address portion
1und1 CNAME for subdomain setting

The CNAME config screen again – and now we’re fine with checking the box at the bottom

Done. This is it. Mailclients discovered the correct mailserver automatically and configuration instantly became a matter of seconds 🙂

[update] 1und1 has updated there domain dashboard, hence config is easier now – find hints here!


{feature image from Ken Stone’s site – I hope, he don’t mind me using it here}


Published by:

Tension or Suction?

What was it, that made you learn best, back in school? Was that when you were totally captured by a topic or the way it was presented by your teacher? Or was that when your parents stood behind you (virtually “with a stick”) giving you a hard time by pushing you to do your homework?

Yesterday, I read the following in some article: “[…] which are closely related and characterized by constructive tension […]”. That resonated. “Constructive Tension” – What is this really? How can “tension” be “constructive”? How would anyone think of “tension” to be the driving force behind an initiative and imagine that it can be created to be “constructive”?

It was some 12 years ago – commencing into my people management years – when I learned to adopt a principle – first theoretically, later by literally experiencing it in my daily job: “Suction instead of Tension” *). That is why I instantly believed that “constructive tension” cannot exist. Here’s why:

  1. Tension is a force – physical or emotional – that leads to strain. Strain is in no case a constructive feeling – rather destructive.
  2. Goals, outcomes, deliverables, … targeted by applying tension to the actors are normally either not achieved at all or are not perfect. At least, they are not sustainable. Accepting imperfect or non-sustainable results to an initiative is like accepting to be second best. Hence, applying tension in the assumption that it might be constructive is accepting tension for the benefit of its constructiveness over first-class awesomeness of an initiative and its outcome. Noone would really wanna do that.
  3. People loaded with tension steadily float into a state of sneaking demotivation. The constant personal pressure put on them by the tension applied to the respective initiative may lead to some positive results but experience shows that in the long run people get less productive, less motivated and less constructive – eventually leading to an all-time motivational “low”, fully disabling them to yield great results. Rather destructive than constructive, that is.

Bottom line: There is no such thing like “constructive tension”. It cannot exist. By definition. It is a paradox in itself.

The only constructive force supporting personal motivation and thereby leading to utterly perfect results and a sustainable, positive outcome of an initiative is “suction”. By creating a culture of intrinsic motivation, self-responsibility, involvement and identification with a goal, mission, vision and strategy, people will work their axxxx off to achieve the utmost perfection and exceed any goals set. I have experienced “suction moments” in teams which have enough force to blow you away and leave you standing in awe about what is possible if the motivation is just right.

You can reach beyond any all-time high if not tension is your pushing force, but a culture of “suction” is your guiding path!

*) in German: "Sog statt Druck" - which is one of those rare cases were the German language offers the better flow
Published by:

Mind: DevOps isn’t a role model!

This blog post (“How ‘DevOps’ is Killing the Developer”) airwaves a bit at the moment. It reached me right at some really cool, breakthrough conversations on how DevOps will lead change of culture and role perception … and it fully truly nailed the opposite of those highly positive talks. To say it in the words of one of the commenters: “I couldn’t disagree more!” I even would go as far as to consider it dangerous!


Because the post reflects a totally wrong perception of DevOps! The article claims that DevOps would transform the role and responsibility of a particular person – a developer in this case. I would be surprised if literature really postulates this – the change of a role. DevOps is the transformation of HOW things are done, not WHO does it. Firstly, you have to lay the basis for a DevOps company transformation. Do developers change their expertise by that? No. Do OPS guys do? Neither. BUT: They do get closer together, get better understanding for each others challenges.

Secondly: The post misses another highly important – maybe the most important – investment along with DevOps introduction: Automation! Along with the cultural change, you’ll have to invest in automation of processes for artefacts which would formerly have taken you days and weeks to create/setup/deploy/run.


So – let’s be clear here: DevOps isn’t the change of a role! DevOps is a 90° turn of a modus operandi. The whole movement derives from manufacturing where the importance lies in getting rid of any blocker in a production pipeline. Neither would a continous production change the role of the screwmaster (to name just anything) nor would DevOps change that of a QA expert or buildmaster … or – well: developer (as exemplarly taken here)!

The article is dangerous in another aspect: It claims developers to concentrate on development and nothing else. It is – but – another important aspect of DevOps as a cultural tranformation: To bring understanding for everybody else’s responsibility in the process to everybody. And thereby encourage Automation even more to take its place in it all. This importance is totally missed out in the post!

Bottom line

Let’s be crystal clear on a few things with DevOps:

  • It’s a cultural and organizational change; not a role and responsibility change for single individuals
  • It is a 90° turn of a modus operandi. It turns vertical silos of responsibility and action into horizontal pipelines/chains of continous work-flow
  • It’s a way to create role and responsibility awareness throughout the whole chain of collaborating individuals
  • And it surfaces the need of Automation to support cultural and process transformation, stability, security, repeatability, speed, continuity, …

There’s – however – a really positive DevOps-supporting aspect in that post: It does indeed drive discussion into a good direction … just browse through the comments there … 😉


( This post was also published in the official Automic company blog: )


Published by:

From bottom to top much can be lost

I’ve not been here for long. Not because I wouldn’t have had things to say – I actually had to say a lot, but it all went into our company’s architecture documentation. 100s of pages of high level designs, dependencies, relations, segregations, inputs, outputs, … and all of that boring stuff. Down the track of this work, one of the most important conversations with stakeholders and builders all-the-same was the one of the

Bottom-up versus top-down approach

Obviously – as with everything in life (well: nearly everything) – there’s 2 approaches to create blueprint documents/specifications and build the needed services accordingly: Bottom-up and top-down. In our case, the question arose wrt the framework of delivery support systems (operations support as well as business support systems) and the process of building/integrating them.

How to bottom-up or top-down?

The bottom-up approach focuses first on a few requirements to be defined in order to set expectations, then builds the stack according to the respective phase’s needs and derives the definitions accordingly. This approach is more “chaos” and ad-hoc driven and might serve a demo-led approach; at the same time it bears a few significant risks:

  • effort and cost consumption without properly defined product and architecture strategy
  • build and throw-away effects due to late findings
  • build and accept; i.e.: a prototype might be considered more mature than it actually is (under the hood) which would later result in very poor and endangering service quality
  • increased effort for keeping information through working teams synced
  • missing the point where neither the architecture not its Operations scale anymore and where a change of approach/setup is necessary (especially wrt OPS)

While the bottom-up approach clearly has the advantage of more rapid delivery and market-entry, it seriously endangers technical debt to be created:

Technical Debt (as defined by Ward Cunningham):

“If we failed to make our program align with what we then understood to be the proper way to think about our fin objects, then we were going to continue to stumble on that disagreement which is like paying interest on a loan.” – Ward Cunningham (

Hence, as a pre-requisite for this approach to be working, one must seek upfront clarity about

  • which ecosystem/framework services to build
  • around which products
  • which relations to create – and (!) maintain

which within the top-down approach might evolve and shape during the pyramid’s first layer. The top-down approach also has the advantage of an all-know-all effect which can allow for utmost work parallelity while at the same time ensure compatibility of built entities. Its risk – however – is first and foremost the late creation of content/deliverables, hence later demo, later feedback, later market-entry, etc…


Additional complexity is added when building the above in phases; i.e. from limited functionality offered to a limited amount of users in a first phase (e.g. Alpha) to offering full functionality at the final V1.0 release.

NOTE: Assuming a fully balanced build process, I would highly recommend a kanban-style build approach beginning with version 0.1 of the product or framework; assuming that fully balanced process, continous enhancements through continous deployment on a high patch/upgrade rate per day/week/month would be possible. However, even with that balanced process, the following is applicable allthesame.

Both approaches can be driven in a phased-mode in more or less the same way; i.e. in none of the 2 the full set of specifications (or backlog entries respectively) need to be created in order to start into the pyramid’s next layer. It is sufficient to create as much content as for a particular phase needed.

In both phases – though – it is essential to have a basic set of guidelines (like e.g. segregation of duties, purpose of buildling blocks) crystal clearly created so that anybody within any working team is able to align his/her work with these guidelines, perceive, recognise and acknowledge deviations and understand where alignment with other parties is crucial for ongoing success. It is the purpose of the first set of specifications to ensure these guidelines and clarity.

“… the whole debt metaphor or lets say the ability to pay back debt and make the debt metaphor work for your advantage depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem.” (


Published by:

Why not Cloud?

Edward Snowdon is causing us another headache about privacy and data protection. Even though he didn’t even narrate disruptive stuff. Those pretending surprise about the NSA investigating our utmost private data (which we share in the internet) have probably ceased to think about the US’s proclaimed intention to reveal and chase all terrorism in the world (by whatever means it takes). Folks – one thing upfront: The Patriot Act isn’t new!

What obviously really hits us here is the fact, that so far nobody really thought that the capabilities and technical resources to do that investigation efficiently are available (i.e. Big Data Analytics is not slideware anymore – trend followers out there: face it!)

And what’s the consequence? A new wave of discussion whether moving data into “the cloud” is really wise? The wisest thing to meet this discussion is to clear up with a few facts.

So, spend a few minutes and think about the following questions, if you will:

Do you send email?

If you’re in a company (or if you are a company), you may claim now that you send your email from an on-premise mailserver. Good. Whom do you send mail? Only to parties on other on-premise mailservers? Encrypted? End-to-end? I don’t want to argue to move your mail server into the cloud; this wouldn’t make a difference for the question discussed. What I’m emphasizing is the fact, that every attachment that is sent unencrypted through an unencrypted channel could be listened to and caught by any party interested. Without any cloud provider being involved. 10 years ago already.

Now, what is the real problem here?

The real problem is that the vast majority of email senders don’t give a shit on which channels their information traverses. In 90% of the cases this isn’t even a problem, as nobody really cares about the 127th slide deck proposing a better life when shared with 10 friends. Even not the NSA. The remaining 10% cause a problem if compromised. No matter if sent through a cloud provider or your server in your own cellar.

Do you use a social network?

No? Then forget about this question!

If yes, whom do you communicate with in it? And what? Personally, I don’t know any relevant social network owned by a provider outside the US (or not co-located within US boundaries). I.e.: you’re trapped if you use it. Except – well — except we’re talking about a company social network hosted behind your employer’s firewall. You might be trapped in another way here, but that’s a different story. Hence, it is applicable to say that sharing information within a social network which could use its (your!) data for analysis or open its data to be transferred and analysed by anybody else means opening trackable information about yourself and what you do.

But what is really the problem here?

It’s again the information you share, the information others share about you and the information others share with you without your permission or control; be it your home address and holiday absence or your latest invention you talked about with your friends over a beer. In other words: The real problem is not the cloud as such but what you share with it and how you (can) control openness and transparency (this could – by the way – be a problem with your company social media tool as well).

Do you exchange documents apart from mailing them around?

A company will for sure have already introduced a mature, secured and company compliant private dropbox service (what if not, is subject to another post; well, actually it’s rather boring to repeat what happens when employees need a dropbox and find blocked). But what if you intend to leverage x-company collaboration? Without blowing mailboxes or having the documents lying around in public unsecured mailservers? Rent a cloud collaboration service supposed to be more secure and reliable than any employees uncontrolled dropbox account. Or get your IT to setup an extranet service to collaborate with your external partners (including a lengthy process to add more collaborators to it).

Is this the real problem here?

In a way, yes. It is the move into x-company collaboration that causes headaches for your IT. You could solve this by simply avoiding any open service supporting such collaboration, in which case you can easily skip cloud (and the collaboration itself, too; congratulations; case closed). Or by accepting the duration for adding collaborators to your extranet. Or by using eMail (see above ;)).

Do you use a mobile phone or tablet PC?

If not, forget this paragraph, too?

If yes, you may probably use apps which go beyond email, facebook or the weather forecast. A photo app e.g.; to share a quick scan of some doc page or some instant messaging tool (whatsapp?). I reckon you do know the vendor of your instant messaging app on your mobile phone and he transparently explained to you where your communication threads are stored and which investigation means he offers international homeland security. And of course these means are in line with your privacy expectations. Are not? Well …

So, what’s the real problem here?

Flexibility. This is what poses the challenges. Fewer people are willing to exchange mobilitiy and work-life flexibility against lock-downs for the benefit of security. Which again essentially results into thinking about what to share, controlling the apps respectively and managing the mobile devices to lock them down or wipe them in case of compromising.

So, face it:

Cloud is not black or white.

Moving data into the cloud isn’t a question of “like” or “dislike”. When servers, networks, the Internet, … evolved from mainframe computers (some time ago), IT bent into a path of openness. Today, something has not become less secure just because of the 3rd Industrial Revolution we are facing.

To claim that moving company data into the hands of a cloud provider means to make it open to anybody is equally stubborn as stating that an email sent from (a) to (b) means to make its content available to the whole internet. It is true for certain ways of transporting that mail. And for these ways it was true already some decades ago. Not only now.

Hence, a mature cloud provider would make its service secure, confidential and (most of all) transparent. With that in mind there’s no real way of stopping the move.


Here’s a nice one about transport security and about it being compromised and how:

Published by:
%d bloggers like this: