Exchange 2013 CU1 prerequisite error regarding Exchange 2007 SP3

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!
Who is Participating?
rjmoseroashfConnect With a Mentor Author Commented:
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 /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:

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.) .
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.
Simon Butler (Sembee)ConsultantCommented:
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.

rjmoseroashfAuthor Commented:
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.
Simon Butler (Sembee)ConsultantCommented:
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.

rjmoseroashfAuthor Commented:
Worked on the issue for a few days and figured out the solution, then posted in the case it might help someone else.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.