Number=9 Description=Subscript out of range Source=SMSComponent

Was getting the following error in smsreporting.log on my sccm 2007 server.

Number=9 Description=Subscript out of range Source=SMSComponent

From there I found a few answeres but it seems to be ASP Buffer Limit in IIS. The default is 4mb and changing that seems to be the fix for that error.

I'm going a little further as I'm turning off the buffering and going to keep an eye on things. Yikes! Plus if I just fix things there will be nothing to post here. :)

WSUS Still No Status **Fixed**

Windowsupdate.log file I had several of the following errors:

WARNING: SyncUpdates failure, error = 0x8024400D, soap client error = 7, soap error code = 300, HTTP status code = 200

WARNING: SOAP Fault: 0x00012c
WARNING: faultstring:Fault occurred
WARNING: ErrorCode:ConfigChanged(2)
WARNING: Message:(null)


With some research I stumbled across this having to do with SCCM being setup with SUP. Now if you've gone through my older posts you'd see that I had that role at one point and removed it. Well it apparently set the WSUS reporting to none so here is a link to the tool that will fix it.

WSUS Reporting Level

Basically run it at command prompt and select 1 for All. After I did this

WSUS Clients status not yet reported

Well about two days ago our WSUS server had crashed and I pretty much had to reload it. Now the problem I'm having is that all of the clients show as not yet reported. I've checked a couple things and first problem I found was the Virtual Directory named Selfupdate was not in IIS. I had to create that myself and set the rights and paths as follows:

Directory: %ProgramFiles%Update Services\SelfUpdate

Security: Anonymous Access Enabled

Now that is all that I found and it seems there is more to it. You also have to set

Security: Like above but also set Integrated Windows Authentication.

Execute Permissions: Scripts Only

From a client Computer I ran the folowing command:

wuauclt /resetauthorization /detectnow

Before I did the above the log file c:\windows\windowsupdate.log had the following errors/warnings

Cached cookie has expired or a new PID is available

Once I set all the above my client had connected and downloaded new updates. A good link to follow is

IIS Settings For WSUS

SCCM SMP 500 error

Just stumbled across the top solution. I'm going to try it now and see if my error goes away. Seems over night the error has happen 4 times. I'll post updates if it fixes my error

@@@@@@@@@@@@@@
@@@ SOLUTION 1 @@@@
@@@@@@@@@@@@@@

Issue: MP Control fails with HTTP test request failed, status code is 500, 'Internal Server Error' on a Management Point running a 64-bit OS hosting 32-bit (x86) based IIS. The MPControl log contains the following:

Call to HttpSendRequestSync failed for port 80 with status code 500, text: Internal Server Error SMS_MP_CONTROL_MANAGER 1/23/2008 5:53:30 PM 4792 (0x12B8)
Http test request failed, status code is 500, 'Internal Server Error'. SMS_MP_CONTROL_MANAGER 4792 (0x12B8)

The IIS Logs may also show the following:

W3SVC1 192.168.0.35 CCM_POST /ccm_system/request - 80 - 192.168.0.105 ccmhttp 500 0 193
W3SVC1 192.168.0.35 CCM_POST /ccm_system/request - 80 - 192.168.1.109 ccmhttp 500 0 193
W3SVC1 192.168.0.35 GET /SMS_MP/.sms_aut MPLIST 80 - 192.168.0.35 SMS_MP_CONTROL_MANAGER 500 0 193
W3SVC1 192.168.0.35 CCM_POST /ccm_system/request - 80 - 192.168.0.61 ccmhttp 500 0 193

Browsing to http://SiteServer/SMS_MP/.sms_aut?MPlist returns a 500 as well.

Cause: This problem occurs because the ASP.NET registry keys are missing. The ASP.NET registry keys are missing when you install ASP.NET after the Enable32bitAppOnWin64 Microsoft Internet Information Services (IIS) metabase setting is set to a value of 1. Because IIS is configured to run in 32-bit mode, the ASP.NET installation does not create the ASP.NET registry keys in the 64-bit registry. The ASP.NET installation creates the ASP.NET registry keys only in the 32-bit registry.

Resolution: To resolve this problem, follow these steps for 32-bit or 64-bit mode:

To enable 64-bit mode:

1. Click Start, click Run, type cmd, and then click OK.

2. To enable the 64-bit mode, type the following command, and then press ENTER:

cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0

3. Type the following command, and then press ENTER:

cd C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727

4. To install the 64-bit version of ASP.NET, type the following command, and then press ENTER:

aspnet_regiis -i

5. Type the following command, and then press ENTER:

iisreset

----

To enable the 32-bit mode:

1. Type the following command, and then press ENTER:

cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1

2. Type the following command, and then press ENTER:

cd C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727

3. To install the 32-bit version of ASP.NET, type the following command, and then press ENTER:

aspnet_regiis -i

4. Type the following command, and then press ENTER:

iisreset


@@@@@@@@@@@@@@
@@@ SOLUTION 2 @@@@
@@@@@@@@@@@@@@

In management Console I just started getting the following error:

SMP Control Manager detected SMP is not responding to HTTP requests. The http status code and text is 500, Internal Server Error

So far the fix that works 99% of the time is as follows

1. Remove the MP role and reporting role by highlighting the roles on the server and deleting them. Check MPSetup.log to make sure it is fully uninstalled.

2. Remove IIS

3. Reboot

4. Delete the Inetpub folder (C:\inetpub) I renamed to inetpub_OLD for safety

5. Reinstall IIS - I used server management and added the application server role back. Make sure to enable WEBDAV in the IIS console under web service extentions. **ALSO** add remove windows component and make sure BITS gets installed. otherwise error 1603 will show in the MPsetup.log

6. Add back the reporting point.

7. Add back the MP role and check the box to allow clients to use the MP. Check The MPSetup.log to make sure it install is successful.

8. Watch the MPcontrol.log file. May take up to 20 minutes for the normal HTTP 200 messages to appear, but it should work and communications should resume with your clients.

So thats it. Main things to check are the logs to make sure the install and unisntalls are successful other wise other errors may occur. I usually do a search for the log files. Also make sure BITS and WEBDAV are setup correct. WEBDAV just needs to be allowed. BITS needs to be seleted