<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Hello All<br>
_ _ <br>
<br>
This notice has very little to do with the normal proceedings of a
group happily focussed on *nix.<br>
<br>
HOWEVER .. <br>
many of US do service Customers outside that happy world<br>
.. and .. Redmond hath spoken .. and ..<br>
_ _ <br>
<br>
Many of our Customers have been receiving MTS notices recently,
about "CHANGES". <br>
<br>
There is suggestion of a "window" to respond to a transit/MIGRATE
away from the current [ms-withdrawn] email service, to MTS/Alliance
-hosted service, now called "MTS Mail". <br>
<br>
( Does this ring a bell ? <br>
Yes. <br>
Only four years back. <br>
Let's not go into those old, buggy extrusions .. for now.)<br>
<br>
Today's (2015-02-28) WpgFreePress had a G.Kirbyson article, quoting
a MTS/Alliance honcho<br>
" ..
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
Melanie McKague, director of corporate communications and community
investment .. "<br>
saying there is a "slick tool" ON THE WEBSITE. <br>
<a class="moz-txt-link-freetext" href="http://www.winnipegfreepress.com/business/frustratingmtsnet-292868671.html">http://www.winnipegfreepress.com/business/frustratingmtsnet-292868671.html</a><br>
<br>
This came as some surprise to an internal source, with whom I spoke
this (28th) evening. <br>
<br>
I had entertained a call from (more than) one client - to help with
transition. <br>
So, I showed up at one customer's site tonight. <br>
I am not cheap. <br>
No such "tool" was to be found. <br>
This made things UNCOMFORABLE, to say the least. <br>
<br>
And that, from all of our-side good intentions, adequate advance
notice by MTS/Alliance emals to so many, to the subject, AND today's
major-media publication, SAYING THERE WAS A TOOL ON THEIR WEBSITE. <br>
<br>
Our very helpful MTS/Alliance tech (sshh:Thomas), whom I was able to
contact later in the evening's sortie, said he [paraphrase]
<<had instructions to "not encourage" use of that tool>>
for MOVING EMAIL OFF MS, onto MTS/Alliance's new scheme. <br>
<br>
YET.<br>
<br>
He also invited a [forward] of the clients (there are more than one)
who received emails describing "15 days" .. "window deadline" ..
etc. <br>
<br>
Go ahead .. waste your time on the rather wordy, ostensibly helpful
FAQ page at MTS/Alliance. <br>
<br>
[Yawn]<br>
<br>
THERE IS NO DIRECT LINK, <br>
as of this last evening (Feb.28) <br>
TO ANY SUCH TOOL, <br>
contrary to the FP interview's MTS contact's statement (her word
"slick" may resonate). <br>
<br>
BESIDES: There will be numerous reasons for us to hold back from
"jumping on" with any transition tool, if our experience(s) with up
to 3rd iteration/revision of "helpful tool" from 4yrs back, would be
any indication. <br>
<br>
This unilateral withdrawal of service by <br>
<<golden opportunity outsource>> [quote:cca2010] <br>
Microsoft .. from hapless, trusting-in-outsource victim/sucker
MTS/Alliance<br>
is actually deadlined (beside local discussions of "window")<br>
for the end of 2015.<br>
<br>
NOW, we, in jeopardy, in practical terms, should expect the real
window, before [further unilateral] withdrawal of this ill-fated
proxy delegation, should be a bit short of that. <br>
<br>
I will encourage my people to observe, patiently, at least a month
of commentary about whatever "slick tool" is on offer, as to how it
succeeds in data migration, before we attempt any transition. <br>
<br>
I DO NOT SUGGEST "WE" BECOME SUCH A FORUM .. although I would look
to "our" discussion before many others' discussions.<br>
<br>
I immediately took an inventory of [my clients in the range of]
people I expect to help through this horrid [re-]imposition. <br>
<br>
MANY are NOT INDEPENDENT of WHERE THEIR EMAIL DATA RESIDES. <br>
By this, I mean that Enough of those people happened to trust the
rather <br>
big service providers (MTS/Alliance, Microsoft) <br>
and STAYED WITH REMOTE ACCESS (webclient) meaning REMOTE DATA. <br>
MEANING they will have to RELY ON A MIGRATION TOOL, should they
"need" their email data to survive [again]. <br>
<br>
Of course, real transitions, especially for such IMAP, or POPx
clients, who do not use local clients (who do not have full copy at
a local station), will have to be CAREFULLY MANAGED. <br>
<br>
TheEasySide: Should you have a customer using <br>
(across the board of their nway field of mtsEmailClients) <br>
Local Clients <br>
[meaning local client (e.g:TBird on POPx) has recently fetched all
traffic / all content]<br>
then you need worry less about Data in the transition.<br>
Simply change your source links' parameters, on a slow night/wknd. <br>
<br>
IN ADVANCE, should you choose to move your clients to a local-client
(local data) scheme, like Thunderbird, then after the initial
huge-sync, you only have to manage any duplicate fetch-stations, and
either make them all say "Leave Data On Server", or pick a station
to be BossOfEmail.<br>
<br>
If your customers have been using MS' webclient or other MS-approach
- YOU WILL NEED TO CAREFULLY perform the "eventual" MTS migration
tool procedure.<br>
<br>
[sigh]<br>
<br>
John D<br>
</body>
</html>