Your browser is incompatible with this site. Upgrade to a different browser like Google Chrome or Mozilla Firefox to experience this site.
1040 Results Found
In the last two posts I discussed aspects of services in the context of some landscaping work that I’m having done. This is clearly what many people would call a “non-IT example.” I often use similar examples in my classes. However, I might initially describe an example that seems unrelated to IT, but will conclude with a challenge to students. That challenge is, “identify the IT in this example.” The truth of the matter is that most businesses these days are underpinned by some form of information technology. In fact, technology has become so ingrained into everyday services that often even the service providers themselves don’t realize how technology supports their business.
Lessons learned is a theory, or conclusion, based on evidence at a given time and describes what went wrong (as well as what went right) throughout the lifecycle of a project. Although it’s completed during the project closeout process, it should occur during the entire project lifecycle to ensure all information is captured and documented. Consequences of not having a project review of lessons learned are the increased likelihood of repeating actions that might have caused:
Previously I discussed service providers and their risks in the example of my involvement with a landscaping company. ITIL clearly states that services, “…deliver value to customers by facilitating outcomes customers want to achieve…” However, sometimes organizations and people focus on outputs as opposed to outcomes, which sacrifices some of the value of the service. This leads to a question, what is the difference between an outcome and an output?
Global Knowledge Course Director and Lab Topology Architect Joey DeWiele, a specialist in Unified Communications, explains the difference between Cisco's Call Manager Express & Call Manager.
This week we'll review the IPv4 Address Classes including subnet masks, examples of Class C, Class B, and Class A subnet masks, and planning IPv4 addresses.
As mentioned in last week’s post, interviews that require ITIL Intermediate level knowledge will most likely be targeted to specific process areas and activities. If I interviewed someone for a job that required ITIL Intermediate level knowledge, in addition to other questions about the specific technical responsibilities of the job, I might ask the following questions:
“Twisted Pair” is another way to identify a network cabling solution that’s also called Unshielded Twisted Pair (UTP) and was invented by Alexander Graham Bell in 1881. Indoor business telephone applications use them in 25-pair bundles. In homes, they were down to four wires, but in networking we use them in 8-wire cables. By twisting the pairs at different rates (twists per foot), cable manufacturers can reduce the electromagnetic pulses coming from the cable while improving the cable’s ability to reject common electronic noise from the environment.
Global Knowledge practice director for cloud solutions, Hank Marquis, explains the people, process, and technology aspects of cloud computing.
Both technologies, Ethernet and FC, satisfied the two conditions at that time, but there was a catch. Read more.
Here are seven tips for working with vSphere, including: Logging in via Command Line, dealing with connection problems using ssh to an ESXi host; network performance issues; possible storage problems; Log Files to View in vSphere ESXi 5; network performance troubleshooting; migrating to a virtual machine using VMotion.