Exchange Server and Update Rollups Build Numbers

Exchange Server Release dates

Product name	Build number	Date
Microsoft Exchange Server 2003	6.5.6944	6/30/2003
Microsoft Exchange Server 2003 SP1	6.5.7226	5/25/2004
Microsoft Exchange Server 2003 SP2	6.5.7638	10/19/2005
Microsoft Exchange Server 2007	8.0.685.24	12/9/2006
Microsoft Exchange Server 2007	8.0.685.25	12/9/2006
Microsoft Exchange Server 2007 SP1	8.1.240.6	11/29/2007
Microsoft Exchange Server 2007 SP2	8.2.176.2	8/24/2009
Microsoft Exchange Server 2007 SP3	8.3.083.6	6/20/2010
Microsoft Exchange Server 2010	14.0.639.21	11/9/2009
Microsoft Exchange Server 2010 SP1	14.1.218.15	8/24/2010
Microsoft Exchange Server 2010 SP2	14.2.247.5	12/4/2011

Exchange Server 2007 Service Pack 1

Product name	Build number	Date	KB
Microsoft Exchange Server Exchange 2007 SP1	8.1.240.6	11/29/2007
Update Rollup 1 for Exchange Server 2007 Service Pack 1	8.1.263.1	2/28/2008	KB945684
Update Rollup 2 for Exchange Server 2007 Service Pack 1	8.1.278.2	5/8/2008	KB948016
Update Rollup 3 for Exchange Server 2007 Service Pack 1	8.1.291.2	7/8/2008	KB949870
Update Rollup 4 for Exchange Server 2007 Service Pack 1	8.1.311.3	10/7/2008	KB952580
Update Rollup 5 for Exchange Server 2007 Service Pack 1	8.1.336.1	11/20/2008	KB953467
Update Rollup 6 for Exchange Server 2007 Service Pack 1	8.1.340.1	2/10/2009	KB959241
Update Rollup 7 for Exchange Server 2007 Service Pack 1	8.1.359.2	3/18/2009	KB960384
Update Rollup 8 for Exchange Server 2007 Service Pack 1	8.1.375.2	5/19/2009	KB968012
Update Rollup 9 for Exchange Server 2007 Service Pack 1	8.1.393.1	7/17/2009	KB970162
Update Rollup 10 for Exchange Server 2007 Service Pack 1	8.1.436.0	4/9/2010	KB981407

Exchange Server 2007 Service Pack 2

Product name	Build number	Date	KB
Microsoft Exchange Server 2007 SP2	8.2.176.2	8/24/2009
Update Rollup 1 for Exchange Server 2007 Service Pack 2	8.2.217.3	11/19/2009	KB971534
Update Rollup 2 for Exchange Server 2007 Service Pack 2	8.2.234.1	1/22/2010	KB972076
Update Rollup 3 for Exchange Server 2007 Service Pack 2	8.2.247.2	3/17/2010	KB979784
Update Rollup 4 for Exchange Server 2007 Service Pack 2	8.2.254.0	4/9/2010	KB981383
Update Rollup 5 for Exchange Server 2007 Service Pack 2	8.2.305.3	12/7/2010	KB2407132

 

Exchange Server 2007 Service Pack 3

Product name	Build number	Date	KB
Microsoft Exchange Server 2007 SP3	8.3.083.6	6/20/2010
Update Rollup 1 for Exchange Server 2007 Service Pack 3	8.3.106.2	9/9/2010	KB2279665
Update Rollup 2 for Exchange Server 2007 Service Pack 3	8.3.137.3	12/10/2010	KB2407025
Update Rollup 3 for Exchange Server 2007 Service Pack 3	8.3.159.0	3/2/2011	KB2492691
Update Rollup 3-v2 for Exchange Server 2007 Service Pack 3	8.3.159.2	3/30/2011	KB2530488
Update Rollup 4 for Exchange Server 2007 Service Pack 3	8.3.192.1	7/7/2011	KB2509911
Update Rollup 5 for Exchange Server 2007 Service Pack 3	8.3.213.1	9/21/2011	KB2602324
Update Rollup 6 for Exchange Server 2007 Service Pack 3	8.3.245.2	1/25/2012	KB2608656
Update Rollup 7 for Exchange Server 2007 Service Pack 3	8.3.264.0	4/16/2012	KB2655203

Exchange Server 2010

Product name	Build number	Date	KB
Microsoft Exchange Server 2010 RTM	14.0.639.21	11/9/2009
Update Rollup 1 for Exchange Server 2010	14.0.682.1	12/9/2009	KB976573
Update Rollup 2 for Exchange Server 2010	14.0.689.0	3/4/2010	KB979611
Update Rollup 3 for Exchange Server 2010	14.0.694.0	4/9/2010	KB981401
Update Rollup 4 for Exchange Server 2010	14.0.702.1	6/17/2010	KB982639
Update Rollup 5 for Exchange Server 2010	14.0.726.0	12/13/2010	KB2407113

Exchange Server 2010 Service Pack 1

Product name	Build number	Date	KB
Microsoft Exchange Server 2010 SP1	14.1.218.15	8/24/2010
Update Rollup 1 for Exchange Server 2010 SP1	14.1.255.2	10/4/2010	KB2407028
Update Rollup 2 for Exchange Server 2010 SP1	14.1.270.1	12/9/2010	KB2425179
Update Rollup 3 for Exchange Server 2010 SP1	14.1.289.3	3/7/2011	KB2492690
Update Rollup 3-v3 for Exchange Server 2010 SP1	14.1.289.7	4/1/2011	KB2529939
Update Rollup 4 for Exchange Server 2010 SP1	14.1.323.1	6/22/2011	KB2509910
Update Rollup 4-v2 for Exchange Server 2010 SP1	14.1.323.6	7/27/2011	KB2579150
Update Rollup 5 for Exchange Server 2010 SP1	14.1.339.1	8/23/2011	KB2582113
Update Rollup 6 for Exchange Server 2010 SP1	14.1.355.2	10/27/2011	KB2608646

Exchange Server 2010 Service Pack 2

Product name	Build number	Date	KB
Microsoft Exchange Server 2010 SP2	14.2.247.5	12/4/2011
Update Rollup 1 for Exchange Server 2010 SP2	14.2.283.3	2/13/2012	KB2645995
Update Rollup 2 for Exchange Server 2010 SP2	14.2.298.4	4/16/2012	KB2661854
Update Rollup 3 for Exchange Server 2010 SP2	14.2.309.2	5/29/2012	KB2685289

Tracking Login Password Changes in SQL Server

Problem

By default, SQL Server does not keep track of login password changes. When the question initially came up with a user, I thought that perhaps it might be in the default trace or in the system_health extended event session. No such luck. So I was in search of an alternate way to keep track of these events, if not retroactively, at least going forward.

Solution

In a short time you can be up and running with collecting password change information using three different methods: server-side trace, event notifications, and SQL Server audit. Below I will provide an example using each technology. Note that all three examples are able to track password changes using ALTER LOGIN, the system procedure sp_password (deprecated since SQL Server 2005), or the Management Studio Login properties dialog.

---

Server-Side Trace

Trace includes an event called “Audit Login Change Password Event” – which is much more reliable than capturing all batches and filtering on ‘%sp_password%’ and ‘%ALTER%LOGIN%PASSWORD%’. The EventID is 107, so you can set up a very simple trace with the following code (make sure to set a proper path to the desired trace file):

DECLARE @TraceID INT, @MaxFileSize BIGINT;
SET @MaxFileSize = 5;

EXEC sp_trace_create 
    @TraceID OUTPUT, 
    2, 
    N'C:\Traces\PasswordChangeTrace', -- make sure to change this!
    @MaxFileSize,
    10; 

EXEC sp_trace_setevent @TraceID,107, 1,  1;
EXEC sp_trace_setevent @TraceID,107, 11, 1;
EXEC sp_trace_setevent @TraceID,107, 8,  1;
EXEC sp_trace_setevent @TraceID,107, 12, 1;
EXEC sp_trace_setevent @TraceID,107, 14, 1;
EXEC sp_trace_setevent @TraceID,107, 40, 1;
EXEC sp_trace_setevent @TraceID,107, 42, 1;

EXEC sp_trace_setstatus @TraceID, 1;

SELECT @TraceID;

Make note of the TraceID in the output. Once this has been running, you can use that TraceID to review the events that have been captured using the following query:

DECLARE @path NVARCHAR(255);

SELECT @path = [path]
FROM  sys.traces
WHERE id = <traceID from above>;

SELECT 
  LoginName  = TargetLoginName, 
  EventCount = COUNT(*), 
  FirstEvent = MIN(StartTime), 
  LastEvent  = MAX(StartTime)
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE EventClass = 107 -- in case you've added other events
GROUP BY TargetLoginName;

Since the above trace definition specifies a max of 10 x 5MB files, eventually an event that happens today will no longer be available through the above query. So as an added exercise you may consider periodically taking a snapshot of this data into a permanent table, and running your queries from there.

---

Event Notifications

An alternative to trace is to set up a targeted Event Notification. These are lightweight, asynchronous messages sent via Service Broker that can be used to perform various actions in response to a specific event. One such event is AUDIT_LOGIN_CHANGE_PASSWORD_EVENT. In a lot of cases people use these to send an e-mail or start a job, but in this case we’re just going to log to a table. We can create the following table in msdb:

USE [msdb];
GO

CREATE TABLE dbo.PasswordChangeLog
(
    LoginName  SYSNAME,
    EventTime  DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);

We will then need to set up a queue and a notification to handle our events:

CREATE QUEUE PasswordChangeQueue;
GO

CREATE SERVICE PasswordChangeService ON QUEUE PasswordChangeQueue
  ([http://schemas.microsoft.com/SQL/Notifications/PostEventNotification]);
GO

CREATE EVENT NOTIFICATION PasswordChangeNotification
    ON SERVER WITH FAN_IN
    FOR AUDIT_LOGIN_CHANGE_PASSWORD_EVENT
    TO SERVICE 'PasswordChangeService', 'current database';
GO

And then the following procedure can be used to log events to our table:

CREATE PROCEDURE dbo.LogPasswordChange
WITH EXECUTE AS OWNER
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @message_body XML;

    WHILE (1 = 1)
    BEGIN
       WAITFOR 
       ( 
         RECEIVE TOP(1) @message_body = message_body
         FROM dbo.PasswordChangeQueue
       ), TIMEOUT 1000;

       IF (@@ROWCOUNT = 1)
       BEGIN
        INSERT dbo.PasswordChangeLog(LoginName) 
          SELECT @message_body.value('(/EVENT_INSTANCE/LoginName)[1]', 'sysname');
       END
    END
END
GO

Finally, we can change the queue to call this stored procedure in response to the event:

ALTER QUEUE PasswordChangeQueue
WITH ACTIVATION
(
   STATUS = ON,
   PROCEDURE_NAME = dbo.LogPasswordChange,
   MAX_QUEUE_READERS = 1,
   EXECUTE AS OWNER
);
GO

Now change the password for a few logins, and you should see results from the following query:

SELECT 
  LoginName, 
  EventCount = COUNT(*), 
  FirstEvent = MIN(EventTime), 
  LastEvent  = MAX(EventTime)
FROM dbo.PasswordChangeLog
GROUP BY LoginName;

---

Server Audit

The final option I’ll present here is creating a Server Audit Specification. You may already be using Server Audit, and if so, handling password change auditing using this technology might make more sense than using either of the above two methods. (However note that Server Audit requires Enterprise Edition of SQL Server 2008 or SQL Server 2008 R2 – in SQL Server 2012, this feature has been made available in all editions.)

One of the options for a Server Audit Specification is LOGIN_CHANGE_PASSWORD_GROUP. We can set up a file-based audit to capture these events with the following code (note that this needs to be performed in master and you should update the file path appropriately – you probably don’t want to rely on C:\ for this):

USE [master];
GO

CREATE SERVER AUDIT ChangePasswordAudit
  TO FILE (FILEPATH = 'C:\Audits\', MAXSIZE = 5MB, MAX_ROLLOVER_FILES = 10)
  WITH (ON_FAILURE = CONTINUE); -- important unless you want your server to halt on failure

ALTER SERVER AUDIT ChangePasswordAudit
  WITH (STATE = ON);

CREATE SERVER AUDIT SPECIFICATION ChangePasswordAuditSpecification
  FOR SERVER AUDIT ChangePasswordAudit
  ADD (LOGIN_CHANGE_PASSWORD_GROUP)
  WITH (STATE = ON);
GO

Once this is running, you can change a few passwords and then retrieve data from the audit using the following query:

DECLARE @folder VARCHAR(255);

SELECT @folder = log_file_path + '*' 
  FROM sys.server_file_audits 
  WHERE name = 'ChangePasswordAudit';

SELECT 
  LoginName  = target_server_principal_name, 
  EventCount = COUNT(*),
  FirstEvent = MIN(event_time), 
  LastEvent  = MAX(event_time)
FROM sys.fn_get_audit_file(@folder, DEFAULT, DEFAULT)
WHERE action_id IN ('PWR', 'PWC') -- PWR = ALTER LOGIN / SSMS, PWC = sp_password
GROUP BY target_server_principal_name;

As with the trace above, this file-based audit is limited to 10 x 5MB files. So you may want to change those options to have the audit data hang around longer, or you may consider occasionally storing the result of this query in a permanent table.

One important thing to note about Server Audit is that it records the event time in UTC, so you might notice that the timestamps are off depending on your time zone. Therefore you may need to look into adding a helper function that will convert any UTC date to your time zone. Since this can get complicated with Daylight Saving Time, I’ve often found it easier to just set up all of our servers to do everything in UTC. 🙂

---

Conclusion

As you can see, there are a variety of ways to set up tracking for password changes, and each method is relatively straightforward to implement. While it is still impossible to obtain this information from the past, once you have implemented one of the above solutions, you will be able to look back on this information over time.