Set the folder name language for shared mailboxes in Office 365 with powershell

Recently I created a shared mailbox (a support mailbox). This mailbox showed up in German Outlook with English folder names like Inbox, Drafts, …

The newly created mailbox didn’t have had any language settings assigned to:

PS C:\> get-MailboxRegionalConfiguration -id
Identity Language DateFormat TimeFormat TimeZone
-------- -------- ---------- ---------- --------

This seens to be a default for Outlook. Using the OWA-frontend you are able to change your language and settings for the folder names but this setting does not seem to be reflected to shared mailboxes.

Looking at this support entry, there’re several options to handle this issue. After trying all possibilities, I ended up using the powershell approach (method 3 of the support document) as all other methods didn’t worked out for me. Therefore I followed several documents to run powershell modules for exchange (both for my tenant as also for the partner’s tenant).

Therefore he we are:

  1. Connect to the Office 365 session
  2. Download the session
  3. Set the language settings for the shared mailbox.

1. Connect to office 365

Depending on your demand, you have two options:

  1. Connecting to your account can be achived by following Connect to Exchange Online PowerShell on Microsoft docs.
  2. Connecting to your client’s account by following 
    Connect to Exchange Online tenants with remote Windows PowerShell for Delegated Access Permissions (DAP) partners

2. Import the session

The next step is to import the session (assuming that the above steps are successfull and the session created is using the variable name $session:

Import-Session $session

3. Update your shared mailboxes

After importing your session you can use Get-Mailbox and Get-MailboxRegionalConfiguration command to look for the status of your shared mailboxes:

PS> Get-Mailbox | Where-Object {$_.RecipientTypeDetails -eq "SharedMailbox"} | Get-MailboxRegionalConfiguration
Identity Language DateFormat TimeFormat TimeZone
-------- -------- ---------- ---------- --------
Support de-DE dd.MM.yyyy HH:mm

As you can see, the mailbox “Support” has already the language set to “de-DE”.

For the other mailboxes you may set the language by using the following command:

PS> Set-MailboxRegionalConfiguration -id -LocalizeDefaultFolderName:$true -Language de-DE

By using  Get-MailboxRegionalConfiguration you will see the results…

PS> Get-MailboxRegionalConfiguration -id
Identity Language DateFormat TimeFormat TimeZone
-------- -------- ---------- ---------- --------
Demo de-DE dd.MM.yyyy HH:mm

Done 🙂 Restarting outlook should display all folder names with the correct language.



Protecting your customer … from unnecessary requests

Today I stumbled over a twitter post:

This one is referring to the “product deathcycle”. This picture shows one part of the problem. Another part are requirements which cause the customer to be unhappy about you (the vendor). Every business analyst or requirements engineer knows about those customer demands.

So… Why are some requirements worse than others or why do they even harm the relationship to you.

IMHO requirements that are creating “un-happiness” are those which solve the problem that was on top of the customers mind while the key account (or business analyst) was visiting the customer. I’ve seen so many occurrences where a key account came back from the customer site with dozens of new ideas where most of them are “urgent”, “out of discussion”, “essential for our users” or even “important for our relationship”. Anyhow, the last one is somewhat an exception because that is usually a request to get something for free ;).

What is happening here that most of those urgent requirements result out of a single incident or escalation currently on the desk of the customer. If you solve this problem (probably included in a release several month later) it is out of the customer’s mind and usually therefore not urgent anymore.

Try to evaluate (together with the customer or through experience) if the customer’s requirement is a lasting one (no one time shot, really required and not part of a single escalation). In any other case try to see if the requirement can be

  • cancelled in the first place (i.e. convince the customer that he doesn’t need this requirement),
  • replaced by something the customer really demands (is lasting, improves efficiency, …),
  • cancelled during the offer process or
  • (as a last resort) deny to provide an offer for a specific requirement

The latter two ones are usually the ones with the most negative feedback from the customer. They should be avoided by using one of the first two options.

I cannot remember how often a customer came around with an important report the management (or somebody else) demands. After further evaluation the usual cancellation reasons where:

  1. One time demand (results in one day in Excel or two weeks in software),
  2. Exists already in slightly different form and is sufficient or
  3. Can be easily created in Excel with existing reports or data


Using with ASP.NET webforms – A generic approach is a flexible HTML table component used in many applications. Recently (in a large ASP.NET webforms legacy application) we’ve had the need to switch from a commercial product towards a product which is easier to maintain and which does not contain 5000 features where we use only 10 out of them (and some of the others are creating problems).

Using is very easy and requires only limited knowledge on JavaScript in case you are providing table data together with the data to be displayed. You can find tons of examples on the home page.

In case you are going to display data which is

  • hard to generate on the fly (volume, complex queries) or

  • is changing during paging or other table operations

you need to load data from the server even after the page has been requested. The term used in is “server side processing”.

By using a .NET handler class and a generic interface that encapsulates the data provider we’ve generated a solution which can be easily adapted to create a generic data table provider implementation in ASP.NET web pages.

I’ve created a short demo on github that shows the general approach and might help as a base to use an own implementation.

Effective Meetings

After participating a (phone) meeting that was not worth spending the money for the IP traffic, I’ve sent a mail to all participants referring to the following post: Tips for Running Effective Meetings. Some of the folks replied and asked if the infographic is available as text as well… Here we are:

  • Email an agenda 24 hours in advance
  • Arrive 5 minutes early
  • Come prepared
  • Bring paper and a pen
  • Start and end on time
  • Stay on topic
  • No interrupting
  • No smartphones
  • Be brief and concise
  • Share all relevant data
  • No side conversations or comments
  • Disagree without being disagreeable
  • Everyone participates
  • Silence = Agreement
  • Challenge ideas rather then people
  • Follow-up email within 24 hours

Looking at all those points I need to work on some of those points 🙂

The original infographic:

Agile and Enterprises – No Match Found

I’ve just stumbled over an interesting blog entry: Why Agile is failing.

Cyrille shows in a very smart way the problems that I’m facing while selling our software to our customers. We are working internally according to Scrum (it’s actually ScrumBut, but anyhow), but our (enterprise) customers like to work on a strict waterfall model (for the process, not for their ideas :-)).

What is missing is an acceptance of the customers and a smooth migration strategy especially for enterprises to adopt agile methodologies (and not only for s/w development).

As long as this problem remains, there’s some kind of mixed mode where we try to handle two methodologies in parallel.

Is this task appropriate for my job?

One who considers himself too important for small tasks is often too small for important tasks.
(Jaques Tati)

ImageOnce in a while there’s a discussion where people are asking: “Is this task appropriate for my job?” (or role, assignment, or whatever) while they have to perform a specific task that seems to be a little bit outside their usual business.

Well, when we would live in an ideal world this question would be right and I would answer: “Yes, you are right. That’s not supposed to be your job. I’ll find the correct person/team to address this topic”.

Coming back to reality (especially while working for a project oriented company where the “start-up spirit” should still be the favorite way of working), statements like these would kill your business. Continue reading “Is this task appropriate for my job?”

I18n: Parsing Decimal values

At Tideum and for TimeJack we are developing line of business applications which usually handle numbers. As we are developing our software for international markets we usually face the problem of users entering numbers in a format that is not the same as the current locale (e.g. Germans are entering numbers in English locale and vice versa). This happens very often if data is copied from 3rd party applications (e.g. SAP or Excel).

Parsing those numbers with the standard .NET functions (aka. Decimal.Parse()) is parsing only a fixed language, e.g.

string source = "123,45";
decimal value = Decimal.Parse(source);

depends on the current thread culture settings. In case the current settings are “de-DE” (or “de-AT”), the conversion will return value == 123.45, for “en-US” value == 12345 will be returned and for “de-CH”/”fr-CH” a System.FormatException is thrown.
Continue reading “I18n: Parsing Decimal values”