• In 2007 there were 500 million connected devices or 1/10th of a connected device per person worldwide. In 2010, there are now 35 billion (5 connected devices per person). In 2013, Forester Research projects that there will be 1 trillion (140 per person) connected devices.
• In 2007 there were about 3000 total mobile applications. In 2010, there are 265,000 mobile applications. Current growth trends estimate in 2013 there will be 1.5 million mobile applications.
• In 2007 there were approximately 624,000 security threats (the document doesn’t specify what this really means). In 2010, there will be 2.6 million security threats. The Symantec and Cisco projection for 2013 predicts 5.7 million security threats.

It is amazing how much things in the IT world have changed in the past three years and taking that projection out another three years seems staggering. How is an organization supposed to handle the growing environment and the growing threats? Cisco offers some suggestions in this report:

1. Close gaps in situational awareness. Be aware of the totality of the network.
2. Focus first on solving “old” issues – and doing it well. Begin making improvements in the area of software updates and patches.
3. Educate your workforce on security – and include them in the process. Remember in information sec-u-r-it-y, You Are IT (U-R-IT). Kinda cheesy I know but it is a basic truth. We are all responsible for IT security.
4. Understand that one security border is no longer enough. Business has now become borderless and mobile.
5. View security as a differentiator for your business. “How an enterprise approaches security and responds to trends such as social networking and mobility can have a direct impact on ability to hire and retain talent.”

What do you think is going to happen in the next 3 years with regards to devices, applications, and security threats? Is the Cisco on target, or off base? Let me and other ITKE readers know your thoughts. Thanks for reading and let’s continue to be good network citizens.

One main way of protecting your organization is by applying patches. An article on Dark Reading proposes 4 Steps for Trimming Patch Management Time. Those steps summarized here are:

1. Level the patching field. Time-saver: Develop a patch priority list based on business criticality: Your business continuity/disaster recovery plan is a good starting place for establishing a hierarchy of patch deployments that will see the most critical exposures patched first, with lower risk or lower exposure vulnerabilities patched on a less fast-paced (and, ironically, less time-consuming) schedule.

2. Know which systems impose their own patch schedule. Time-saver: Maintain a list of critical systems’ regular maintenance and planned downtime schedules, and plan patch deployment accordingly, dealing with other more readily available systems in the meantime. Review and update system maintenance schedules (and their effect on other schedules) on a regular basis.

3. Know who needs to know and who signs off. Time-saver: Create and maintain a comprehensive patch deployment approval and sign-off path along with your systems inventory, including emergency and off-hour contact information for all personnel on the list.

4. Take time to test patches before going operational. Time-saver: Establish comprehensive patch test platforms, including platforms for new technologies and configurations ahead of time, and make their maintenance, readiness, and upgrades an ongoing part of your operations overhead and budget. Build a day of patch-test time into your patch deployment schedule.

What steps do you take to effectively manage patches for your organization? I think Dark Reading hit the nail on the head with this list. I urge you to go read the article in its entirety. Add your comments below.

Thanks for reading & let’s continue to be good network citizens!

The Startup Control panel tool window looks like the window below:

Startup Control Panel window

Using the application:

I have successfully run this utility on both XP and Vista. The dialog contains six to seven tabs, depending on your system configuration. Each tab represents one place where a program can be registered to run at system startup. These include:

• Startup (user) – the current user’s Startup folder in the Start Menu.
• Startup (common) – the common (all users) Startup folder in the Start Menu.
• HKLM / Run – the Run registry key located in HKEY_LOCAL_MACHINE. These apply for all users.
• HKCU / Run – the Run registry key located in HKEY_CURRENT_USER. These apply for the current user only.
• Services – system services that are started before the user logs in. This appears only in Win9x; on NT/2000/XP, use the Services control panel, or the Services item in Computer Management.
• Run Once – started once and once only at the next system startup.
• Deleted – programs go to the Deleted tab when you remove them from another location. They will not run at system startup, but will merely be stored should you ever want to use them again. If you delete an item from the Deleted tab, it is removed permanently.

Each page contains a list of the programs registered at that location. Use the checkbox to enable or disable individual items. Additional operations are available by right-clicking an item. You can select multiple items using the Shift and Control keys. Options include:

• New… – create a new entry. You can also drag & drop files from My Computer or Explorer.
• Edit… – edit an existing entry.
• Delete – delete the currently selected entry.
• Disable / Enable – disable or enable the selected entry. A disabled program will appear in the list with a special icon, and will not run at system startup. You can also use the checkbox next to an item to enable or disable it.
• Run Now – executes the program now.
• Send To – moves the entry from the current location to another.
• Press F5 to refresh the list at any time.

Hope you find this tool as useful as I do. Thanks for reading and let’s continue to be good network citizens.

Clint Huffman Analyzes PerfMon Logs! Mr. Huffman is the creator of the Performance Analysis of Logs tool found at Codeplex. I have found this tool very useful in tracking down server issues to show folks “it’s not the network!”

Shane Creamer Goes Deep on Performance Monitor! This is a very interesting presentation. There is a link to the video presentation portion and another link to the various audio formats. The video presentation has a very long gap in audio at the beginning (almost 12 minutes). This is because the video portion is only capturing the presenter’s audio portion and not the commentators’. You really should download both audio and video to get the full impact of the presentation.

Steven Choy Measures Server Performance!

Other topics that might be of interest includes SQL, Active Directory, IIS, cloud (Azure), Powershell, virtualization, SharePoint, information security, and many other Microsoft-centric technologies. I have subscribed to the RSS feed so I can keep up with new presentations as they are released. If you run any Microsoft technologies, or you just want to learn about some recommended best practices, then check out this resource. There might be something here that will help you “save the day”.

Thanks for reading and let’s continue to be good network citizens!

If you manage a network and have taken packet captures to work on a problem and have seen RST packets or if you need to do this at some point in your career, you need to understand the purpose and source of the RST packets. Take a few minutes, read this excellent article that is the best explanation that I have seen on this topic. You will become better informed and better able to understand the nature of the network beast.

Where do resets come from? (No, the stork does not bring them.)

Thanks for reading and let’s continue to be good network citizens.

The URL ping tool is described in the Microsoft IT Showcase: sharepoint Performance Optimization Technical White Paper. It is a C# script that will need to be compiled using the proper include files and configuration for your environment. I configured the script to log in CSV format the date, time and time to first byte from the webserver in question. Using the console output redirect pipe, I logged the information to a text log file. I configured a Windows scheduled task to run the URLping command over the time period of interest. The URLping command ran every 30 seconds logging the results to the specified text file.

During the same period, ever 30 seconds, I ran the fping utility from Kwakkelflap.com. The fping utility is much more flexible than the ping tool that is part of the Windows operating system. Some of the features that make fping so useful includes:

• Time between pings can be adjusted as needed from 1ms to 5s.
• Beep on every successful or unsuccessful reply allowing you to test your network status in the background.
• Ping multiple hosts with one simple command.
• Read a hostlist from a file
• Output redirection to a file for parsing.
• Ping with random data, or data you provide

The results from these two utilities were logged into two separate CSV files. Since the tests were running every 30 seconds, I could take the fping results and the urlping results and combine them into one spreadsheet for analysis. I wanted the units for the urlping and fping response times to be the same. I had to divide the fping results, which were in milliseconds (ms), by 1000 to convert the results to seconds to match the units of the urlping results. I then graphed the results. This information is shown below. The blue data points are the urlping results. The pink data points are the ping times.

URLping vs fping

During this sample period of 54 hours, the maximum urlping response time was about 30 seconds. The maximum fping response time was 0.4857 seconds (or 485.7 ms). The average urlping response time was 2.75 seconds and the average fping response time was 0.06 seconds (or 60 ms). As you can see, the network ping response times are much lower than the webserver response times.

We found it very interesting that there was an elevation in webserver response times from about 15:45 on 9/23/09 until just after 01:30 on 9/24/09. Note that the ICMP ping times were not elevated in a similar manner during this period. Further investigation on this issue would be required.

I ran a correlation statistical analysis to see if the fping (icmp) response times and url ping times were related. The graph below has the ICMP ping time as the X-axis and the url ping time as the Y-axis. As you can see, there is very little correlation (0.251) between the two measurements.

URL pings vs ICMP pings correlation

Based on this information, I was able to convince the team that the webserver response is  not related to the network response.

These tools are simple to use and should be in your toolkit as a network administrator. How often are you told that the network is having a problem yet you know that there is something else happening? Stay tuned… more to come!

So for now – share with the other ITKE readers ways that you look at network/application performance. What tools do you use to instrument and diagnose network issues?

Thanks for reading and let’s continue to be good network citizens.

The number 1 and 2 tools that can find out if there is a potential problem are ping and pathping (Windows XP). To test a network path between a client and host for latency and packet loss use a command something like:

ping -n 100 -l 1000 host.com

The -l is a LOWER case L. This command will send 100 pings of 1000 bytes each to host.com. This will give you latency for larger packets and also if there is any packet loss along the path. To get more details about where along the path packet loss is happening, use the command:

pathping host.com

This also does some pings along the path but will inform you of where along a traceroute the pings are getting lost. Note that ICMP must be enabled along the path for these commands to give you the information you may need to resolve the problems.

If the network path and hosts are all on your private network, you may need to capture some additional performance data. This is where network diagrams and service diagrams come into play. In a typical webserver farm environment, there are potentially a lot of “moving” parts along the path between a client and an application. The application path between a client might go something like this:

client -> LAN switch -> router -> WAN link -> router -> LAN switch -> web server -> database/index server

And then return through the same or similar path. This example has 8-9 various connections/hosts that could impact client application performance. This is no longer just a network data traffic issue.  I won’t be getting into the LAN switch or the router performance monitoring at this time. I will leave that for another posting. I will also make another entry discussing more about reviewing the server performance issues. Stay tuned.

So for now – share with the other ITKE readers ways that you look at network/application performance. What tools do you use to instrument and diagnose network issues?

Thanks for reading & let’s continue to be good network citizens.

Some of the presentation titles:

I Just Found 10 Million SSN’s

Sniff Keystrokes With Lasers/Voltmeters
Side Channel Attacks Using Optical Sampling of Mechanical Energy and Power Line Leakage

Anti-Forensics: The Rootkit Connection

Reversing and Exploiting an Apple® Firmware Update

The Language of Trust: Exploiting Trust Relationships in Active Content

Mo’ Money Mo’ Problems: Making A LOT More Money on the Web the Black Hat Way

The Conficker Mystery

These are just some of the titles available in the BlackHat 2009 Technical Conference media library. Check it out even if you are a web developer or an IT professional who manages desktops or networks or staff members who perform these tasks. You need to know what you are up against and possible methods to fight the threats.

Thanks for reading & lets continue to be good network citizens!

Maybe you forgot the steps before the RFP. You can go back and review:

The first post in this series covered two questions: Where are you? and Where do you want to go?

The second article in the series described the calendar of events or how many shopping days do we have?

This third article in the series covered the actual RFP (request for proposal) anatomy and contents.

This final posting will discuss the vendor selection process – planning for the wedding (or engagement).

Let’s get talking about vendor selection and awarding the contract!

Some important tips to remember when negotiating with a vendor during the proposal process.

• Get it in writing!
  • Anything the vendor verbalizes during the proposal process should be in writing in the contract. Ask for example copies of contracts in the RFP.
  • Vendors have short memories after the contract is signed unless you can show it in writing and both parties have agreed to the terms.
• Ask the vendors to use your response template format.
  • You can compare proposals much easier.
• Watch the minimum revenue commitment requirement(s)
  • Is it based across all services or per service?
  • Is it annualized or other period?
  • Ensure business downturn clause is included – think about the worst case
• Negotiate rate stabilization across commitment term
  • Technology upgrades should be cost neutral
• Make service contracts co-terminus (if multiple services and/or service terms are needed)
  • How often do you want to write new contracts

A lot has been written about Service Level Agreements (SLA’s). I am going to weigh in on some considerations that should be addressed during the vendor selection process.

• What items should be covered under SLA’s
  • Installation
    • North America vs ROW (rest of world)
  • Performance
    • Latency
    • Packet loss
  • Availability
    • Is it the vendor’s network or does it include CPE (customer premise equipment)? This one can get you if you don’t understand where the SLA endpoints are and what impacts performance and availability statistics)
  • Support
    • Are the support lines only available 8-5 Pacific time or do they have coverage for the timezones where you need it?
    • What is the recovery time objective (RTO)?
    • What is the recovery performance objective (RPO)?
    • What is customer’s responsibility vs vendor’s responsibility?
  • Billing
    • Do you spend a lot of time managing the billing end of things? Are one-time charges appearing much later after work is completed? Are disconnected services still being charged?

Some additional contract terms or clauses to consider to protect your organization:

• Innovation – new technologies/solutions at cheaper prices
• Key personnel – supplier and customer
• Transition & implementation planning
• Term of agreement
• Fixed or variable pricing
• Project schedule & deliverables
• Subcontractor approval
• Out of scope work
• Benchmarking – cost negotiation during agreement lifetime
• Audit
• Termination & migration
• Change of control of the vendor
• If customer company is acquired, can vendor assign contract to new owner

When evaluating the proposals from the suppliers courting your business, rate the results on a quantitative scale. Build this criteria checklist when building the RFP. Be sure your team is familiar and agrees with the criteria. An example evaluation document is shown below.

Evaluation criteria

Summarize the results for each vendor. Can discard bottom candidates unless there is a reason to keep them.
Begin firm and final negotiations with top 1 or 2 candidates. Hopefully incumbent provider (if there is one) will be one of the top candidates, or will they?

Vendor evaluation

We are now at the end of this series and you have finished selecting a vendor and the real work (honeymoon) begins. So what happens once you have made your selection? What things are left to work on?

• Communicate, communicate, communicate! – How else will you know when problems arise or things are going well?
• EGAP: Everything goes according to plan – RIGHT??
• Watch out for Blamestorming
  • The contract is right
  • The proposal was a dream
  • What is reality?

Thanks for reading these posts. Leave some feedback with other tips/tricks and ideas you have for others looking for managed services or negotiating a contract.

Have a great day and let’s continue to be good network citizens!

The second article in the series described the calendar of events or how many shopping days do we have?

This third article in the series will cover the actual RFP (request for proposal) anatomy and contents.

The fourth article will discuss the vendor selection process – planning for the wedding.

Hopefully you are now ready to dive into the RFP itself.

The purpose of a Request for Proposal (RFP) is to provide detailed information for suppliers about requirements discussing an implementation and possible budget limitations. It is focused on addressing a business issue with a solution for the customer organization.

Here are the typical elements of an RFP:

• Cover letter
• Project overview and administrative information
• Technical requirements
• Management requirements
• Supplier qualifications and references
• Supplier’s section
• Contracts and license agreements
• Appendixes

Now, more detail about each element.

The cover letter should have most, if not all of the following:

• Invite the provider to submit a proposal
• Present your company briefly
• Briefly describe existing environment
  • What are your pain points and critical success criteria
• Present the project timeline – goal: on time & on budget
  • Pre-proposal submission meeting: mandatory or voluntary
  • Notice of intent: is vendor interested? Ask them to acknowledge interest.
  • Proposal timeline
    • Submission date
    • Contract award date
• Thank the provider for time and interest
• Close the letter with contact and reference information

The project overview and administrative information should briefly cover:

• Executive summary – high level objectives
• Information about the management of the RFP
  • Where & when to submit proposal
  • If and when a bidders conference will be held
  • Relevant dates for procurement
  • Requirements for preparing proposals
  • How proposals will be evaluated
  • RFP contact names and addresses
  • Other information as needed

Since we are focusing on IT managed services there must be a technical requirements section in the RFP. The technical requirements section will probably take the most time to produce. The clearer this section the better; show your knowledge!

• Summary of the problem
  • What is the business application?
  • What is the technical environment?
• Goals and objectives for the project
  • What are your pain points & how do you expect the vendor to address them?
• Critical success factors
  • Must have / Need to have / Nice to have
• Functional specifications: both existing and projected
• Performance specifications
• Hardware/Software requirements
• Communication requirements
• Reporting requirements

Another section in the RFP will be the management requirements.

• How will the project be implemented & managed?
• Internal staffing requirements
• Site preparation responsibilities
• Delivery & installation schedule
• System acceptance test requirements
• System maintenance requirements
• System training requirements
• Documentation/reporting requirements
• Ongoing care & feeding. “Free puppies are not always free.”

It is important that you know who is trying to get your business. So, the supplier’s qualifications and references section is also important to the outsourcing process. Consider gathering details from the vendor about:

• Brief history of suppliers firm
• Installation & maintenance offerings & capabilities
• Description of the relationship between the supplier and manufacturer & how long has the relationship existed
• Evidence supplier has technical skills, staff & financial resources to perform the contract
• Number of currently installed systems
• Customer references with similar solutions provided by this supplier – get names & numbers

The supplier’s section is where the customer is asking the supplier for additional information.

• Tell me what you think I have not thought about
• What else should I know or consider?
• Pricing document template
  • Clearly formatted to enable better comparisons between vendors
  • Example spreadsheet for categories (one time vs ongoing, fixed vs variable) such as:
    • Hardware – lease, buy
    • Software – OS, App, Reporting
    • Installation – hourly, fixed cost
    • Maintenance – remember if you want annual maintenance
    • Training – onsite, offsite, electronic
    • Documentation – there may be additional charges for some documentation
    • Project management
    • Other integration fees
    • Licensing fees – annual, one-time

The contracts and license agreements section may request specific details about  the following:

• Purchase agreement
• Maintenance contract
• Warranty details
• Software license agreement
• Non-disclosure agreements

And finally, the appendixes should include materials that do not really fit into other areas of the RFP. Some of these materials might include:

• Workflow diagrams
• Statistical information spreadsheets – to support requirements
• Communication network drawings – if network involved
• List of current equipment/software – for integration
• Company standards
• Tentative project plan with dates & responsible parties – project work breakdown schedule (WBS)
• Etc.

That is a lot of information but it will be a great communication tool between you and potential suppliers. It helps your organization ensure the requirements are documented and understood at the beginning of the process.

Stay tuned – more to come!

Thanks for reading and let’s continue to be good network citizens!