APPROVING AND PUBLISHING ANNOUNCEMENTS
The following instructions will detail how to approve an IT announcement and publish to the IT Announements website (http://www.it.okstate.edu/itannounce).
1.
Visit the URL: https://app.it.okstate.edu/itannounce/admin/Login.php
2.
You will authenticate using your O-Key credentials. You will then see the following screen:
3.
Click on the link “Edit/View/Approve Messages”
4.
The following page will appear:

5.
Under the Pending queue is an announcement titled "Test Announcement". This is an example of an announcement that requires review and approval. Click on the title of the announcement to open the page. For this example, you will see the following page…
6.
Please make note of the announcement title. Ensure that it is appropriately detailed, and appropriately spelled. In the example, the title is appropriate.
7.
Make note of the start date. Ensure that it indicates the date that the event did, or will, occur. The body of the announcement should indicate the appropriate start date as well,

however if you require confirmation, please contact the poster. In the example, the start date is appropriate.
8.
Make note of the end date. Ensure that it is at least several working days after the start date to allow plenty of time for the community to read the announcement. This is NOT the date that the event ended, but rather the last day that the announcement will publish to the website. In the example, the end date is listed the same as the start date. This should be changed to Monday, 04/03/2006.
9.
Note the Approved, Pending, and Rejected radio buttons. You will choose Approved once the announcement is ready to publish, or Rejected if the announcement will not publish at all. Usually, you will indicate in the title the reason for the rejection. The EOP person will not reject an announcement without first speaking with the Poster.
Announcements can be rejected even after publishing to the site.
10.
Ensure that all affected campuses have been indicated. Should you require clarification, contact the poster.
11.
Note the services affected. Ensure that the list is accurate, and spelled correctly. If the
EOP person requires confirmation of affected services, he/she will call the poster. In the example, the services affected are listed appropriately.
12.
In the Announcements Contact Information fields, the following information is listed by default: First Name = IT, Last Name = Helpdesk, Phone Number = 405-744-4357, and
Email = helpdesk@okstate.edu. Of course, if this is not the area that customers should contact in the event that they need further assistance, please modify this information as appropriate.
13.
Make note of the Reporting Contact Information. This will include the first and last name of the person posting the announcement, as well as their work extension and email address. Usually, the poster is not in their office, therefore you will need to contact their cellular phone. The CIS People Data Application in Lotus Notes continues to house this information.
14.
Read the body of the annoucement. Make any adjustments necessary to ensure the accuracy and consisitency of the announcement… a.
Announcements should include a detailed description of the event, buildings/areas/people affected, the service (s) affected, the date/time that the event occurred and the expected date/time that the event will end. b.
Time format: It is noted that some IT staff would prefer the use of the 24-hour format to list the time (i.e. 17:00 = 5:00pm). However, several customers did not care for this decision. Therefore, we will use the following format: 5:00PM (not
5:00 pm, or 5:00p.m.). c.
Date format: Reported feedback indicated that the date format preference is as follows: 03/17/2006 (not 17March2006, or 3/17/06). d.
Updates: Should any aspect of the event change (such as date/time of expected resolution), please contact the EOP phone. The EOP person will add the following text to the title of the announcement: "UPDATE:" The text of the title may require slight modification in order to fit the word UPDATE due to the character limitation of the field. In addition to the title change, the following text will be included in the annoucement: "UDPATE TIME DATE: Text of the update". In some cases, those that post an announcement for approval are able to update their own announcements. However, it is recommended that the EOP person is contacted for editiorial purposes. e.
Resolutions: Once the event is resolved, please contact the EOP phone. The
EOP person will add the following text to the title of the announcement:
"RESOLVED:". The text of the title may require slight modification in order to fit the word RESOLVED due to the character limitation of the field. In addition to the title change, the following text will be included in the announcement:
"RESOLVED TIME DATE: Text of the resolution".

f.
Please review the additional documentation which provides detailed descriptions of each type of announcement, including examples of updates and resolutions. g.
In the example, the date format is incorrect and should be changed to
03/28/2006. Also, the word "announcement" in the second sentence is misspelled and should be corrected. Finally, the word "please" is misspelled in the third sentence, also requiring correction.
15.
Once edited appropriately, click the radio button next to Approved at the top of the page.
16.
Click on "Submit" at the bottom of the page. This will publish the announcement to the
IT Announcements website (www.it.okstate.edu/itannounce).
17.
After the announcement is published to the website by the EOP person, those customers that have chosen to participate in the Listserv list will receive an email or a page. Each time the submit button is clicked by an approver, whether for an editiorial change, an update or a resolution, an email or page is sent. Those that have access rights to approve announcements will do well to bear this in mind. It is not recommended that an approver post several versions of a single announcement, but rather make all necessary changes during the initial round of editing. Any other changes should post as an UPDATE, in order to avoid confusion. Please see the additional documentation for examples of
UPDATES and RESOLVED status additions.
18.
Please contact your supervisor should you have any questions or concerns.

ADDITIONAL INFORMATION FOR EOP DEVICE CARRIERS:
1.
The EOP device, Siemens SX66, has several settings associated with it. Some of the more important area as follows: a.
A ring tone for inbound calls – This tone should be loud enough for you to hear when you are in a bustling environment. You will not always be at your desk when the EOP phone rings. The device is currently set to not only provide a ring tone, but also vibrate in the event of an inbound call. This is recommended. The phone will ring several times prior to routing the call to voicemail b.
A ring tone for inbound text messages – Like the ring tone for inbound calls, this tone should be loud enough to wake you up in the middle of the night. This setting is also set to vibrate in the event that a text message is received. The device will only notify you once. The only text messages you should receive are those generated by an IT announcement having been submitted for approval. c.
The Indicator LED – This LED flashes green when no event has occurred that has gone unnoticed. It will flash RED under the following circumstances… i.
You have an unanswered call ii.
You have an unheard voicemail iii.
You have an unattended text message that you have not viewed iv.
Your battery is low v.
Any other unattended event or notification d.
You will learn more about the device during hands-on training.
2.
When phone rings, answer as follows: "EOP Phone, this is *state your first name*"
3.
Ensure that you have at least the following information associated with each announcement: a.
Recommended category b.
Affected system or service (for example, do not simply post an announcement that the web cluster was down. Find out what services are associated with the web cluster, and list them in the announcement. Our average announcement reader will not be able to intuit this information) c.
Comprehensive list of affected campuses d.
Description of event e.
Number of affected customers or comprehensive list of affected building/areas f.
Date and time the event occurred (or will occur) g.
Date and time the event ended (or estimated date and time the restoration will occur) h.
The last date that the announcement will post to the website i.
Cause of the event j.
Regarding an update: 1) current status of event, 2) details of changes, 3) date/time of said changes k.
Regarding resolutions: 1) current status of event, 2) details of resolution, including what they did to resolve the issue, 3) date/time of said resolution
4.
PRIOR to publishing an announcement, you MUST ensure that you have a complete understanding of the situation.
Any questions you may have, the average reader of the announcement may have. It is the expectation and responsibility of the EOP person to ensure the accuracy, consistency, and readability of the announcement. Call the poster for clarification if need be.
5.
All announcements will be edited and approved to publish within 15 minutes of your receiving notification, via either telephone call or text message.

6.
The majority of calls will come in from Network Operations, Telecommunications, and
Systems. Other areas will contact you; however these three areas comprise the majority of announcements. a.
The staff members contacting the EOP phone are expected to post their own announcements. This is part of their job as administrators, and this has been communicated to them by their management. However, there will be times when they are unable to do so (due to lack of connectivity in the area, no time, etc.).
Under those circumstances, it is expected that they ASK if you would post an announcement on their behalf. b.
Ensure that they are able to give you all of the information you need to post an announcement for them. Refer to #2 for a list of some important information needed for announcements.
7.
If you are writing the announcement on behalf of the system admin or technician, or even reviewing an announcement for approval, ensure that the body of the announcement is written in such a way that every end user associated with OSU will read and need to understand it. These announcements are not meant to simply inform tech managers or other folks that are technically savvy.
8.
Be careful with acronyms. Ensure that if you use them, they are defined. For example, if an announcement included information about the SAN, you would state, "…the Storage
Area Network (SAN)…" Any further reference to "SAN" is appropriate with the acronym, as it has already been defined.
9.
If the system administrators or technicians write their own announcement, you will need to edit the announcement for the following items. Copy and paste into MS Word, if need be: a.
Spelling errors b.
Grammar and sentence structure c.
Date/Time format d.
Accuracy and descriptiveness e.
Polite tone, good customer service sound
10.
For your information, the following information has been provided in the instructions geared for Posters:
"At times, Information Technology may wish to soften an announcement in order to avoid undue confusion or anxiety. Under these circumstances, generalizing a particular aspect of the event may become necessary. For example, we may not wish to announce that IT is fighting a brute force hack attack, but rather state that IT is investigating an issue that may affect network connectivity for a particular area. It is recommended that strong words such as "suffer", "attack", or "failure" are softened to avoid unnecessary drama associated with an event.
As a poster of announcements, if you find that your announcement has been modified erroneously and now does not reflect your intended message, please contact the EOP person immediately.
He/She will be more than happy to adjust the announcement to meet the needs of your area.
NOTE: If you have posted an announcement for approval, and it is not published to the site within 15 minutes, please call the EOP person. They may not have heard the notification sent to the EOP device, or they may be experiencing complications of which you are unaware. If you cannot reach the EOP staff member, please contact the IT Helpdesk Manager or Charles McCann,
Director of Technology Support"

11.
It is recommended that you copy and paste the body of the announcement into a word document. By doing so, you will find that spell checking and text modification is faster.
Also, the IT Announcements page may time out on you. If this occurs, you will not have lost all of your hard work. NOTE: Please ensure that you have disabled "smart quotes" within MS Word prior to pasting into the Announcements application.
12.
If using the SX66 to post or approve announcements, you may want to ensure that you have several minutes to work on it. It takes a while when using the device, so announcements that require immediate approval, it is recommended that you find a computer so you can work quickly. If a desktop machine is not readily available to you, please contact the poster to let them know that you will have the announcement published as soon as you can. The majority of posters has experienced this type of call before, and will understand.
13.
Take this responsibility very seriously. This is one of only a very few methods by which
Information Technology is able to communicate to the OSU community. The accuracy and efficiency of our announcements will ensure that the reputation of Information
Technology is upheld.
14.
If you experience any complications with the IT Announcements website or server, please contact Brett Robins or Pam Coleman. They will assist you with the majority of complications, or provide a direction if they are not the appropriate area.
15.
Do not include the following characters in announcements (it disrupts the parsing process): < or > or ^. Contact Pam or Brett if problems arise with posting announcements to the website.
16.
We use the following phrases often. If the announcement includes any altered variation, please replace it with these versions… a.
We apologize for any inconvenience b.
Please continue to view this announcement for updates as they are communicated c.
Clients continuing to experience complications are encouraged to contact the IT
Helpdesk for further assistance
17.
Do not include the Happy Text in any announcement.
18.
PRIOR TO APPROVING ANY ANNOUNCEMENT , including updates and resolutions, the EOP person must contact Charles McCann by calling his cellular phone, office line or home phone. You will provide Charles with a description of the announcement. He will request any necessary clarification, and then issue the go-ahead to publish the announcement. If he is unreachable, leave a voicemail on his cellular phone briefly describing the announcement. He will call you via the EOP device, if necessary.
19.
Contact the Helpdesk after you approve an announcement.
The EOP person, or the reporting technician, should contact the Floor Desk to inform them of any event that requires an announcement.
20.
Please contact you supervisor should you have any questions or concerns.

EXAMPLE: OUTAGE/SERVICE INTERRUPTION
The following is an example of a proper Outage/Service Interruption announcement submitted for approval.
Please note the date and time format, as well as the services affected and the detailed description of the event. In this case, the IT Technician did not know what had caused the event; therefore

simply stating that it was caused by a malfunctioning network device (such as switch, or the main feed) was all we could announce at the time.
The following example will show the proper method by which this Outage/Service Interruption will be updated…
Please note that the title of the announcement now indicates that this announcement has been updated from its original version. Also, the body of the announcement includes the UPDATE at

the TOP of the text, and that the ORIGNAL ANNOUNCEMENT text separates the update from the original announcement.

The following example will show the proper method by which this announcement will include an additional update…
Please note the format of the title, in that it now reflect UPDATE(2). Due to some interested parties receiving pages as announcement notifications, indicating that this update is a SECOND update (different that the first update) attempts to prevent confusion. Also, please note that this update text is located ABOVE the text of the original update, also with an UPDATE(2) indicator.
Please change the number of the update, both in the title and body of the announcement, as more updates are required.

The following example will show the proper method by which this announcement will list as resolved…
Please note that the title of the announcement now reflects an indication that this announcement has been resolved. Also, the body of the announcement includes the RESOLVED indication
ABOVE the most recent update. The resolution will include, if possible, a detailed description of the cause of the event and what the technician did to resolve the event.

EXAMPLE: VIRUS ALERT
The following is an example of a proper Virus Alert announcement submitted for approval.
Please note that the title of the announcement does not include unnecessarily panicky text, but rather a simple and easily understood indication as to what information the reader may find in the body of the announcement.
Virus Alert announcements are generally posted by a member of the Systems Security team, and are usually quite lengthy. Details such as a description of the virus, the infection risk level, How

one's machine can become infected, what to look for in an email's subject line (or other "red flag" issues, of which the customer should be aware), what will happen to the customer should their machine become infected, suggestions for prevention and links to online sources for more information are typically included.
It is recommended that the start date indicate the date that Information Technology was informed of the risk, and that the end date is a sufficient amount of time in the future to ensure that the
OSU community has a chance to read the announcement and apply the appropriate measures for protection.
Generally, updates and resolutions to Virus Alerts are not necessary.

EXAMPLE: SCHEDULED DOWNTIME
The following is an example of a proper Scheduled Downtime announcement submitted for approval.
Please note in this example, the title indicates WHAT is affected and WHERE. The services affected are accurately described, and the body of the announcement details exactly WHY the service is affected, WHO is affected, and WHEN. In this particular example, the planned switch replacement may take an unknown length of time. Therefore, an exact estimated service

restoration time is not listed. However, a general statement that service should be restored that afternoon is included in order to indicate that the downtime will take hours rather than days.
It is also imperative that Scheduled Downtime announcements post well in advance of the interruption in service. For example, some areas may need to prepare for the downtime. It is recommended that a window of at least 24 hours is provided, more if possible.

The following example will show the proper method by which this announcement will be updated…
Please note the title change, services affected change, and the body of the announcement format.
The title has been changed from the original title, "USDA Network Downtime" to now include that the ETS building has been added. Additionally, the Services Affected field now indicates that not only network connectivity, but also access to the OSU Calendar will be affected. This additional service downtime is also noted in the body of the announcement.

The following example will show the proper method by which this announcement will list as resolved…
Please note that the title of the announcement now reflects an indication that this announcement has been resolved. Also, the body of the announcement includes the RESOLVED above the most recent update. The resolution also indicates that all services affected by the downtime have been restored. However, this may not always be the case. In the event that one service, such as network connectivity, has been restored but another service, such as the OSU calendar, is not, the proper procedure would be to post another UPDATE and not a RESOLUTION. The event is not resolved until all affected services have been restored.

EXAMPLE: IT NEWS
The following is an example of a proper IT News announcement submitted for approval.
Please note the detail provided in both the title and the body of the announcement. News items do not typically require an update or resolved status, but it can be necessary under certain circumstances. Most News items post for a significant period of time, and detail events that will occur that do not fit within the alternate announcement types.