I am not sure I follow.  If you are looking for how the CUCM facilitates MWI on/off in legacy and SCCP systems, then take a look at what Hailey posted.  With SIP integration, there is a service parameter for MWI On/Off CSS and I believe it is expected that a SIP Notify will carry the Message Waiting indication.

That being said, I had a different understanding of your question.  My original understanding was that you had extensions that had their light's lit and you wanted to reset the MWI status back to "off" (not lit) across all phones or a group of phones.  I assume as part of a migration process or something similar.  Now that I read Hailey's response I am not so sure what you are looking to do ;-)  Anyway, since I tested this out in my lab maybe it is of interest.

There is no command or bulk update process that targets the MWI setting itself.  However, you can reset the current MWI state using either the "run sql" command facility that is built into the CLI or via the AXL/SOAP API (i.e. using the AXL SQL Toolkit).  For example, let's say you wanted to turn off the MWI light for every line that has it lit.  You could use this command from the CLI.

admin: run sql update numplandynamic set tklampblinkrate_messagewaiting=1 where tklampblinkrate_messagewaiting=2

If you want to find out what the heck "lamp blink rate" value 1 means, you can use this command:

admin: run sql select * from typelampblinkrate

Likely, you will get this response:

enum name     moniker
==== ======== =====================
1    Lamp Off LAMP_BLINK_RATE_OFF
2    Lamp On  LAMP_BLINK_RATE_ON
3    Wink     LAMP_BLINK_RATE_WINK
4    Flash    LAMP_BLINK_RATE_FLASH
5    Blink    LAMP_BLINK_RATE_BLINK

It is a good idea to test things like this out first.  The CLI sql facility does protect you from doing something bad to the database, but this is still a non-standard approach to accomplishing what you are looking to do (or at least what I thought you were looking to do).  To test, you can select one line on one device.  Now, this is kinda ugly but I found that the CLI SQL facility wouldn't allow me to get fancy with the update query.  Anyway, an example for testing one directory number:

admin:run sql select n.pkid,n.dnorpattern, npd.pkid as npdpkid, npd.tklampblinkrate_messagewaiting from numplan as n inner join numplandynamic as npd on npd.fknumplan=n.pkid where n.dnorpattern ='9165552001'
pkid                                 dnorpattern npdpkid                              tklampblinkrate_messagewaiting
==================================== =========== ==================================== ==============================
52efb303-5ed0-4f3a-c247-16bee84f8567 9165552001  ad5bcd9f-29d9-4551-aaf4-85313be13bd8 2

So, the above gives us a bunch of crazy stuff.  What we care about is the npdpkid column value.  We will use this value to set the MWI status:

admin:run sql update numplandynamic set tklampblinkrate_messagewaiting=1 where pkid='ad5bcd9f-29d9-4551-aaf4-85313be13bd8'
Rows: 1

So, the output of this is quite unassuming but if you are sitting there looking at the phone, you will see that the light went out immediately.

I have tested this on my 7.1(3b) cluster but my schema notes say that the schema (with respect to this topic) is the same on 6.1.  I have shut down all of my 6.1 VMs while I am testing 7.1 and 8.0.  Let me know if you have issues and I can check the data dictionary in 6.1.

If you needed to do this individually as opposed to "all phone lines that have the MWI lit today" then you may want to run a query to export the data and then build a custom update file for use with the AXL SQL  Toolkit.  I discuss the toolkit and give an example on its use starting with this article:

http://www.netcraftsmen.net/resources/blogs/running-sql-queries-on-cucm-6x7x-using-axl-soap-toolkit-part-1.html

One word of warning.  DO NOT RUN THIS COMMAND:

admin: run sql update numplandynamic set  tklampblinkrate_messagewaiting=2 where tklampblinkrate_messagewaiting=1

Or anything similar to this command.  The reason is that all of the lines in the numplandynamic table would be affected.  This includes intercom extensions, translation patterns, route patterns, etc.  If you execute a command that turns MWI off if it is already on, then this shouldn't be a problem because only certain patterns should have this enabled in the first place.  But if you modify the MWI setting on an Intercom DN then that is a problem that would get really hairy if you did it to like 10, 100, 1000 numbers.

I also have to give the general disclaimer that I have tested this out in a lab scenario with a handful of phones and was able to toggle MWI on/off without issue.  But if you go this route, test and make sure you are able to support yourself.  You may also want to see if your existing VM system has a method that you can take advantage of.  Something a little more straighforward perhaps.

Now, if you find that you did not need all of this and just wanted to know how to integrate MWI then sorry to burn up your cycles.  I have had the need in the past to reset MWI to "off" globally and this was one of two methods.  I'll spare you the second one.

HTH.

Regards,

Bill

Please remember to rate helpful posts.