Go Premium for a chance to win a PS4. Enter to Win


Exchange 2013 CU1 prerequisite error regarding Exchange 2007 SP3

Posted on 2013-05-31
Medium Priority
Last Modified: 2013-06-11
I  can't seem to get an Exchange 2013 install  to recognize that the Exchange 2007 on the network is honest to goodness SP3 rollup 10.

Our current server runs SBS 2008.  I have Exchange 2007 fully updated with Service Pack 3 and Rollup 10. I've gone back and  verified it under Program and in the Shell and Console. It says Rollup 10 is installed and the build number is

The new server is a separate box with Microsoft 2012 Standard. I have 3  virtual servers running via hyper-V--one as a second DC, one with Sharepoint 2013 and SQL Server 2012, and one for Exchange 2013. All are currently pointed to SBS server as the DNS server (the second DC also points to itself as an alternative).  The SBS 2008 Server still has all the FSMO roles

The first two haven't been a problem with setting up, but for the Exchange install constantly fails with just one Error:

 [REQUIRED] All Exchange 2007 servers in the organization must have Exchange 2007 SP3 or later installed. The following servers don't meet this requirement: [MySBSServerName]

 The domain level is 2003, (I haven't read advice to bump it up, but it wouldn't be a problem if I had to).  I am using the Exchange 2013 CU1 for the install, which should coexist with 2007. . Once everything is finished and everyone moved over, I'll transfer the main roles to the new DC and retire the SBS server.

 Could this error be because it's a SBS server? Has anyone encountered this or could point me in the right direction?

Many thanks!
Question by:rjmoseroashf
  • 3
  • 2
LVL 63

Expert Comment

by:Simon Butler (Sembee)
ID: 39211124
SBS will not be the problem.
Are the FOREST and the DOMAIN at Windows 2003? That is the minimum required.
If you run the rollup again, does it do anything? It could be that something hasn't been stamped correctly in the registry or domain.


Author Comment

ID: 39219510
Yep, both are at 2003. No difference when I ran the rollup 10 again.  Going to  re-install service pack 3 the moment I have downtime in hopes that will jog something.
LVL 63

Expert Comment

by:Simon Butler (Sembee)
ID: 39220715
You will need to remove the rollup before you can reinstall the service pack, although I don't think you will be able to reinstall it unless the installer detects something is missing.


Accepted Solution

rjmoseroashf earned 0 total points
ID: 39224064
After much trial and error, I've finally cleared the issue.

Steps that had no effect for me on it (to be helpful in case someone else has a similar issue):

Re-installing the rollups had no effect, and while I did run the setup.com /prepareschema, and then setup /preparead again, no difference.

Disabling Symantec Endpoint and Forefront Protection for all roll-ups, Active Directory prep, and attempted 2013 coexistence install (although I'd recommend doing that anyway for them, especially the first time). No change.

Changing the registry keys to reflect Service Pack 3 rollup 10 (the correct versions were listed as unpacked, but not configured) at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\v8.0\<Role>\ConfiguredVersion. Before taking such a measure,  I verified that the files in the Exchange bins folder (like store.bin) were all rollup 10 build. I also verified it the Exchange Management Console using GCM exsetup |%{$_.Fileversioninfo}.

While this did not affect the issue, it did lead me to the solution. Because putting in get-exchangeserver, the result next to  AdminDisplayVersion was "Version 8.1 (Build 30240.6)'". Service Pack 1 Rollup 6. Hmm.

Looking through the exchange setup log on the 2013 server (previously I had just looked at the error/failure reporting sections. Before for that is the expansive list of its starting, evaluated, and finished prerequisite checks. There I found exactly "Version 8.1 (Build 30240.6)". From other blogs I had learned the AdminDisplayVersion wasn't the reality of the version: it just displays  whatever's listed in the Active Directory. Exchange 2013's prerequisite's check depends entirely on info provided Active Directory, not what's actually running.

At some point in the past (SP1 1 Rollup 6 in my case), Exchange had stopped updating the Active Directory exchange attributes when updating itself--information needed for the 2013 install.  The problem source existed in the original place I looked--the Active Directory Service Interface using adsiedit.msc. I'd just been looking in the wrong place.

 The forest and domain version number for exchange were perfectly correct. What wasn't was two attributes on the exchange server object. The first was easy. The second, not so much.


Here's a handy page of Exchange: build numbers: http://social.technet.microsoft.com/wiki/contents/articles/240.exchange-server-and-update-rollups-build-numbers.aspx

Right-click ADSI Edit at the top of the mmc. Right click and choose Connect to, then  Select a well know Name Context and pick Configuration. Then okay,

Expand CN=Configuration], CN=Services, CN= Microsoft Exchange, CN=[ExchangeDomain], CN=Administrative Groups, CN=Exchange Administrative Group (FYD...), CN=Servers, CN=[Your Exchange Server]. Right click your exchange server name listed and select Properties. Scroll to serialNumber. If it does not say it already, and you are POSITIVE your Exchange server  is operating on SP3 rollup 10 as exampled earlier in this post, Edit it and add Version 8.3 (Build 30298.3) and remove the one that was there.

That changes get-exchangeserver AdminDisplayVersion to exactly that (I almost think that if you changed it to fluffybunnies, it would say that); that line is simply a reflection of  what's listed in ADSI. More importantly, the server 2013 log stops showing the older version when evaluating it's minimum and existing version rules.

BUT IT STILL FAILS WITH THE EXACT SAME ERROR. 2007 is not service pack 3 etc (I had actually done this before changing the registry.] The evaluations lists absolutely no specific reason why. The error still states [sbs/exchangeserver] is at fault.

While I believe the above does need done since the Exchange 2013 install specifically pulls it as a prereq, there's one more attribute that needs changed, and it's in the same list as serialNumber. This is where it got fun, with a mix of deduction and luck.

It occurred to me the attribute versionNumber, also in [exchangeserver] properties had not changed at all, not once through all the changes and updates. It stuck out as 'versions' had been the issue from the start, even though the number there was entirely unfamiliar. But a quick past in Google informs that it was associated with SP 1, rollup 6. Let's change it.

And then, of course, does it list nowhere on the net for a list versionNumber values. I found a forum poster that listed them for the original service pack 1 and 2. But service pack 3? Nada. Evidently if you run Edge server, you can export a new subscription file and the integer will be right in there. I do not, and no hub or transport export I tried had what I was looking for.

If I ever meet the writer of this article, I owe him a beer. It instructs how to turn a build  number into binary sections and then a decimal integer (or rather the other way around, but i just reversed the process.) http://blogs.msdn.com/b/pcreehan/archive/2009/09/21/parsing-serverversion-when-an-int-is-really-5-ints.aspx .
I converted the sections of the Rollup 10 build number into binary, added first four bits and middle flag as instructed and put t together to form a new decimal integer. I came up with 1912832298. I could be off  as I'm no parsing pro, it was quite late, and i'd had no food all day, so it's entirely possible that any integer above a certain level will clear it. But as soon as I put in that in versionNumber and retried,  the prereq error cleared. MS Exchange 2013 installed on the new server with no new problems, and no issues with SBS.

Author Closing Comment

ID: 39237129
Worked on the issue for a few days and figured out the solution, then posted in the case it might help someone else.

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In this post, I will showcase the steps for how to create groups in Office 365. Office 365 groups allow for ease of flexibility and collaboration between staff members.
Mailbox Corruption is a nightmare every Exchange DBA wishes he never has. Recovering from it can be super-hectic if not entirely futile. And though techniques like the New-MailboxRepairRequest cmdlet have been designed to help with fixing minor corr…
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
This tutorial will walk an individual through the process of installing the necessary services and then configuring a Windows Server 2012 system as an iSCSI target. To install the necessary roles, go to Server Manager, and select Add Roles and Featu…
Suggested Courses

885 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question