Information Technology Writing Analysis by Shelby Arnold

In this memo, Shelby Arnold strives to discover what it means to write in the workplace. She wrestles with assumptions about what it means to write, as well as new definitions and contexts that she has learned in class. Ultimately, she tries to convince her readers that writing is more than what we see in the classroom. After reading this, how do you think writing works in the workplace? How might it work in other communities, like churches or outreach programs? How do you define writing? As you read this essay, notice that the citation style is APA, sixth edition, which is the most current version.


TO: Professor Steve Smith

FROM: Shelby Arnold

DATE: October 18, 2016

SUBJECT: Writing as a Server Support Manager


To get a better idea of what my future career might look like, I decided to interview a professional. I am interested in information security, but a friend of mine recommended that I meet with Ross Davis, a Server Support Manager for the University of Louisville School of Dentistry, which is one of the teams within the Dental Informatics department. Ross’ job, along with the rest of the server support team, is to maintain the computing systems that back the academic, clinical, and research functions. They also help assist in troubleshooting over 900 computing devices.

As a Computer Information Systems major with a previous interest in dentistry, interviewing someone who gets to work on the technical side of dentistry was a perfect fit. I also work in the same building as Ross, but dealing with other software, so it was interesting to see a different technical field within the University. Although server support management did not involve as much information security as I was looking for, Ross mentioned that he still did some security; it just was not all that he did. This is an example of how IT careers will allow you to experience different sectors of the field.

Ross has worked with the University for two years following his experience in computer sales and service requests at Circuit City, as well as serving the country as a signals intelligence communicator and systems administrator in the United States Marine Corps for over four years. He generously shared with me some things he has learned along the way, as well as some insight on his daily operations and the writing that he does now as a server support manager. In this report you will find 3 pieces of writing that Ross shared with me: a status page, an information article, and an email; I analyzed each document by its purpose, the audience, and the structure.

Writing as a Server Support Manager

Interviewing Ross gave me a better understanding of the daily operations that are done as a server support manager. When asking about the kind of writing that is done, Ross said he did not really do too much writing other than making bulleted lists. There are many situations in which people would claim they do little to no writing, but as Winsor (1992) says, “perhaps we are ethnocentrically assuming that the only documents that should count as writing are those that most resemble the traditional English essay” (p. 337). Winsor makes a good point; I’m sure Ross writes practically every day but didn’t consider certain things as writing. After explaining that writing isn’t just your typical words on paper, Ross was able to give examples of a lot more writing that he does, such as, “making lots of diagrams, showing the logical flow of things, how things are set up physically, writing training documents, and change management- making sure that people understand what things are ongoing.” (Davis).

When it came to writing, I was curious to know whether there are any guidelines or restrictions in this field. Working for the University means there are general guidelines for everyone, but also since The Dental School is its own kind of separate entity, they have their own guidelines from the dean of The Dental School and also from main IT. The restrictions include federal regulations with the Health Insurance Portability and Accountability Act (HIPPA), which means they must protect patient information.

One thing that I found interesting after interviewing Ross was how he sets guidelines for himself from a security standpoint. He explained that the regulations in the Marine Corps helped him prepare for more relaxed environments. For example, if he is sending out a diagram to somebody that is not in the office, he will take out things like IP addresses and DNS names just in case someone gets ahold of the information and may find a way into the network.

I also spoke with Ross about group writing. This is something we often do in school, and I have heard it is common in IT positions. The Dental Informatics department does group work when it comes to large projects. They get together to collaborate, brainstorm, and start writing out the steps of what they’re doing, what they’re going to do next, what they screwed up, and what can be done better. Even though sometimes group writing may not be enjoyable, it is still something that has to be done.

In a related book, Collaboration and Team Work, it states: “Professional jobs require substantial education, and the sharing of information and opinions to get work done. Each actor on the job brings specialized expertise to the problem, and all the actors need to take one another into account in order to accomplish the job” (p. 3). In other words, professionals often utilize group writing because it makes for a better outcome due to the constant peer review and being able to bring together everyone’s ideas.

Status Page: “Informing Users of Incidents”


The first document analyzed was a status page. The purpose of the status page is to inform users of identified incidents regarding hardware and software within The Dental School. The Dental Informatics team troubleshoots and does maintenance on different computer equipment and programs, and updates the status page when they identify any known issues, as well as when those issues have been resolved.


Status pages are informational pieces of writing that alert users when there is scheduled maintenance, updates, functional issues, or outages. The target audience for the status page are users in The Dental School, primarily professors and students who are the end users of the hardware and software that the Dental Informatics team deals with. These professors and students should be familiar with the status pages because the computer equipment and programs that they regularly use have scheduled updates and maintenance, and most people know to either check the status page or are already subscribed to updates and receive individual status alerts.

Users will most likely feel aggravated when they go to use a microphone, virtual desktop, etc. and realize it does not work. The Dental Informatics team helps with this aggravation by keeping the status page updated with a list of things that are being worked on, as well as sending out alerts to subscribers about new incidents. The users can go to the status page to see if the particular hardware or software they are experiencing problems with is on that list of outages. They also have the option to subscribe to a particular incident, such as an incompatible microphone, and be updated via email or text message when the problem has been solved, as well as subscribe to all identified issues. Letting users know that the Dental Informatics team is aware of issues probably helps cut back on having multiple people contact the team about the same things.

While the status page informs users of known issues, it also encourages them that something is being done to solve the incident. Without the status page, users would have to call the Dental Informatics team each time they experience an issue. If the team just verbally told each user that the issue is being looked into, users would be less susceptible to believe that. It is also helpful that the status page updates every couple of seconds on its own; users do not even have to refresh the page, which uses ethos to suggest that the team is currently working on the problem. These pages also give a number to contact and a link to submit a work order; these alternatives create a favorable impression of the department.


Although the incidents on the status page may differ, each has a similar structure. They are organized by the date, what the issue is (microphone, projector, scheduled maintenance, etc.), the status–whether it’s resolved, investigating, identified, or monitoring– followed by an explanation of the incident, and each ending with a link to take you to the main status page, as well as the option to submit a work order if you are experiencing issues regarding that subject matter.

Figure 1- Color Meaning


Each different issue is color coded by its status as shown in figure 1. As you will see in the figure, examples of a partial outage (orange) and degraded performance (yellow) are given. This visual rhetoric helps emphasize the severity of the issue. The status page with all issues listed begins with the current issues, and is organized backwards by date. This way, people can look back and see progress of issues and whether particular ones have occurred before.

The status page alerts are written so often that a template was created “so that way when we have a major outage; DI team members can plug and play what they need to convey and push it to the users” (Davis). Essentially, team members choose a series of words that express the message they want to send, kind of like a canned response. This example of writing goes against what Winsor (1992) has to say about the free creating of meaning: “Many people have believed that when we really write something, we think it up all on our own and do creative, original, individual work” (p. 338). If the team were really doing original work, they would have to write out the messages every time rather than using the canned response. Since the team faces the same issues so often, their solutions are rarely creative.

The server support team is not doing creative, original work in this case, but they are still writing. Instead of having to type out the same concept with each incident, the canned response makes it easier and keeps each alert clear, simple, and uniform. These characteristics relate to something else Winsor (1992) argued, “The meaning any of us can make when we write is always constrained to one degree or another. Freedom to create meaning is never absolute because we always operate in communities that shape what we can say in a comprehensible way” (p. 338). This is true when it comes to writing status alerts; the server support team is constrained in their writing, especially since these alerts only cover certain aspects of hardware and software. The department is a community that shapes the way the status alerts are structured so that things are worded in a certain way. The team is constrained from writing things in their own words, but it is appropriate in a situation where different readers need to be able to understand. If a writer were to use certain terminology that only his colleagues understand, it would confuse the readers, which is how the pre-written responses are helpful. The canned responses keep each alert similar in structure and makes it easy for readers to understand. Also, being able to prepare a fast alert will save time for the team to fix the issue.

Informational Article: “How to Register a License”


The second document analyzed was an informational article. The article was written as a reference for the server support team to refer to when they need to perform maintenance on regularly used software in The Dental School.


Although the entire Dental Informatics department has access to this information, the target audience is the server support team, where Ross is a member. The article is for a dental imaging software, Ortho Insight 3D. The team performs maintenance on this computer program, and the article in this particular case is to teach the team how to register a license for this software.

Assuming this maintenance only occurs once a year (like most license registrations), even those who have performed this maintenance before will most likely need to refer back to the article to remind themselves what needs to be done. The same series of steps listed are performed on 25 machines, so this article is most likely only used to refresh the team’s memory. Even if they are seeing this article for the first time, it is structured in a way that is easy to follow. Wardle (2004) argues, “If new workers fail to write in ways that a workplace community of practice recognizes as effective and appropriate, the reasons may be related to identity rather than ability” (4). Some workers may ineffectively register the licenses without referring to the steps; the failure to follow the steps may be related to a worker assuming they know what to do rather than actually already having that experience. The informational article is available so that the team will use it to help refrain from taking any wrong steps and interfere with the maintenance or mess up the software. By having the article available, the department is protecting themselves, since they are responsible for mistakes their employees make, and users will have no excuse for not knowing how to perform this task.


The structure of the informational article is laid out very clearly. It is broken into three headings– summary, contact, and body. The summary explains what you will find in the remainder of the article; it even lists a table of contents. Under “contact”, you will find a link to a support page and a phone number. Within the body are symptoms (how to know when a license needs to be registered) and a list of steps on how to register those licenses. This rhetorical layout suggests that the steps are easy to follow. Even though this is a short article, the summary and table of contents helps users find what they are looking for. Instead of having to skim through the article to see if it includes a particular topic, the summary does that for you. If the article does include that topic, users can use the table of contents to jump to that section.

Email: “ Just a Quick Question”


The final document analyzed was an email. Ross came across a discussion online about how older BlackBerry phones will no longer synchronize with the email service that the University uses. Knowing that there was a user in The Dental School with this particular outdated phone, he turned to a colleague for help.


The colleague works at Miller Information Technology Center (MITC), referred to as main IT. The Dental Informatics Department does quite a bit of work with main IT and often go to them for system support. MITC is also a part of the University, so they work with similar issues and should be familiar with the communication that is done with Dental Informatics. Ross reached out to this colleague to ask if a particular phone would be affected by BlackBerrys discontinuation of support. This employee seems like a colleague that Ross works with often based on the absence of a formal greeting or closing. I assume the MITC colleague was already aware that an outdated Blackberry was floating around The Dental School and was experiencing issues, or else Ross would have given more explanation for why he was asking that question.

Based on an article that was found, Ross was able to present the fact that because the phone is so outdated, it will no longer support the user’s email account with the University. The article comes from a BlackBerry support website, which should deter the owner of the phone from having any doubts. Since there is only one known user with a phone that will not be compatible, this is not a crucial issue. If BlackBerry were to disable this feature on newer phones as well, then more people would be faced with the same issue. If that were to happen then it would be best practice for the University to send out a notification to everyone.


The email has almost no structure, even though it was just a quick question, neither the original email nor the response has a greeting and neither person signed their name. You can tell by the simplicity of the email and informality that the conversation was between two friends/colleagues who were already familiar with the topic. Since Ross and his colleague seemingly trust each other’s opinions, there is no reason for either of them to persuade the other that they are asking a legitimate question or that the given answer is credible.

According to Bertacco and Deponte (2005): “The use of speed-facilitating devices lacking in multidimensional stimulation might bring about important social-psychological consequences. Specifically, the authors expect users of such devices (a) to abbreviate their interactions and (b) to be more egocentric than individuals who communicate by means of either slow communication or face-to-face modes” (para. 4).  In other words, it is common to be brief and worried about your own self-interests when communicating through email. This particular email is short and gets straight to the point, which was the purpose in this case, but if this email were going to a user who was unfamiliar with this topic, or someone who Ross uses formal communication with, then it would be lacking critical pieces.

Final Thoughts

Interviewing Ross was a great way to get a better idea of what writing in my future career might look like. It was a great experience seeing things first hand as a server support manager, and even though I may not choose that particular path, I was able to relate the writing that he did to just about any Information Technology field I end up in.

The status page represents many problems I may come across working in the Information Technology field. When troubleshooting hardware and software, the job of the IT department is not only to fix the issues, but it is also important to keep users updated and let them know that it’s being solved. One way or the other, an IT professional will most likely have to report to someone about the status of their work, whether it’s their boss, colleagues, or the end users.

The informational article also represents documents I will most likely use in the IT field. It is impossible for one person to possibly remember everything they learn, so these kinds of documents are crucial to remind yourself how to perform certain tasks. Ross did not have formal schooling, which led to a lot of trial and error, but even for someone who has proper training and education, mistakes will be made and it is good to have documents like the informational article to refer back to.

I have realized that the IT field requires a lot of research; I have already begun to experience this first hand just working for a help desk. As you research, it is likely that you will come across things that will answer previous questions or relate to another topic. Ross could have come across the BlackBerry article in a number of ways, but what’s important is that he took what he found relevant and used that information to help solve an issue.

Working in the information technology field allows you to communicate and collaborate with other sectors of IT, and sometimes different fields. Even though Ross didn’t plan on being where he is today, working for the Marine Corps helped guide him. With the right experiences, Information Technology can take you down many paths towards a successful future.


Bertacco, M., & Deponte, A. (2005). E-mail as a speed-facilitating device: A contribution to the reduced-cues perspective on communication. Journal of Computer-Mediated Communication, 10, Retrieved 22 October 2016, from

Collaboration and team work: The role of information systems [PDF]. Global E-business and collaboration.  Retrieved from Learning_Tracks/Ess10_CH02_LT2_Collaboration_and_Teamwork.pdf

Davis, R. (2016, September 21). [Personal Interview]

Wardle, E. (2004). Identity, authority, and learning to write in new workplaces. Enculturation, 5(2). Retrieved from

Winsor, D. (Fall 1992). What counts as writing? An argument from an engineers’ practice. Journal of Advanced Composition, 12, 337-347. Retrieved from 2086586


Appendix A
Appdx AAppdx A2
Appdx A3

Appendix B

Appdx B

Appendix C

Interview Transcript- Ross Davis

Wednesday, September 21st 2016. 10:00 AM. University of Louisville Dental School

Me: So the purpose of this interview is to learn about the kinds of writing I may do in my career in the future… and how communication plays into the real world. So I’m just going to start with the basics… Are you from Louisville?

Ross: Mhm, yeahp.

Me: I looked online and you’ve worked here at The Dental School for two years now?

Ross: Yes, I started September 2014.

Me:  How do you like it?

Ross: Yeah! It’s a great place to work, I like it so far.

Me: So what do you do on a daily basis as a server support manager?

Ross: Well, as a server support manager, I’m in charge of making sure that the infrastructure that we have is all up to date and secure and that we’re still able to run clinical operations across the school. So we’re always pushing out major upgrades and making sure things are working, helping out where needed.

Me: Do you have to walk around like upstairs and stuff to check out their stuff?

Ross: Yeah, sometimes.

Me: Yeah so Jonathan mentioned your job is similar to information security… is it pretty similar?

Ross: Uh, yes and no. So when you’re a system administrator, you do do some security. Uh, I think the largest difference between what I do and an actual info sec person is that that’s all they focus on, is security. But we do have to focus on security cause thats a big portion of it especially because of HIPPA and having the HR and all that. But it’s not the only thing I do.

Me: I also saw too that you were a systems analyst a couple years ago.

Ross: Yeah I did signals intelligence for the Marine Corps before working here.

Me: Because those are the two fields I’m choosing between… Do you have a suggestion?

Ross: Um, well signals intelligence isn’t so much security, but there is a large security aspect of it because anything you do has to be top secret. You’re doing a lot more collections… So usually with signals intelligence, you would be the one that would go out somewhere and you would listen in on what people are saying on the phone, and reading their emails and things like that, intercepting them. Getting information out of them that’s useful then writing it up and passing it up.

Me: Did you see yourself doing this when you were my age, or is this even what you wanted to do?

Ross: You know, honestly I didn’t. At the time I really wanted to be a mechanic but after joining the Marine Corps and doing my time in there, I was like you know what, I might as well keep going with it; I’ve got the experience, I’ve got the certs. And it is a good field to work in. I have no regrets.

Me: So what prepared you the most, just past jobs or classes you took?

Ross: Uh, mostly experience I’d say. I actually, since I don’t have any formal schooling it’s been a lot of trial and error. You know, making very expensive training exercises by breaking stuff on accident.

Me: So I guess I’ll get into writing stuff… What kind of writing do you do?

Ross: Uh, I don’t do too much writing that often. Usually when I do its bulletins of things that are going on, what changes that are being made-whether its security, software or hardware… all those types of things.

Me: Yeah so in class we learned about writing and it opened my eyes to all of the things that writing could be. So like a wedding planner takes pictures and that’s considered writing because it shows people the location and all that… does that change your answer at all?

Ross: Actually yeah it does, there are a lot of things that we have to document that if you’re not going by the traditional, actually writing it out, making lots of diagrams, showing the logical flow of things, how things are set up physically, writing training documents, and change management- making sure that people understand what things are ongoing.

Me: Do you think I could collect some of that? Whether it’s an email or a spreadsheet?

Ross: Yeah, I could dig up some of that

Me: Okay, and I can always black out any kind of sensitive information…. Um so I think you kind of already answered my next question; do you have to follow certain guidelines/template?

Ross: Yes and no, it depends… so there are guidelines that we have to follow that are set by the University (by the University IT down on main campus). And then we’re our own kind of separate entity here. So we have our own guidelines that we have to follow that are sent down by the dean of The Dental School, the own guidelines that are set by main IT, and then also the federal regulations with HIPPA.

Me: So how much of your day does that consume, like just writing, or are you mostly on your feet like checking stuff out?

Ross: I’d say it’s about 50/50. It’s kind of a day to day thing; it depends on if something major is broken. But I’d say if it’s a normal day, maybe about 30% of my day is writing.

Me: So who do you communicate with? Just everyone that’s in this building?

Ross: For the most part it’s generally other members of IT community here at the University and in Louisville. I do spend a lot of time with main IT and the folks down there, you know I help them out with stuff and they help me out with stuff. And then of course I’m always running around on the clinic floor helping out people that are having issues… people will stop me and say “Hey, I’ve got this issue can you help me out with it?”

Me: So people stop you to ask basic computer questions as well just cause they know you’re IT?

Ross: Oh yeah. And sometimes it’s nice to get out of the office just to do stuff like that. Stretch your legs a little bit.

Me: What kind of writing do you receive? Same kind of thing like emails… reports?

Ross: Yeah usually emails , reports, training documents, a lot of business papers. A lot of things like BAA’S ( Business  Administration or Business Associates)

Me: Who sees your writing? Is that mostly for you or do you have to send it to people?

Ross: I share it pretty openly, at least within the members of my team and to those that need it outside of my team would usually be the folks down at main IT.

Me: Do you ever do group writing? Like a couple people working on the same thing together?

Ross: Yes, depending on the larger the project the more people we are going to have working on it. So, we usually get together and start collaborating, brainstorming and start whiteboarding the steps of what we’re doing, what we’re going to do next, what did we screw up, what we can do better.

Me: Do you enjoy that?

Ross: Uh, depends on the project. I’d say most of the time cause it’s always good to go back over your work and try to learn from it. But if something was a major soup sandwich then it’s not enjoyable for anybody. But it’s still something that needs to be done.

Me: Yeah cause doing group work now is just like omg… it kind of just depends on the kind of people you work with. Have you ever had a problem with that?

Ross: Yes and no. When I was in classes I had some groups that were, you know… you always get that one person who doesn’t wanna do anything, they always sit in to the side and look at the other person that just doesn’t wanna talk.

Me: Are there ever times where there is miscommunication at work?

Ross: Oh yeah. That happens fairly often, but that’s going to happen with just about any work environment. Usually when that happens  it’s all about how you rectify and how you move on with it.

Me: So is there ever times where you mess up like a report or something?

Ross: Oh yeah…

Me: Do you ever have to yell at anyone or like confront them?

Ross: Uh thankfully not here. Since I’ve been out of the Marine Corps , I’ve not had to yell at anybody. I’m very grateful for that.

Me: You hated that?

Ross: I didn’t hate having to yell at people, but it’s nice that it’s not something that I have to do all the time. As much as I love the Marine Corps, Marines are some of the best people and some of the stupidest people you’ll ever meet.

Me: And you said there was HIPPA restrictions, is there any other kind of stuff like that that restricts your writing?

Ross: Here it’s definitely more about protecting personal information, like patient information, medical treatments… as long as that kind of information is scrubbed then we’re usually fine. But there are some guidelines that I have set for myself from a security standpoint. If I’m sending out a diagram to somebody and it’s not somebody in the office, I will take out things like IP addresses and DNS names off the servers so that way if someone else got ahold of the information  and they find a way to the network, they’re not going to be able to look at it and go “oh I know exactly where to go”

Me: It’s good you do that on your own then… a lot of people wouldn’t think of it.

Ross: Yeah a lot of people do don’t it and it’s one thing that I’m grateful for with all the regulations in the Marine Corps is that it helped prepare me for environments that were way more relaxed, so I don’t make that screw up and then end up sinking the ship.

Me: Do you do any kind of writing outside of work? Like at home, do you write for fun or anything?

Ross: Not really, no. Just Facebook status’ that’s about it.

Me: Okay, well I think that is all I have… It was nice meeting you!

Ross: Nice meeting you too!

Me: Thank you again!

Appendix D

Follow Up Questions


Attached are a few documents that you requested for your paper. One is a sanitized version of one of our server rack diagrams, the second is a screenshot of our StatusPage that we use to alert users about any upcoming maintenance or outages ( and the third is a training document we provide to users to assist them in accessing our virtual environment.

Feel free to reach out if you need anything else!


Perfect! A couple of questions…

The server rack diagram- who uses it? Just the Dental Informatics Team? What is its purpose?

The status page- Is this something that you write or is it like a canned response? Also, how do users see it? Do they have to go to that website to view all outages/ upcoming maintenance? Are outages pretty common?

The training doc- Under what circumstances would users need to use the virtual environment? Are the users anyone in The Dental School? (The only virtual environment I am familiar with is VMware… I can get on it from home and access things I saved on my school account)


The server diagram is mostly for the Dental Informatics team and the infrastructure team with Main IT. Since they house our hardware, we do a lot of work with the folks down there, so it’s imperative for us to share information.

The statuspage is written but it’s also a canned response. I put together the outage template so that way when we have a major outage; DI team members can plug and play what they need to convey and push it to the users. Every time we send out a statusupdate, it updates the website and sends both an e-mail and SMS to their phones, so we can keep them up to date on the latest issues and maintenance. Thankfully outages are pretty uncommon but it is nice to have a reporting tool to get the word out so we’re not having our help desk line get clogged while simultaneously troubleshooting overarching issue.

All of our users use the virtual environment. Instead of deploying the traditional model of PC’s out to users stations, we use Wyse Thin Clients, which allow us to stream a virtual desktop with a fraction of the mess involved. For our Virtual Desktop Infrastructure (VDI), we use Citrix XenDesktop and Citrix XenApp, which allows us to deploy a full desktop or various applications to any station across the school. We also use VMWare but it’s for the back end systems as opposed to the VDI. I believe the Business school uses VMWare Horizon instead of Citrix XenDesktop but I may be wrong.


When you refer to Main IT, are you talking about the one on Belknap campus? Do you have any examples of communication you do with them?

Also, how often do you use your phone for writing? And I forgot to ask you about the walkie talkie you had, what is its purpose and how often do you use it?


Yes. We generally refer to them as Main IT or MITC (Miller Information Technology Center). I do have some examples of communication with them but sadly I can’t share it because of the information in it but we do work closely with almost all of the departments to help maintain operations.

And I use my phone pretty often for writing. Generally for quick notes if someone stops me to talk about something while I’m out and about. And the walkie talkie is for us to maintain contact with our technicians while they’re out handling calls. If they run into an issue that’s difficult to troubleshoot, they can use the radio to contact either my team or the applications team for assistance. It helps cut down on the time of resolving help desk tickets by having a direct line of communication back to the office without having to fuss with a phone or any texts/emails. Especially if we’re out supporting one of our satellite clinics.


That helps, thank you! I may have more questions once I get deeper into this assignment but you have been a huge help!


No problem! I’ve only barely scratched the surface for classes with my degree but understand the pain of trying to complete assignments like that. Feel free to reach out anytime!


Hey, me again!

I am hoping to get some more writing from you, particularly things that you wrote. The status page is good because you said you put together the template. Also, I know you said you cannot share writing you do with MITC, but if there is some kind of similar communication you do with other departments, (of course you can black out any kind of sensitive names, IP addresses, etc.) that would really give me a better idea of the kind of writing that is done.

Other ideas are emails you may have sent, a to-do list you made, notes you left for yourself when someone may have stopped you when something was broken… things like that. My purpose is to look at the writing and explain its purpose, the audience, and who else might be affected by the writing (like a supervisor, other employees, or the public).


Sure thing!

The first attachment (KB) is a screenshot from one of our knowledge base articles. I put this together as a reference for my team in case they need to perform maintenance on a dental imaging software, Ortho Insight 3D. This is shared across the entire Dental Informatics department so it’s available to any of our staff but it is mostly tailored towards to my team, the Server Support Team.

The second attachment (Go Live Notes) is a screenshot from an e-mail with one of our Citrix consultants. The list was used over the summer when we were upgrading our Citrix Infrastructure and gave us a reference point for our testing before pushing it into production. This was shared amongst my team and the rest of the department to help minimize the impact to users and keep things operational.

The third attachment (blackberry) was a quick conversation I had with a colleague at MITC about an old blackberry phone we have floating around at The Dental School. The phone itself is extremely outdated and is soon to be so out of date that they will no longer be able to connect said phone to their work e-mail. While the user impact is extremely small; it will be a large issue to the person who owns it and it’s a good example of how intertwined we are with MITC for system support.


Perfect! Thank you so much!

As for the Blackberry, was the Reddit page just something the MITC colleague came across and knew it would affect that person or was the person having problems?


I was out of the office Monday and Tuesday so I didn’t see your note until now. The article on reddit was something I came across but I knew that we had an aging blackberry floating around somewhere within the building. But it was a combination of both knew it would affect that person and that the person is having problems (because their phone is ancient).


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s