Hi there, already posted this in the SBS forum, although it has quite some views, not a single reply. It's probably not related to SBS anyways, so it's perhaps better suited here. Atleast there will be more exchange knowledge here. I've reinstalled the CAS role as well now, which has reinstalled the msexchangeab service, but that didn't help either. When starting microsoft.exchange.addressbook.service.exe on the cli it will remain 'running' until I press enter, but still logs the same error and doesn't do a thing either thus. Probably there's some setting left behind in AD, but I have a hard time finding it. Haven't been able to find an option to run the executable in debug mode or something similar, didn't see a debug option (for the process itself, not the generation of the oab's) in the .config file either. Here's the original post: Hi there, for the fourth time (sbs 2003 -> sbs 2011 migration) I could not replicate the public folders. In all 4 instances (4 different migrations) the public folder replication never completed. None of our customers use public folders extensively, usually just some shared addressbooks, none of them have more than say 30MB of data in the PFs. Also noteworthy, whilst the 'Public Folder Instances' folder showed folders in all 4 cases, the 'Public Folders' folder did not. Which is odd... Anyways, I deleted the public folder store (that is the files) on the 2003 server so it would create an empty store. The newly created empty store did show the default folders in 'Public Folders' (and under Public Folder Instances too). Hoped it would move the replica's, but no go. During this time, exchange (2010) operated fine, already had migrated the offline address book and the mailboxes after having waited a day or 2 for the public folders. Then came HP, which replaced the motherboard and the power backplane and maybe some other components, as the server occasionally just powered off. Highly doubt that caused it, but since then ExchangeAB won't start and it will return this error: Unable to register the MSExchangeAB RPC interface. Failed with the error code The endpoint is a duplicate (1740) Since then I've been fighting with the public folders etc to remove the old exchange (it won't uninstall w/o removing the public folder database and it won't remove even an empty store unless it's replicas are moved). Quite fed up with the replication, I can backup the public folders to PST in 5 mins, and restore them in the same time... Not having a proper way to trash the public folder is somewhat cumbersome, so far for every migration... Anyways, I deleted the public folder store on the 2003 server through adsiedit, then I could remove exchange. It did leave the administrative group, so I trashed that too through adsiedit in hopes the situation would become 'cleaner'. Because of issues we had then, I trashed the public folder store on the 2010 server as well, as well as the Default OAB. Created a new public folder store and a new Default OAB. Attached the public folder store to the mailbox store (had to correct the path in adsiedit, which I found weird since it was nicely set up in the gui) and published oab in web and public folder. Besides the above error, exchange throws no errors. BPA shows some weird things, like a notification (not an error/warning type of thing) that the public folder store is remote (eh? there is only one exchange server and the paths for the mailbox and public folder store hardly differ besides the obvious naming differences). Checked some other SBS 2011 installs, but get the same notification there. It also notes that the permissions on the public folder path are incorrect and that read rights are lacking. This is an error of BPA, strange enough, it doesn't show up with this error every time I run it. It's a dutch server, but the groups listed that lack permissions are in english, their dutch equivalents (the english ones don't even exist) have exactly the permissions that BPA states. Found some other people with similar issues, one is about global catalog being removed from the exchange server, so that probably doesn't apply (it has a big warning not to touch the registry keys if it's still a GC). Did try to assign the msexchangeab a static port (tried 3 different ones) and checked it wasn't used through netstat, but that makes no difference. To be clear, the error thus exists since before the public folder stores had both been removed (but the 2003 public folder store files were removed and created a new empty one, which didn't move it's replica's proper either...). It probably came to live because of the reboot required to replace the components, doubt it has to do with the hardware..., but I don't know the exchangeab internals. Any ideas on how to solve it? There have been some other issues too, if people hit send/receive, at least some of them had the 0x8004010f error (most don't hit send/receive, not really necessary anyways :)), which has to do with being unable to download the OAB. Not sure if the users I tested with now had the same issue, but they don't have it now. I did test with users that had their exchange profiles automatically updated by starting outlook whilst the 2003 was still in the air and the mailboxes had already been migrated to 2010. Probably went away since the OAB was recreated and attached to the mailstore. Also, nearly everyone with a migrated profile has to enter their password to connect to exchange and this occasionally comes back. People with a migrated profile are also unable to open other users' mailbox/folders. Says it can't find/open the folder (freely translated). Both of these seem to go away with a clean profile. Not sure if this is of interest as the exchange server initially operated fine, but the first time I tried to migrate the server had one of the magic power-offs messing up the migration. Simply tried to migrate again, but that failed, because of entries in AD made for the DC status and exchange install of the migration. Removed these entries from AD, reran exchange with iirc /preparead (the one that does the scheme update, otherwise it was whining about the administrative group already existing etc.). Yet another migration went fine after that. Not sure if the ExchangeAB is required... Everything seems to work fine with clean profiles at least... TIA Kind regards

This was solved by a reply in exchange general forums, in which I posted it too after a while. The following is my reply there: Thanks a lot :) 6002 was used (6001 as well, but by exchange rpc so that's ok) by a sentinal key server (this thing seems to wrap around flexlm, the license key manager, probably familiar to a lot of people. Think it extends it to support dongles (all flexlm installations I've seen so far use just a license file, this one has 2 sentinal services as well and uses a dongle + the license file). TCP 0.0.0.0:6001 0.0.0.0:0 LISTENING 9276 [Microsoft.Exchange.RpcClientAccess.Service.exe] TCP 0.0.0.0:6002 0.0.0.0:0 LISTENING 4796 [spnsrvnt.exe] Stopped the sentinal services and now it starts just fine. Can't believe I lost so much time on this :(. Do have one more question tho', I used the TcpRpcPort reg entry to set a port (might be spelled differently as in RpcTcpPort). Tried 3 different ones, but this hasn't helped at all. Perhaps I should have used static ports on the RPC service as well, but netstat shows msexchangeab bound to the 6002 port, not RPC. TCP 0.0.0.0:6001 0.0.0.0:0 LISTENING 9276 [Microsoft.Exchange.RpcClientAccess.Service.exe] TCP 0.0.0.0:6002 0.0.0.0:0 LISTENING 2864 [Microsoft.Exchange.AddressBook.Service.exe] This is what I send to MS Support (who called 5 mins after it was solved :)): We actually just resolved the case. Turns out port 6002 was in use by a service called ‘Sentinel Protection Server’. Not quite sure why this was an issue, as I tried to set the RpcTcpPort (or TcpRpcPort, don’t recall the exact naming) in registry to a free port and still had the issue (tried 3 different ports all 3 were verified free (with netstat)). So clearly it needs port 6002. This service, along with 2 others ‘Sentinel Keys Server’ and flexlm (of which you can choose the service name yourself) are part of a licensing setup from Solid Edge (a CAD package). I come across just flexlm a lot, which just uses a license file. This one also uses a dongle (next to the license file) and I think the 2 sentinel services wrap around flexlm to enable the USB dongle (never saw them with other customers who only have a license file). Anyways, it might have been a race (start-up). It was already installed for quite a while without causing issues (rebooted a lot for updates etc). If I stop the services, and then start msexchangeab and then the sentinel services, everything appears fine. Although I haven’t tested the licensing setup yet (it couldn’t find the server during testing and because of my holiday I just left the licensing stuff running on the old server for now, perhaps because msexchangeab occupied one of the ports it likes thus), the service doesn’t throw an error. This is my current view on it: Msexchangeab probably used to start before the sentinel services. This probably also explains why the Solid Edge package couldn’t find it’s licenses. It seems to switch ports or it just doesn’t throw an error about not being able to bind to the 6002 port. This is currently just a guess though, haven't tested if it works fine if I start it before the msexchangeab yet. The following is probably more interesting, because SBS 2011 has issues starting up (that is, several services frequently don’t start on boot, you can just start them manually afterwards, it’s a documented issue) I applied several tweaks from the SBS forums and a patch to ensure they would all start. I think this alters the way the services start in such a way the sentinel services now start before msexhangeab does, whereas before it would have been the other way around.