Just updated SCCM 2012 to SP1, and now in SQL Server, there are several processes being run by the SCCM server that are constantly in a "BROKER_RECEIVE_WAITFOR" state. Is this normal? Anyone know what these are for?

Looks like the new Notification Server released with SP1. These links will provide you with more details

http://myitforum.com/myitforumwp/2012/12/11/configmgr-2012-sp1-client-notification/

http://blogs.technet.com/b/configmgrteam/archive/2012/09/27/fast-channel-for-system-management.aspx

We are experiencing the same.

Problem is SMS_NOTIFICATION_SERVER waits for BROKER_RECEIVE_WAITFOR for 1 full hour before resetting the transaction. This very long running transaction is causing our transaction log file to grow to extremely high sizes when SCCM is active because it prevents the transaction log VLFs from being reused.

Was any solution found for this behavior?

Is there any additional configuration we might've been missing?

Is there any update to the SMS_NOTIFICATION_SERVER to play more gracefully in terms of SQL transaction length?

Is SMS_NOTIFICATION_SERVER even essential?

Thanks,

Radu

I recently (this week, coincidentally) reinstalled SCCM on a new server and migrated database to newly installed SQL Server, and I no longer see these suspended SMS_NOTIFICATION_SERVER messages. Prior to that, I just assumed it was normal operating behavior. The SQL Server on new box is exact same version as before, but server OS is different (now Server 2012 R2 Standard, was Server 2008 R2).

I'd have no problem with this BROKER_RECEIVE_WAITFOR wait if it wouldn't cause a long-running transaction that prevents the reuse of the T-log, thus overflowing the T-log file and disk.

We are running SCCM 2012 R2 with SQL Server 2012 Standard SP1 on Windows Server 2012 R2 Standard.

Just to prove the case, we temporarily stopped the SMS_NOTIFICATION_SERVER for the past day and there are no more T-log issues :-)

Nevertheless, we'd like to be able to use the SMS_NOTIFICATION_SERVER.

Unless I'm missing something, I'm hoping that there might be a CU for SCCM to fix this behavior.

Yes, I know this is an old post, but Im trying to clean them up. Did you solve this problem, if so what was the solution?

Since no one has answer this post, I recommend opening  a support case with CSS as they can work with you to solve this problem.