Note 1:
Please see
the details
on http://www.microsoft.com/technet/year2k/product/product.htm
for the
latest
information
on Windows
NT Server.
Exchange is
Compliant
when used
with the
Compliant or
Compliant#
version of
Windows NT
Server. This
included
Windows NT
Server 4.0
SP3 with the
latest hot
fixes.
The
Microsoft
Exchange
Server will
operate in
the minimum
range of Jan
1, 1970 -
January 19,
2038. In
many cases
the
Microsoft
Exchange
Server will
operate in
ranges that
extend far
beyond their
parameters
and stretch
the range
from 1601
through
60055.
This
document
covers all
of the
Microsoft
Exchange
components
and
discusses
the way
these
components
function
together and
use dates.
The document
covers all
products
that are
included in
the
Microsoft
Exchange
Server
Enterprise
edition, or
that can be
purchased
separately.
In addition,
it covers
the
individual
components
that can be
added to the
Exchange
Server
Standard
edition. All
components
combined
together are
referred to
as Exchange.
There are
individual
components
that may be
called out
specifically,
in order to
give more
details on
how they use
dates or how
some
features
should be
tested. Year
2000
information
for the
Exchange
clients and
Outlook are
covered in
their
corresponding
documents.
What are
the
prerequisites?
Exchange
4.0 is year
2000
compliant
when used
with Service
Pack 5
(SP5).
How can
the customer
make the
product
compliant?
Exchange
4.0 SP5 is
located on:
ftp://ftp.microsoft.com/bussys/exchange/exchange-public/fixes/Eng/Exchg4.0/SP5
This is
the location
of the
English
version.
French
(FRN),
German (GER)
and Japanese
(JPN) are
located in
the
corresponding
directories
at ftp://ftp.microsoft.com/bussys/exchange/exchange-public/fixes/
When the
service pack
5 is
installed,
Exchange
Server 4.0
is year 2000
compliant.
Description
of Date
Handling:
Listed
below are
the major
components
of Exchange
and how each
handle
dates.
Microsoft
Exchange
Server
Database :
The
Extensible
Storage
Engine and
the Exchange
Server
Database
Engine are
year 2000
compliant.
The internal
date range
in years
from 1900 to
2156. Jet
uses the
JET_LOGTIME
structure.
Date/Time
structures
the Exchange
Server
Database
Engine uses:
JET_LOGTIME
structure (8
char's
(bytes)
representing
date-time)
Year is
encoded as:
char bYear;
Date range
for this
structure
is: 1900 -
2156
Microsoft
Exchange
Information
Store (MDB):
Internally
the
information
store stores
all year
dates in 4
digits using
the types
FILETIME or
SYSTIME.
There are a
few cases in
which the
information
store
accepts a 2
digit year
in those
cases where
other
components
hands the
MDB an
internet
standard RFC
822 message.
In this case
the
information
store stores
these dates
as the
number of
seconds
since Jan 1st,
1986. This
gives the
information
store a
range to of
1986 û
2085.
In the
cases where
dates are
passed to
the
information
store as a
UTC_TIME
string, the
Exchange
Information
Store will
convert the
two digits
using 1951
as the cut
off for the
range. If
the year is
in the range
51-99 the
date is
converted to
be
1951-1999.
If the year
is in the
range 00-50,
the date is
converted to
2000-2050.
Date/Time
structures
the Exchange
Information
Store uses:
Filetime
structure
(two DWORDs
representing
# of 100ns
intervals
since
1/1/1601)
| |
Qword
|
|
Base
Unit
|
1.84467E+19
|
|
Seconds
|
1844674407371.0
|
|
Minutes
|
30744573456.2
|
|
Hours
|
512409557.6
|
|
Days
|
21350398.2
|
|
Years
|
58454.2
|
|
Max
Date
|
60055
|
Date
range for
this
structure
is: 1601 û
60055,
however due
to internet
standards
that only
support
2-digits,
the MDB has
to do the
correct year
2000
conversion
and supports
a range of
1986 û
2050.
Active
Messaging
and MAPI:
Active
Messaging
and MAPI
uses a
64-bit
FILETIME.
Any Active
Messaging or
MAPI
applications
written that
pass in a
year 2000
compliant
date will be
stored
correctly
within
Exchange.
The internal
date range
in years
from 1601 to
60055.
Date/Time
structures
MAPI uses:
Filetime
structure
(two DWORDs
representing
# of 100ns
intervals
since
1/1/1601)
| |
Qword
|
|
Base
Unit
|
1.84467E+19
|
|
Seconds
|
1844674407371.0
|
|
Minutes
|
30744573456.2
|
|
Hours
|
512409557.6
|
|
Days
|
21350398.2
|
|
Years
|
58454.2
|
|
Max
Date
|
60055
|
Date
range for
this
structure
is: 1601 -
60055
Microsoft
Exchange
Message
Transfer
Agent (MTA):
The
Exchange MTA
is a X.400
standard
MTA. X.400
itself is
not year
2000
compliant.
The ASN.1
type UTCTime
defined by
ISO/CCITT
uses a
2-digit date
format for
years. An
example of a
UTC time
format is
980128131030Z
which stands
for
1/28/1998,
1:10:30pm,
zulu (GMT)
time.
When
these ASN.1
dates come
in from
other
systems MTA
converts
them from
the UTC
format to
determine
the century.
If the year
is in the
range 50-99
the date is
converted to
be
1950-1999.
If the year
is in the
range 00-49,
the date is
converted to
2000-2049.
Date/Time
structures
the MTA
uses:
ASN.1
string is
any of the
following:
This is the
format used
for X.400
standards.
/* UTC
FORMAT TIME
:
YYMMDDHHmmZ
*/
/* OR
YYMMDDHHmmssZ
*/
/* OR
YYMMDDHHmmXhhmm
WHERE X IS
"-"
OR
"+"
*/
/* OR
YYMMDDHHmmssXhhmm
WHERE X IS
"-"
OR
"+"
*/
UTC_TIME
string (two
digit year)
980128131030Z
stands for
1/28/1998,
1:10:30pm,
zulu (GMT)
time
Date
range for
this
structure
is: 00 û
99, however
due to X.400
standards
that only
support 2
digit dates
the MTA has
to do the
correct year
2000
conversion
and supports
a range of
1970 û
2038.
Microsoft
Exchange
Directory
(DSA):
The
Exchange
directory
service uses
X.500
industry
standards
which store
dates in UTC
time
formats. UTC
time format
uses 2
digits to
represent
the year of
each date.
An example
of a UTC
time format
is
980128131030Z
which stands
for
1/28/1998,
1:10:30pm,
zulu (GMT)
time.
Internally
these dates
are stored
as a 4-byte
int counting
the number
of seconds
since
January 1st,
1970. Thus
the date
range of DSA
is January 1st,
1970 through
January
19th, 2038.
When these
dates come
in from
other
systems or
components
the
directory
converts
them from
the UTC
format to
determine
the century.
If the year
is in the
range 50-99
the date is
converted to
be
1950-1999.
If the year
is in the
range 00-49,
the date is
converted to
2000-2049.
Date/Time
structures
MAPI uses:
UTC_TIME
string (two
digit year)
980128131030Z
stands for
1/28/1998,
1:10:30pm,
zulu (GMT)
time
/* UTC
FORMAT TIME
:
YYMMDDHHmmZ
*/
/* OR
YYMMDDHHmmssZ
*/
/* OR
YYMMDDHHmmXhhmm
WHERE X IS
"-"
OR
"+"
*/
/* OR
YYMMDDHHmmssXhhmm
WHERE X IS
"-"
OR
"+"
*/
Date
range for
this
structure
is: 00 û
99, however
due to X.500
standards
that only
support 2
digits the
DSA has to
do the
correct year
2000
conversion
and supports
a range of
1970 û
2036.
Microsoft
Exchange
Administrator:
The
Exchange
Administrator
program has
to be able
to
administer
X.400 and
X.500
components.
To do so it
has to be
able to
support
ASN.1 and
UTC time
standards.
Both of
these
standards
store the
year date
values in
two digits.
An example
of an ASN.1
and UTC time
format is
970128131030Z
which stands
for
1/28/1998,
1:10:30pm,
zulu (GMT)
time. When
the
Administrator
program uses
these dates
it converts
them into 4
digits when
needed. If
the year is
in the range
50-99 the
date is
converted to
be
1950-1999.
If the year
is in the
range 00-49,
the date is
converted to
2000-2049.
Date/Time
structures
the
Administrator
program
uses:
ASN.1
string is
any of the
following:
This is the
format used
for X.400
standards.
/* UTC
FORMAT TIME
:
YYMMDDHHmmZ
*/
/* OR
YYMMDDHHmmssZ
*/
/* OR
YYMMDDHHmmXhhmm
WHERE X IS
"-"
OR
"+"
*/
/* OR
YYMMDDHHmmssXhhmm
WHERE X IS
"-"
OR
"+"
*/
UTC_TIME
string (two
digit year)
980128131030Z
stands for
1/28/1998,
1:10:30pm,
zulu (GMT)
time
Date
range for
this
structure
is: 00 û
99, however
due to
internet and
X.400
standards
that only
support 2
digits the
Administrator
program has
to do the
correct year
2000
conversion
and supports
a range of
1970 û
2038.
Microsoft
Exchange Key
Management
Server
(KMS):
The KMS
server
explicitly
uses 4
digits to
represent
years for
all storage
of dates.
The UTC_TIME
string is
used, but
only for
keeping
track of
when a cert
is issued.
Since the
certs are
internally
tracked by
minutes and
hours the
year digits
as part of
the date are
not used,
there for
there are no
issues
making KMS
year 2000
compliant.
All
levels of
encryption
were tested
to verify
year 2000
compliance.
This
includes
testing with
languages
that support
different
levels of
encryption.
Microsoft
Exchange
Internet
Mail Service
(IMS):
The IMS
stores dates
internally
as a
FILETIME
structure.
This is a
64-bit value
representing
the number
of
100-nanosecond
intervals
since
January 1,
1601.
Messages
that are of
the format
RFC 822,
that come
into the
IMC, are
handled by
IMAIL and
the
information
store. RFC
822 messages
store date
formats with
2 digits
representing
the year.
See
Microsoft
Exchange
Information
Store for
more
information.
When the IMS
is setup as
a connector
it reads
information
from the
GWART. See
MTA for more
information.
Date/Time
structures
the IMC
uses:
Filetime
structure
(two DWORDs
representing
# of 100ns
intervals
since
1/1/1601)
| |
Qword
|
|
Base
Unit
|
1.84467E+19
|
|
Seconds
|
1844674407371.0
|
|
Minutes
|
30744573456.2
|
|
Hours
|
512409557.6
|
|
Days
|
21350398.2
|
|
Years
|
58454.2
|
|
Max
Date
|
60055
|
Date
range for
this
structure
is: 1601 û
60055,
however, due
to internet
standards
that only
support 2
digits, the
IMS has to
do the
correct year
2000
conversion
and supports
a range of
1970 û
2038.
Microsoft
Mail
Connector
Interchange
(MSMI):
All dates
going to
Exchange via
MSMI in the
P1 Envelope
of a message
are mapped
to XOM
objects of
syntax
OM_S_UTC_TIME_STRING
which is a
string
presentation
of the ASN.1
UTC time
syntax used
by the MTA.
UTC time is
a 2-digit
year so the
century is
dropped
going to
Exchange and
the MTA
interprets
the date
into a
4-digit
year. See
the MTA for
details.
Dates from
Exchange in
the P1
envelope are
ignored and
dropped.
All dates
going
to/from
Exchange in
the content
of a message
are mapped
to/from MAPI
PT_ SYSTIME
properties
of MAPI type
PT_SYSTIME,
see MAPI for
details.
PT_SYSTIME
encodes the
year
unambiguously.
All dates
going
to/from MS
Mail and
downstream
foreign
systems via
MS Mail
gateways are
mapped
to/from the
MS Mail FIPS
date/time
format. This
is a 4-digit
year format
and is
unambiguous.
Date/Time
structures
MSMI uses:
ASN.1
string is
any of the
following:
This is the
format used
for X.400
standards.
/* UTC
FORMAT TIME
:
YYMMDDHHmmZ
*/
/* OR
YYMMDDHHmmssZ
*/
/* OR
YYMMDDHHmmXhhmm
WHERE X IS
"-"
OR
"+"
*/
/* OR
YYMMDDHHmmssXhhmm
WHERE X IS
"-"
OR
"+"
*/
UTC_TIME
string (two
digit year)
980128131030Z
stands for
1/28/1998,
1:10:30pm,
zulu (GMT)
time
Date
range for
this
structure
is: 00 û
99, however
due to X.400
standards
that only
support 2
digits MSMI
has to do
the correct
year 2000
conversion
and supports
a range of
1970 û
2038.
Filetime
structure
(two DWORDs
representing
# of 100ns
intervals
since
1/1/1601)
| |
Qword
|
|
Base
Unit
|
1.84467E+19
|
|
Seconds
|
1844674407371.0
|
|
Minutes
|
30744573456.2
|
|
Hours
|
512409557.6
|
|
Days
|
21350398.2
|
|
Years
|
58454.2
|
|
Max
Date
|
60055
|
Date
range for
this
structure
is: 1601 -
60055
Microsoft
Exchange
MIGRATION
All dates
going into
Exchange in
the content
of a message
are mapped
to MAPI PT_
SYSTIME
properties
of MAPI type
PT_SYSTIME.
PT_SYSTIME
encodes the
year
unambiguously,
see MAPI for
more
information.
Most other
mail systems
use 2-digit
year format.
Migration
converts
this from
the 2-digit
year format
using
different
rules for
each mail
system.
Below are
the rules
for each
system:
System:
Rule:
cc:Mail
DB6:
Add
1900
to
the
year
that
is
passed
from
cc:Mail.
Example:
110
is
passed
in
for
the
year
2010.
MSMail:
The
year
is
passed
in
as
4
digits
from
MSMail.
Example
2010
is
passed
directly
to
Migration.
Date/Time
structures
Migrations
uses:
Filetime
structure
(two DWORDs
representing
# of 100ns
intervals
since
1/1/1601)
| |
Qword
|
|
Base
Unit
|
1.84467E+19
|
|
Seconds
|
1844674407371.0
|
|
Minutes
|
30744573456.2
|
|
Hours
|
512409557.6
|
|
Days
|
21350398.2
|
|
Years
|
58454.2
|
|
Max
Date
|
60055
|
Date
range for
this
structure
is: 1601 û
60055.
Does the
product
support
2-digit
shortcuts
for date
representation?
Yes
What is
the logic
for
converting
2-digit
shortcuts to
4 digits for
the storage
and
calculation?
There are
some
components
within
Exchange
that use
UTC, ASN.1,
X.400 and
X.500
standards
which
require
dates to be
stored in 2
digits. For
these case
any date
that is the
values 50-99
are
interpreted
as
1950-1999.
Values that
are 00-49
are
interpreted
as
2000-2049.
Are there
some common
pitfalls for
use or
testing of
this product
that may
have caused
the customer
to use the
product in a
non-compliant
fashion?
Microsoft
continues to
promote the
utilization
of Internet
standards
within the
Microsoft
Exchange
Server and
continues to
provide
connectivity
other
vendors
messaging
systems. In
doing so
Microsoft
has had to
adapt
Microsoft
Exchange
Server to
convert any
2-digit
dates
received
from and/or
expected by
those Non
Microsoft
systems.
Microsoft
has
confirmed
and tested
the handling
of dates
within the
Microsoft
environment
and in the
passing to
the Non
Microsoft
environment,
however
Microsoft
can not
assure our
customers of
the
compliance
of the Non
Microsoft
receiving
environment.
What are
the
recommended
processes
for
customers to
follow to
better test
the product
in their
environment?
Setup a
test
environment
that
simulates
part of
their
Exchange
topology.
When this is
setup,
change the
system time
on all
servers to
be December
31, 1999.
Then start
sending
messages and
let the date
roll over to
January 1,
2000. Use
any
applications
that may
have been
written to
use the
Exchange
environment.
These are
any
workflow,
GroupWare,
etcà
applications
that the
company uses
to run their
business.
Microsoft
would
recommend
that the
customer
roll forward
the date to
several
various
dates in the
range
12/31/1999-12/31/2009
and test
many
different
scenarios.
