configmgr console crashes with error “input string was not in a correct format”

i recently posted a fix to a console crashing condition with configmgr.  looks like it’s round two.  one of the configmgr admins here ran into this issue and asked me about.  this should be an entertaining post, especially when i highlight the advice from microsoft on how to fix this problem.  let’s start, shall we?

to begin with, the console crashes, from any machine, when you try to view the settings of specific active directory discovery methods.  this was occurring on two different servers and not always the same ad discovery method.  the only thing of interest that both servers had in common was that they were migrated to new hardware and had run through the site recovery wizard.

i captured the message that fires up whenever a crash condition occurs.  it looks like the likely offense is this message: Input string was not in a correct format.

that usually means site control configuration file corruption to me.  note that if you modify your site control file, you probably won’t get any support from microsoft.  make sure you have a good backup.

 

do not follow these steps

before we go on with how you fix this problem, let’s review how microsoft pss believes you should fix this problem.  here’s the first set of steps.

1. Logon or RDP to SCCM Server, close mmc and console
2. Delete the adminconsole cache file from : \document and settings\%username%\application data\microsoft\mmc  ; (NOTE: %username% is the currently logged in user ID)
3. Start mmc and open sccm console.

hmmm.  apparently the fact that this happens on any console or machine is of no concern.  to say the least, this did not fix the problem.  so we’ll go through the action anyway because you cannot move forward without having done all steps prior and in the end having rebooted your server.  i’m sure that must be coming up…

in all fairness, these are actually good steps in capturing the problem when you’re poking around in the dark, in a very large room, with a very short stick.  after the first steps failed, this is what was sent:

1. Close sccm console
2. Install .net framework SP2 - if you don’t have this installed yet : http://www.microsoft.com/downloads/details.aspx?familyid=5B2C0358-915B-4EB5-9B1D-10E506DA9D0F&displaylang=en
3. Delete adminconsole cache file if it still exist (: \document and settings\%username%\application data\microsoft\mmc )
4. Enable admin verbose log :
   1. Navigate to <installationpath>\adminui\bin folder
   2. Open adminui.console.dll.config using a text editor or notepad
   3. Change the line <source name="SmsAdminUISnapIn" switchValue="Error" > to <source name="SmsAdminUISnapIn" switchValue="Verbose" >
5. From registry key : HKEY_CURRENT_USER\\CONTROL PANEL\DESKTOP\HUNGAPPTIMEOUT . The default is 5000, change this value to 10000 and reboot the machine
6. download procmon from : http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
7. RDP to sccm server, (mstsc/console)
8. Run procmon and reproduce the issue
9. Please send me :
10. Procmon log (.pml)
11. Event logs from event viewer (*.evt)
12. Adminui.log, smsprov.log

this is great and all but won’t fix the problem.  in fact, it’ll only help the pss engineer eventually arrive at what the exact problem is.  “Input string was not in correct format”.  seems pretty obvious to me.

 

consider these steps

i compared a good sitectrl.ct0 against a bad one for the area with issues.  what i noticed to be the problem was pretty simple to fix, actually.  it seemed the console was expecting to read in an integer value when it ran into a string value.

Exception Type: System.FormatException

Exception Message: Input string was not in a correct format.

Server stack trace:
  at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)

sure enough, in the sitectrl file, it was hitting a string.  here’s how a good file should look:

BEGIN_COMPONENT
    <SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT>
    <6>
    <MYSMSSERVER>
    PROPERTY <Run Count><><><1>
    PROPERTY <SETTINGS><ACTIVE><><0>
    PROPERTY <Startup Schedule><0001170000500008><><0>
    BEGIN_PROPERTY_LIST
        <AD Containers>
        <LDAP://OU=myComputers,OU=mySite,DC=myDomain,DC=COM>
        <0>
        <0>
        <LDAP://OU=myComputers,OU=mySite2,DC=myDomain,DC=COM>
        <0>
        <0>
    END_PROPERTY_LIST
    BEGIN_PROPERTY_LIST
        <Start On Master Site Control File Changes>
        <"Component","SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT|MYSMSSERVER">
    END_PROPERTY_LIST
END_COMPONENT

and here’s how the broken one looked:

BEGIN_COMPONENT
    <SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT>
    <6>
    <MYSMSSERVER>
    PROPERTY <Run Count><><><1>
    PROPERTY <SETTINGS><ACTIVE><><0>
    PROPERTY <Startup Schedule><0001170000500008><><0>
    BEGIN_PROPERTY_LIST
        <AD Containers>
        <LDAP://OU=myComputers,OU=mySite,DC=myDomain,DC=COM>
        <0>
        <LDAP://OU=myComputers,OU=mySite2,DC=myDomain,DC=COM>
        <0>
    END_PROPERTY_LIST
    BEGIN_PROPERTY_LIST
        <Start On Master Site Control File Changes>
        <"Component","SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT|MYSMSSERVER">
    END_PROPERTY_LIST
END_COMPONENT

 

notice the difference?  yes, the good file has two integers following the ldap location.  you’re asking yourself what these values represent, right?  good.  i wanted to capture it for later reference anyway.  i’m sure you would have figured this out on your own.  turns out they’re search options.  starting with the first one…

• <0> – Recursive
• <0> – Include groups

if the value is checked, it’s represented as <0>.  otherwise, unchecked is represented as <1>.  i put it in graphical format… :)