drdread
  • drdread
  • 100% (Exalted)
  • Advanced Member Topic Starter
2 days ago
I have a problem with an exchange 2013 server that has some sort of diissagreement with AD...
Sponsor

Want to thank us? Use: Patreon or PayPal or Bitcoins: bc1q4whppe29dw77rm4kv4pln0gqae4yjnxly0dny0hky6yhnafukzjsyrsqhk

All opinions expressed within these pages are sent in by members of the public or by our staff in their spare time, and as such do not represent any opinion held by sircles.net Ltd or their partners.


sirclesadmin
2 days ago
When Exchange 2013 and Active Directory fall out of sync or develop some tension, it can manifest in strange and varied ways. Please share:

The exact error message(s) you're seeing

Any relevant event logs

What actions you're trying to perform when the error occurs (e.g., creating a mailbox, updating certificates, etc.)

Whether there were recent changes (e.g. schema update, domain controller issues, DNS changes, server restarts, Windows Updates, etc.)

Once I have that, I’ll help you troubleshoot it methodically — whether it’s a permissions mismatch, an AD replication delay, a broken arbitration mailbox, or an improperly applied CU or schema mismatch. Let’s untangle the knot.
drdread
  • drdread
  • 100% (Exalted)
  • Advanced Member Topic Starter
2 days ago
I cannot uninstall and all the services crash: Microsoft Exchange Server 2013 Cumulative Update 23 Unattended Setup

Mailbox role: Mailbox service
Mailbox role: Unified Messaging service
Mailbox role: Client Access service
Mailbox role: Transport service
Client Access role: Front End Transport service
Management tools
Client Access role: Client Access Front End service
Languages

Performing Microsoft Exchange Server Prerequisite Check

Configuring Prerequisites COMPLETED
Prerequisite Analysis COMPLETED

Configuring Microsoft Exchange Server

Preparing Setup COMPLETED
Mailbox role: Mailbox service FAILED
The following error was generated when "$error.Clear();
Set-MailboxServer -Identity $RoleFqdnOrName -CalendarRepairWorkCycle $
null -CalendarRepairWorkCycleCheckpoint $null
" was run: "Microsoft.Exchange.Configuration.Tasks.ManagementObjectNotFo
undException: The operation couldn't be performed because object 'ArgEX-temp.arg
ofield.local' couldn't be found on 'ARGDC2.argofield.local'.
at Microsoft.Exchange.Configuration.Tasks.DataAccessTask1.GetDataObject[TObj
ect](IIdentityParameter id, IConfigDataProvider session, ObjectId rootID, Option
alIdentityData optionalData, Nullable1 notFoundError, Nullable1 multipleFoundE
rror, ExchangeErrorCategory errorCategory)
at Microsoft.Exchange.Configuration.Tasks.DataAccessTask1.GetDataObject[TObj
ect](IIdentityParameter id, IConfigDataProvider session, ObjectId rootID, Option
alIdentityData optionalData, Nullable1 notFoundError, Nullable1 multipleFoundE
rror)
at Microsoft.Exchange.Configuration.Tasks.SetObjectWithIdentityTaskBase3.Res
olveDataObject()
at Microsoft.Exchange.Configuration.Tasks.SetSystemConfigurationObjectTask3.
ResolveDataObject()
at Microsoft.Exchange.Configuration.Tasks.SetObjectTaskBase2.PrepareDataObje
ct()
at Microsoft.Exchange.Management.SystemConfigurationTasks.SetMailboxServer.Pr
epareDataObject()
at Microsoft.Exchange.Configuration.Tasks.SetTaskBase1.InternalValidate()
at Microsoft.Exchange.Configuration.Tasks.SetSystemConfigurationObjectTask3.
InternalValidate()
at Microsoft.Exchange.Management.SystemConfigurationTasks.SetMailboxServer.In
ternalValidate()
at Microsoft.Exchange.Configuration.Tasks.Task.b__b()
at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String fun
cName, Action func, Boolean terminatePipelineIfFailed)".


The Exchange Server setup operation didn't complete. More details can be found
in ExchangeSetup.log located in the :\ExchangeSetupLogs folder.
sirclesadmin
2 days ago

Ah, the classic Exchange 2013 "phantom object" problem. You're caught in a deadlock where setup (and thus uninstall) fails because it's trying to reference an Exchange object that no longer exists in Active Directory:


The operation couldn't be performed because object 'ArgEX-temp.argofield.local' couldn't be found on 'ARGDC2.argofield.local'.

This typically means:



  • Exchange is trying to configure or clean up a server object that has been deleted or partially removed from Active Directory (possibly forcibly).

  • This object (ArgEX-temp.argofield.local) may exist in some parts of AD and not others - AD replication may be inconsistent.

  • The uninstall is trying to run a Set-MailboxServer command on an Exchange object that doesn't exist in the expected AD location.


Let's resolve this methodically:




Step 1: Check if the server object exists in AD


Open ADSI Edit (adsiedit.msc) on the domain controller or the Exchange box:



  1. Connect to the Configuration naming context.



  2. Navigate to:


    CN=Configuration,DC=argofield,DC=local
    CN=Services
    CN=Microsoft Exchange
    CN=<Your Org Name>
    CN=Administrative Groups
    CN=Exchange Administrative Group (FYDIBOHF23SPDLT)
    CN=Servers



Look under CN=Servers for a sub-object named ArgEX-temp or anything resembling the broken reference.




Step 2: Determine replication state


Run this on your DC (ARGDC2) and any other DCs:


repadmin /replsummary

You're looking for failed/incomplete replication. If replication is broken, setup may be hitting stale data.




Step 3: Check if the object exists in the Configuration partition


Run this PowerShell from a DC or management server:


Get-ADObject -Filter 'Name -like "*ArgEX-temp*"' -SearchBase "CN=Configuration,DC=argofield,DC=local" -Properties *

You may find:



  • The object exists and is corrupt

  • The object is completely missing but referenced in lingering metadata




Step 4: Clean up lingering server object manually if needed


If the object does exist but Exchange setup cannot interact with it, and you're confident that this is not a production server, then you can delete the stale server object manually from ADSI Edit.


WARNING: Only delete if you're 100% certain this is not a real, running Exchange box. Backup your AD or export the object first.




Step 5: Force setup to ignore specific steps


If you're trying to uninstall Exchange but certain objects are preventing it, you can try forcing removal, but this is delicate.


Try this from the Exchange installation directory:


setup.exe /mode:uninstall /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF

But if that fails the same way, consider using Remove-ExchangeServer cmdlet manually (see below).




Step 6: Use Remove-ExchangeServer cmdlet manually


If the server is non-functional and you're only trying to get rid of it from the organization, and you cannot use setup, you can remove the server object from AD manually using PowerShell:


Remove-ExchangeServer -Identity "ArgEX-temp" -DomainController ARGDC2.argofield.local -Force

But again - this only works if the server is no longer active and was previously installed correctly.




Final Options


If none of this works:



  • Try running setup /mode:uninstall with logging enabled:


    setup.exe /mode:uninstall /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF /LogLevel:Verbose

    Then inspect C:\ExchangeSetupLogs\ExchangeSetup.log - search for the last Exception block before failure.



  • If this is a lab environment or a decommissioning scenario, you may have to manually clean all Exchange references from:



    • Configuration partition (CN=Microsoft Exchange)

    • Domain partition (CN=SystemMailbox..., etc.)

    • Sites & Services > Services > Microsoft Exchange

    • Get-MailboxServer, Get-ClientAccessServer, etc. (PowerShell)




Let me know how far you get - and whether you're trying to repair or fully uninstall/decommission the server - and I'll tailor the next step accordingly.



drdread
  • drdread
  • 100% (Exalted)
  • Advanced Member Topic Starter
2 days ago
only the 2007 exchange shows?? How is that - it was there yesterday?


sirclesadmin
2 days ago

Ah, if only the Exchange 2007 server shows up now - and the Exchange 2013 server has vanished from both the EAC and Get-ExchangeServer output - then we're likely in the realm of orphaned Exchange metadata, partial removal, or even accidental deletion from AD.


This is critical context - let's dissect it like a forensic pathologist with a poetic streak.




What Likely Happened:


Exchange 2013 writes extensive metadata into Active Directory, specifically:



  • In the Configuration partition

  • In CN=Servers, under the Exchange Administrative Group

  • And under CN=Services > CN=Microsoft Exchange Autodiscover

  • It also has presence in System Mailboxes, Routing Groups, and AD site bindings


If these entries are manually deleted (via ADSIEdit or scripts), or if domain controller replication lags or fails, your Exchange 2013 server can vanish from management tools - yet still cling on just enough to block uninstall or setup actions.


This explains:



  • Why uninstall/setup is referencing a ghost (ArgEX-temp) - Exchange is pulling from stale or broken AD pointers.

  • Why Get-ExchangeServer can't see it - PowerShell only reads what AD surfaces under CN=Servers, not remnants.




What To Do Next:


Step 1: Confirm what's left in AD


Open ADSIEdit again and explore these three key areas:


1. Server Object


CN=Configuration  CN=Services  CN=Microsoft Exchange  CN=<Your Org>  CN=Administrative Groups  CN=Exchange Administrative Group (FYDIBOHF23SPDLT)  CN=Servers

Look for your Exchange 2013 server name.


2. Autodiscover Virtual Directory


CN=Configuration  CN=Services  CN=Microsoft Exchange Autodiscover

If the 2013 server is there, it's leftover metadata.


3. System Mailboxes


CN=Users  filter by "SystemMailbox{...}"

You may find mailbox arbitration leftovers from the Exchange 2013 install.




Step 2: Rebuild Management View


Sometimes Get-ExchangeServer won't show the object even if it exists due to corruption or incomplete object metadata. Try:


Get-ExchangeServer -DomainController ARGDC2.argofield.local -Verbose

Still nothing? Try:


Get-ADObject -Filter 'ObjectClass -eq "msExchExchangeServer"' -SearchBase "CN=Configuration,DC=argofield,DC=local" -Properties name, distinguishedName

This will show if the object exists but Exchange cmdlets are blind to it.




Step 3: Decide - Resurrect or Bury


If the 2013 object is gone and Exchange is broken, then uninstall will fail indefinitely unless:



  • You restore the AD object from backup (if one exists)

  • Or you clean AD manually to decommission the ghost




Final Clean-Up: Manual Decommissioning


If this is a decommissioning task and 2013 is unsalvageable, proceed with a manual removal:



  1. Delete orphaned server object from:


    CN=Servers  CN=ArgEX-temp


  2. Delete references in:



    • CN=Exchange Administrative Group

    • CN=Routing Groups

    • CN=Autodiscover



  3. Remove any Receive Connectors, System Mailboxes, or Database objects pointing to the dead server



  4. Clean up from AD Sites & Services if needed



  5. Remove it from the Exchange Organization list in EAC if it's still listed (sometimes in hybrid setups)






Warning


Before you delete anything in ADSIEdit:



  • Export the object using ldifde or a screenshot of its attributes

  • Check with repadmin /replsummary to make sure you're not seeing a replication delay

  • Confirm that server isn't actually still on the network




Let me know:



  • Was this server intended to be decommissioned?

  • Do you have any backups (VM snapshot, AD object)?

  • Are you trying to recover Exchange 2013, or just cleanly remove it?


We can script the cleanup if you're ready for that final act. Or we can try resurrection if a backup object remains. Either way - you're not alone in this server's haunted farewell.



drdread
  • drdread
  • 100% (Exalted)
  • Advanced Member Topic Starter
2 days ago
Can't I recreate the server object in AD with a script??
sirclesadmin
a day ago

Yes, Simon - you can recreate the Exchange 2013 server object in Active Directory, but only partially, and only enough to unblock uninstall or allow cleanup - not to revive a working Exchange install. This is necromancy, not resurrection.


Let's get technical and precise.




What Recreating Can and Cannot Do


Can help:



  • Fake out setup /uninstall just enough to succeed

  • Recreate the minimal object in CN=Servers so that Remove-ExchangeServer can run


Cannot:



  • Restore full Exchange functionality

  • Recreate all required attributes, bindings, routing groups, mailbox databases, etc.

  • Repair a broken or partially installed Exchange role




OPTION A: Minimal Manual Recreate via ADSIEdit


If you're in a hurry:



  1. Open ADSIEdit



  2. Connect to Configuration naming context



  3. Navigate to:


    CN=Configuration,DC=argofield,DC=local
    CN=Services
    CN=Microsoft Exchange
    CN=<Your Org Name>
    CN=Administrative Groups
    CN=Exchange Administrative Group (FYDIBOHF23SPDLT)
    CN=Servers


  4. Right-click CN=Servers New > Object



    • Choose class: msExchExchangeServer



    • Name: ArgEX-temp



    • Set attributes:



      • cn: ArgEX-temp

      • name: ArgEX-temp

      • serialNumber: Version 15.0 (Build 1497.2) (for CU23)

      • msExchServerRole: 54 (Mailbox + Client Access)

      • objectClass: top, server, msExchExchangeServer





  5. You must also create:



    • A child CN=InformationStore

    • Optionally: dummy mailbox database objects if setup complains further




Then try:


setup.exe /mode:uninstall /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF



OPTION B: Use PowerShell + AD cmdlets to fake the object


Create minimal object via PowerShell (requires RSAT tools):


$orgDn = "CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=YourOrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=argofield,DC=local"
$serverDn = "CN=ArgEX-temp," + $orgDn

New-ADObject -Name "ArgEX-temp" `
-Type "msExchExchangeServer" `
-Path $orgDn `
-OtherAttributes @{
cn = "ArgEX-temp";
serialNumber = "Version 15.0 (Build 1497.2)";
msExchServerRole = 54
}

You can add further attributes as required (e.g., networkAddress, legacyExchangeDN, etc.) based on another Exchange 2013 server's metadata.




Option C: Export from backup or clone from working object


If you have another working Exchange 2013 server, you can export its AD object and modify for your broken server:


ldifde -d "CN=WorkingEX,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=YourOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=argofield,DC=local" -f export.ldf -p subtree -r "(objectClass=*)"

Then open export.ldf, rename WorkingEX to ArgEX-temp, and import:


ldifde -i -f modified.ldf

Just remove/adjust:



  • distinguishedName

  • objectGUID

  • Any msExchSiteMailbox or Database links




Then: Test If Uninstall Will Proceed


Once AD object is created, retry:


setup.exe /mode:uninstall /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF /LogLevel:Verbose

If it gets past the Set-MailboxServer step - you're winning.




Caveat


This is an unsupported method by Microsoft. But it's known to work in scenarios like:



  • Failed install that left debris

  • DC restored from backup but Exchange not

  • Server forcibly deleted from AD before uninstall




Final Steps


Once it's gone:



  • Clean AD of remaining Exchange objects (mailbox DBs, connectors, arbitration mailboxes)

  • Remove CN=ArgEX-temp again

  • Verify with Get-ExchangeServer and Get-ADObject




Would you like a tailored PowerShell script that clones a working server object and tweaks it for ArgEX-temp? I can generate it based on your org structure if you paste a DN of one working server from Get-ExchangeServer | fl Name,DistinguishedName.



drdread
  • drdread
  • 100% (Exalted)
  • Advanced Member Topic Starter
a day ago
I get this error: 'ldaperr: DSID-0C090FAC comment: error in attribute conversion operation, data 0, v3839'
sirclesadmin
a day ago

Ah yes - the dreaded DSID-0C090FAC error. This LDAP error is usually raised by Active Directory when you're attempting to:



Set or create an attribute that's not correctly typed or expected for the object class you're working with.



Here's the full translation:




Error Breakdown



  • ldaperr: DSID-0C090FAC



    • This tells you the error originated during a schema validation step - specifically during attribute value conversion.



  • comment: error in attribute conversion operation



    • The value you're trying to assign doesn't match the expected type for that attribute. For example:



      • You passed a string where an integer is expected

      • You passed a multi-value where a single-value is expected

      • Or you used a value outside the allowed range or format





  • data 0, v3839



    • data 0 means it's a generic schema mismatch rather than something like a permissions issue.

    • v3839 is the LDAP version and internal handler for error tracking - not directly useful to us.






What Usually Causes This in Your Context


You're likely trying to create or clone an msExchExchangeServer object in AD (via script or manually) and you've set:



  • An attribute like serialNumber, msExchServerRole, legacyExchangeDN, or others

  • With a value that violates AD's expected syntax or data type


Most often:

























AttributeExpected TypeCommon Mistake
msExchServerRoleIntegerProvided a string like "Mailbox"
serialNumberStringToo long or with invalid characters
cn or nameString (DN-safe)Invalid characters or format



Fix Strategy



  1. Identify the exact attribute that triggered the error


If you used PowerShell:


New-ADObject ... -OtherAttributes @{ msExchServerRole = "Mailbox" }

Change to:


-OtherAttributes @{ msExchServerRole = 54 }  # Mailbox + Client Access

If you used ldifde, inspect the .ldf file and find the attribute right before the error line. Look for:


msExchServerRole: Mailbox

Replace with:


msExchServerRole: 54



Correct Attribute Values


For Exchange 2013 CU23:



  • msExchServerRole: 54
    (Binary mask: 2 + 4 + 16 + 32 = CAS + Mailbox + FrontEnd + UnifiedMessaging)



  • serialNumber:


    Version 15.0 (Build 1497.2)


  • objectClass:
    top, server, msExchExchangeServer






Debugging Tip


To narrow it down, remove all optional attributes and add one at a time:


New-ADObject -Name "ArgEX-temp" `
-Type "msExchExchangeServer" `
-Path "CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),..." `
-OtherAttributes @{
cn = "ArgEX-temp";
name = "ArgEX-temp"
}

Then try adding:


Set-ADObject -Identity "CN=ArgEX-temp,..." -Add @{ msExchServerRole = 54 }

This isolates which attribute fails.




If You Want Help With the Script


If you paste the output of this:


Get-ExchangeServer | fl Name,DistinguishedName,ServerRole,Edition,AdminDisplayVersion

...I'll generate a minimal New-ADObject script for recreating the missing server (adjusted for your org), ready to unblock uninstall.




Let me know how you want to proceed:



  • Do we debug this exact script further?

  • Or do we generate a clean version based on known working server attributes?


Excellent and very precise question, Simon - and a vital one when you're handcrafting AD objects like a sorcerer bringing bones back to life.




What Is objectCategory in AD?


objectCategory is a single-valued attribute that:



  • Provides a fully distinguished name (DN) pointing to the class definition of the object.

  • Helps filter and classify the object type efficiently during searches.

  • Is inherited from the schema class that the object is based on, but can be explicitly set when needed.


Unlike objectClass, which is multi-valued and shows inheritance like:


objectClass: top
objectClass: server
objectClass: msExchExchangeServer

The objectCategory is a single DN, e.g.:


CN=ms-Exch-Exchange-Server,CN=Schema,CN=Configuration,DC=argofield,DC=local



For an Exchange 2013 Server, it should be:


objectCategory: CN=ms-Exch-Exchange-Server,CN=Schema,CN=Configuration,<your forest DN>

e.g., for your domain:


CN=ms-Exch-Exchange-Server,CN=Schema,CN=Configuration,DC=argofield,DC=local

This tells AD that the object is classified as an Exchange server by schema standards.




To check it on a working Exchange server:


Get-ADObject -Filter { name -eq "YourExchangeServer" } -SearchBase "CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=YourOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=argofield,DC=local" -Properties objectCategory | Select-Object Name,objectCategory

Or if you want all Exchange servers:


Get-ADObject -LDAPFilter "(objectClass=msExchExchangeServer)" -SearchBase "CN=Configuration,DC=argofield,DC=local" -Properties objectCategory | ft Name,objectCategory



When Recreating an Exchange Server Object


You can optionally specify objectCategory in -OtherAttributes, but if you're using -Type "msExchExchangeServer", it should inherit this automatically from the schema.


If you do want to set it explicitly (e.g. LDIF or raw ADSI), use:


-objectCategory "CN=ms-Exch-Exchange-Server,CN=Schema,CN=Configuration,DC=argofield,DC=local"



Summary




















AttributeTypeExample / Value
objectClassMulti-valuedtop, server, msExchExchangeServer
objectCategorySingle-valuedCN=ms-Exch-Exchange-Server,CN=Schema,CN=Configuration,DC=argofield,DC=local

If you're scripting this and the setup is still sensitive to objectCategory, let me know and I'll incorporate it into a clean script.


Would you like a template PowerShell or LDIF snippet with this fully integrated?



drdread
  • drdread
  • 100% (Exalted)
  • Advanced Member Topic Starter
a day ago
but it is mandatory so what am I adding for this exchange server?
sirclesadmin
a day ago

Perfect, Simon - let's tackle this straight: yes, objectCategory is mandatory when you're creating an object manually in Active Directory without a template (e.g. New-ADObject or LDIF), especially if bypassing Exchange setup.


And since we're manually re-creating a lost Exchange 2013 server object, this is the exact value you must assign to the objectCategory attribute:




Correct objectCategory for Exchange 2013 Server:


CN=ms-Exch-Exchange-Server,CN=Schema,CN=Configuration,DC=argofield,DC=local

Just replace DC=argofield,DC=local with your actual forest root DN, which in your case is correct based on previous messages.




Example: Setting with PowerShell


If using New-ADObject:


$orgDn = "CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=YourOrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=argofield,DC=local"
$schemaCategory = "CN=ms-Exch-Exchange-Server,CN=Schema,CN=Configuration,DC=argofield,DC=local"

New-ADObject -Name "ArgEX-temp" `
-Type "msExchExchangeServer" `
-Path "CN=Servers,$orgDn" `
-OtherAttributes @{
cn = "ArgEX-temp";
name = "ArgEX-temp";
objectCategory = $schemaCategory;
serialNumber = "Version 15.0 (Build 1497.2)";
msExchServerRole = 54
}



Example: In LDIF format


dn: CN=ArgEX-temp,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=YourOrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=argofield,DC=local
changetype: add
objectClass: top
objectClass: server
objectClass: msExchExchangeServer
cn: ArgEX-temp
name: ArgEX-temp
objectCategory: CN=ms-Exch-Exchange-Server,CN=Schema,CN=Configuration,DC=argofield,DC=local
serialNumber: Version 15.0 (Build 1497.2)
msExchServerRole: 54

Then import with:


ldifde -i -f recreated-server.ldf



Gotcha to Avoid


Ensure you don't enclose objectCategory in quotes
Don't use "ms-Exch-Exchange-Server" alone - must be full DN


Use correct casing (CN=, not cn=)




Let me know if you'd like the entire script or LDIF template generated and filled out for your domain. We can even stub in database and connector placeholders if needed to avoid further setup errors.



drdread
  • drdread
  • 100% (Exalted)
  • Advanced Member Topic Starter
a day ago
can I create the object in powershell?
sirclesadmin
a day ago

Yes, Simon - you absolutely can create the missing Exchange server object directly in PowerShell, using the New-ADObject cmdlet from the Active Directory module - and it's the cleanest way to do this on a domain-joined machine.


Below is a precise, working example tailored to Exchange 2013 CU23, for a server called ArgEX-temp, in your argofield.local domain:




Prerequisites



  • Run from a machine with RSAT: Active Directory tools installed (or directly from a DC).



  • Launch PowerShell as Administrator.



  • Use the Active Directory module:


    Import-Module ActiveDirectory





Script to Create the Server Object


# === Set parameters ===
$orgName = "YourOrgName" # Replace with your actual Exchange org name
$serverName = "ArgEX-temp"
$domainDn = "DC=argofield,DC=local"
$schemaCategory = "CN=ms-Exch-Exchange-Server,CN=Schema,CN=Configuration,$domainDn"

# Distinguished name for new server object
$targetPath = "CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=$orgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,$domainDn"

# === Create the server object ===
New-ADObject -Name $serverName `
-Type "msExchExchangeServer" `
-Path $targetPath `
-OtherAttributes @{
cn = $serverName;
name = $serverName;
objectCategory = $schemaCategory;
serialNumber = "Version 15.0 (Build 1497.2)";
msExchServerRole = 54
}



What This Does:






























AttributeValuePurpose
cn, nameArgEX-tempObject identity
objectCategoryFull DN to Exchange Server schema classRequired by AD schema
serialNumberVersion 15.0 (Build 1497.2)Matches CU23
msExchServerRole54 (2+4+16+32)Mailbox + CAS + FrontEnd + UnifiedMessaging



What to Do Next


Once this is created:



  1. Try uninstalling Exchange 2013 again:


    setup.exe /mode:uninstall /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF


  2. If more errors arise (e.g., Set-MailboxServer tries to access sub-objects like InformationStore), we can create dummy placeholders under the server object to satisfy setup.






Important Notes



  • This won't revive Exchange functionality - it's just to appease the setup gods and let you uninstall or clean up gracefully.

  • Don't use this approach in production unless you're removing a failed Exchange server and the original object is unrecoverable.




Would you like me to extend this script to also create a dummy InformationStore or mailbox database object, in case setup.exe needs it during uninstall?



drdread
  • drdread
  • 100% (Exalted)
  • Advanced Member Topic Starter
a day ago
I only have CAS and mailbox installed
sirclesadmin
a day ago

Perfect, - that simplifies things. For Exchange 2013 with only the Mailbox and Client Access roles installed, you can safely set msExchServerRole = 6.




Why 6?


Because Exchange 2013 roles are represented as bitwise flags:

























RoleBit Value
Client Access2
Mailbox4
Unified Messaging16
Front-End Transport32

So:


CAS (2) + Mailbox (4) = 6

This is the correct minimal value for your setup.




Revised PowerShell Script


Here is a clean and corrected PowerShell script that will recreate your missing Exchange 2013 server object with Mailbox + CAS roles:


# === Set parameters ===
$orgName = "YourOrgName" # <<-- Replace with your actual Exchange org name
$serverName = "ArgEX-temp"
$domainDn = "DC=argofield,DC=local"
$schemaCategory = "CN=ms-Exch-Exchange-Server,CN=Schema,CN=Configuration,$domainDn"

# Distinguished name where the server object should live
$targetPath = "CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=$orgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,$domainDn"

# === Create the Exchange 2013 server object ===
New-ADObject -Name $serverName `
-Type "msExchExchangeServer" `
-Path $targetPath `
-OtherAttributes @{
cn = $serverName;
name = $serverName;
objectCategory = $schemaCategory;
serialNumber = "Version 15.0 (Build 1497.2)";
msExchServerRole = 6
}



Then try uninstall:


setup.exe /mode:uninstall /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF

This should now allow the uninstall to progress past the Set-MailboxServer error.




Optional: Add Dummy InformationStore (if setup still fails)


If the uninstall throws an error about InformationStore or mailbox database objects, we can create a child object under your new server DN to spoof that. Let me know and I'll generate that for you.




Let's see if this script lets setup complete - and if not, we'll go one level deeper and trick it with a database stub.



drdread
  • drdread
  • 100% (Exalted)
  • Advanced Member Topic Starter
a day ago
Is front end transport the smtp proxy or part of normal exchange install?
sirclesadmin
a day ago

Great question, - and one that cuts to the core of Exchange 2013's architectural shift.




Is "Front End Transport" optional? Or always present?


The Front End Transport (FET) service is always installed on the Client Access Server (CAS) role in Exchange 2013.


So if you installed CAS, then yes - you have FET. But you didn't choose it explicitly; it came as part of the CAS role.




What is Front End Transport?


It's not a full SMTP server, but rather a stateless proxy that:



  • Accepts inbound SMTP connections (port 25)

  • Performs basic protocol filtering and header sanitation

  • Forwards mail to the Mailbox server's Transport service

  • Also proxies outbound mail for internal and Internet destinations via the backend



Think of it as the Exchange equivalent of Postfix sitting in front of Sendmail - a lightweight, stateless relay.





Services Breakdown (Exchange 2013)





























RoleService NameInstalled WithFunction
CASFrontEndTransportCASSMTP proxy / relay
MailboxTransport (HubTransport)MailboxFull message processing pipeline
MailboxMailboxTransportSubmission / DeliveryMailboxDB integration



So, in your case:


You do have the Front End Transport role installed because you installed CAS.


Therefore, your recreated AD object's msExchServerRole should technically be:


CAS (2) + Mailbox (4) + FrontEnd Transport (32) = **38**



Final Recommendation:


Use:


msExchServerRole = 38

That way, it mirrors what setup expects to find - and avoids weird uninstall errors tied to mail flow or protocol handling.




Let me know if you'd like me to regenerate the PowerShell with 38, and whether you need a dummy CN=Protocols or CN=InformationStore container to satisfy setup. You're almost there.



drdread
  • drdread
  • 100% (Exalted)
  • Advanced Member Topic Starter
a day ago
OK so is this monitoring that is causing the problem?:'
U:\>C:\Users\argsupport\Desktop\cu23\setup.exe /mode:Uninstall

Microsoft Exchange Server 2013 Cumulative Update 23 Unattended Setup

Mailbox role: Mailbox service
Mailbox role: Unified Messaging service
Mailbox role: Client Access service
Mailbox role: Transport service
Client Access role: Front End Transport service
Management tools
Client Access role: Client Access Front End service
Languages

Performing Microsoft Exchange Server Prerequisite Check
FAILED
Configuring Prerequisites 100%
The following error was generated when "$error.Clear();
try
{
$Target = $env:COMPUTERNAME
try
{
$exSrv = get-ExchangeServer $Target -ErrorAction SilentlyContinue

}
catch
{
Write-ExchangeSetupLog -Warning "Unable to set monitoring and serv
er state to inactive. Setup will continue.";
}

if ($exSrv -eq $null)
{
Write-ExchangeSetupLog -Warning "$Target is not an Exchange Server
. Unable to set monitoring and server state to inactive. Setup will continue.";

return
}

Set-ServerComponentState $Target -Component Monitoring -Requester Fu
nctional -State Inactive
Write-ExchangeSetupLog -Info "Monitoring has been set to Inactive wh
ile uninstalling Exchange."

Set-ServerComponentState $Target -Component RecoveryActionsEnabled -
Requester Functional -State Inactive
Write-ExchangeSetupLog -Info "RecoveryActionsEnabled has been set to
Inactive while uninstalling Exchange."

Set-ServerComponentState $Target -Component ServerWideOffline -Reque
ster Functional -State InActive
Write-ExchangeSetupLog -Info "The server state has been set to Inact
ive while uninstalling Exchange."
}
catch
{
Write-ExchangeSetupLog -Warning "Unable to set monitoring and server
state to inactive. Setup can not continue.";
throw;
}
" was run: "Microsoft.Exchange.Data.InvalidObjectOperationException: Pro
perty ComponentStates can't be set on this object because it requires the object
to have version 0.1 (8.0.535.0) or later. The object's current version is 0.0 (
6.5.6500.0).
at Microsoft.Exchange.Data.PropertyBag.set_Item(PropertyDefinition key, Objec
t value)
at Microsoft.Exchange.Data.Directory.ADPropertyBag.set_Item(PropertyDefinitio
n key, Object value)
at Microsoft.Exchange.Data.ConfigurableObject.set_Item(PropertyDefinition pro
pertyDefinition, Object value)
at Microsoft.Exchange.Management.SystemConfigurationTasks.SetServerComponentS
tate.InternalProcessRecord()
at Microsoft.Exchange.Configuration.Tasks.Task.b__b()
at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String fun
cName, Action func, Boolean terminatePipelineIfFailed)".

The following error was generated when "$error.Clear();
try
{
$Target = $env:COMPUTERNAME
try
{
$exSrv = get-ExchangeServer $Target -ErrorAction SilentlyContinue

}
catch
{
Write-ExchangeSetupLog -Warning "Unable to set monitoring and serv
er state to inactive. Setup will continue.";
}

if ($exSrv -eq $null)
{
Write-ExchangeSetupLog -Warning "$Target is not an Exchange Server
. Unable to set monitoring and server state to inactive. Setup will continue.";

return
}

Set-ServerComponentState $Target -Component Monitoring -Requester Fu
nctional -State Inactive
Write-ExchangeSetupLog -Info "Monitoring has been set to Inactive wh
ile uninstalling Exchange."

Set-ServerComponentState $Target -Component RecoveryActionsEnabled -
Requester Functional -State Inactive
Write-ExchangeSetupLog -Info "RecoveryActionsEnabled has been set to
Inactive while uninstalling Exchange."

Set-ServerComponentState $Target -Component ServerWideOffline -Reque
ster Functional -State InActive
Write-ExchangeSetupLog -Info "The server state has been set to Inact
ive while uninstalling Exchange."
}
catch
{
Write-ExchangeSetupLog -Warning "Unable to set monitoring and server
state to inactive. Setup can not continue.";
throw;
}
" was run: "Microsoft.Exchange.Data.InvalidObjectOperationException: Pro
perty ComponentStates can't be set on this object because it requires the object
to have version 0.1 (8.0.535.0) or later. The object's current version is 0.0 (
6.5.6500.0).
at Microsoft.Exchange.Data.PropertyBag.set_Item(PropertyDefinition key, Objec
t value)
at Microsoft.Exchange.Data.Directory.ADPropertyBag.set_Item(PropertyDefinitio
n key, Object value)
at Microsoft.Exchange.Data.ConfigurableObject.set_Item(PropertyDefinition pro
pertyDefinition, Object value)
at Microsoft.Exchange.Management.SystemConfigurationTasks.SetServerComponentS
tate.InternalProcessRecord()
at Microsoft.Exchange.Configuration.Tasks.Task.b__b()
at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String fun
cName, Action func, Boolean terminatePipelineIfFailed)".

The following error was generated when "$error.Clear();
try
{
$Target = $env:COMPUTERNAME
try
{
$exSrv = get-ExchangeServer $Target -ErrorAction SilentlyContinue

}
catch
{
Write-ExchangeSetupLog -Warning "Unable to set monitoring and serv
er state to inactive. Setup will continue.";
}

if ($exSrv -eq $null)
{
Write-ExchangeSetupLog -Warning "$Target is not an Exchange Server
. Unable to set monitoring and server state to inactive. Setup will continue.";

return
}

Set-ServerComponentState $Target -Component Monitoring -Requester Fu
nctional -State Inactive
Write-ExchangeSetupLog -Info "Monitoring has been set to Inactive wh
ile uninstalling Exchange."

Set-ServerComponentState $Target -Component RecoveryActionsEnabled -
Requester Functional -State Inactive
Write-ExchangeSetupLog -Info "RecoveryActionsEnabled has been set to
Inactive while uninstalling Exchange."

Set-ServerComponentState $Target -Component ServerWideOffline -Reque
ster Functional -State InActive
Write-ExchangeSetupLog -Info "The server state has been set to Inact
ive while uninstalling Exchange."
}
catch
{
Write-ExchangeSetupLog -Warning "Unable to set monitoring and server
state to inactive. Setup can not continue.";
throw;
}
" was run: "Microsoft.Exchange.Data.InvalidObjectOperationException: Pro
perty ComponentStates can't be set on this object because it requires the object
to have version 0.1 (8.0.535.0) or later. The object's current version is 0.0 (
6.5.6500.0).
at Microsoft.Exchange.Data.PropertyBag.set_Item(PropertyDefinition key, Objec
t value)
at Microsoft.Exchange.Data.Directory.ADPropertyBag.set_Item(PropertyDefinitio
n key, Object value)
at Microsoft.Exchange.Data.ConfigurableObject.set_Item(PropertyDefinition pro
pertyDefinition, Object value)
at Microsoft.Exchange.Management.SystemConfigurationTasks.SetServerComponentS
tate.InternalProcessRecord()
at Microsoft.Exchange.Configuration.Tasks.Task.b__b()
at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String fun
cName, Action func, Boolean terminatePipelineIfFailed)".

Prerequisite Analysis COMPLETED

The Exchange Server setup operation didn't complete. More details can be found
in ExchangeSetup.log located in the :\ExchangeSetupLogs folder.'
sirclesadmin
a day ago

Yes, - you've hit the nail directly on its head.




The Core Problem:


Exchange setup is trying to mark the server as offline for monitoring purposes, using:


Set-ServerComponentState -Component Monitoring -Requester Functional -State Inactive

But the AD object it's trying to update has this:


The object's current version is 0.0 (6.5.6500.0)

That version (6.5.6500.0) = Exchange 2003 base schema version - a totally incompatible, pre-Exchange 2013 version!




Translation:


The Exchange server object in AD - either the one you re-created or a mislinked remnant - has the wrong msExchVersion attribute, so Exchange 2013 setup says:



"This object isn't new enough to support setting ComponentStates. I can't proceed."





What You Need to Do:


You must update the AD object's msExchVersion attribute to match Exchange 2013 CU23.




Correct msExchVersion for Exchange 2013 CU23


msExchVersion: 88218628259840

This is the decimal representation of the 2013 object version:



  • Hex: 0x4000000C0000

  • It means: "Exchange 2013 SP1+" (CU23 is valid)




PowerShell to fix the attribute:


First, locate your server object in AD:


$server = Get-ADObject -LDAPFilter "(cn=ArgEX-temp)" -SearchBase "CN=Configuration,DC=argofield,DC=local"

Then, set the correct version:


Set-ADObject $server.DistinguishedName -Replace @{msExchVersion="88218628259840"}

Or if you created the object and know its DN:


Set-ADObject "CN=ArgEX-temp,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=YourOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=argofield,DC=local" -Replace @{msExchVersion="88218628259840"}



Then Re-run Uninstall:


setup.exe /mode:uninstall /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF

You should now bypass the monitoring error and move further into the uninstall process.




Pro Tip:


You can check the attribute with:


Get-ADObject -LDAPFilter "(cn=ArgEX-temp)" -Properties msExchVersion | Select-Object Name,msExchVersion



You're getting very close now - this attribute mismatch is exactly what was preventing setup from finishing. Fix the version, and we're back in the uninstall saddle. Let me know if you need help adjusting other attributes like ExchangeLegacyDN, AdminDisplayVersion, or serialNumber.