It's the jewel in the crown from the end-user perspective - strategically it has been central to MS continued success since they've lost much of the cash-cow benefit of the Office suite. Our team at the time seemed to be quite happy with, once we had a consistent environment to deploy into and sufficient investment to bring everything else up to scratch.
I was the IT director for unified comms and networking at the time, amongst other things. I also programme managed the delivery and managed the EA with MS which prevailed at the time. I'm not sure why you think it's relevant.
My employer is not Fujitsu. I have no idea why you think it would be.
I don't know why you think I have no desire to find out. My original post was about the service status being poorly managed, not a cry for help in diagnosis. I have found out - it's probably a failing amp in the cabinet, which has been affecting the whole road.
What are you, 12? What an offensive child you are.
A Virgin chap came out last week and diagnosed it. As to how Service Status could know - it needs do no more than relate multiple reports of an outage to the same infrastructure component to recognise an issue and report awareness of it, whether they have diagnosed it or not. It would save users a lot of time and hassle and stop all the L1 diagnostic stuff when they phone the helpdesk. It's fundamentally the ITIL principles for incident response enabled by a CMDB.
What reports? 99% of the on the ground kit is "dumb"
How will an amp know it is failing? How will it report that to the service status back end? Why do you think they need to send an engineer to diagnose it?
VM aren't in the business of saving consumers time, any more than any other ISP. Active monitoring of all network components simply isn't a thing. My mate a few door up had an internet outage, we went to diagnose it and found the cable from the pole to the house lying in the garden. What did BT's ITIL framework do? - same as VM's. Nothing. Even in the total absence of a physical network connection, they couldn't "see" it until it was phoned in by the consumer. We've seen cabinets upended by cars and no one comes until its manually reported.
Its a cheap as chips residential service. If you want uptime guarantees and SLA's, get yourself a leased line. If access is mission critical, get yourself a failover. Old habits die hard eh? You want the top of the range at pocket money prices. As you seem to like your acronyms, here is one for you. TANSTAAFL
As a Very Insightful Person, I'm here to share my knowledge. I don't work for Virgin Media.
Just because you have absolutely no clue about how to manage infrastructure services, there's no need to keep driving it back to your comfort zone of widgets and string. This has nothing to do with monitoring and diagnosis, a point I've been making since the start of the thread and which you wilfully ignore, because you're a spod who would rather try and lord it over others with your knowledge of widgets and string. They're irrelevant to everything I have been saying: I have never asked for technical assistance with the problem and I could give a crap about the widgets and string.
It is in Virgin's interests to do this as well as it can because it maintains their competitive position and minimise their support costs. The cost of the residential service has nothing to do with it. It is cheaper to adopt well-established procedures in order to identify component failure as early as possible, rather than waste manhours dealing with individual support requests and diagnosis in glorious isolation. If a car drives through a cabinet, it is far better that V identify the issue immediately, rather than deal with a flood of calls that eventually leads to understanding. If the best they can do is to relate support calls, that's far better than waiting until someone tells them about the accident.
I only used these acronyms because I assumed you had some vague knowledge of this stuff. I'm not that surprised to find you haven't - you just know about widgets and string.
What [or in this case who] informs the service status?
If there is potential for drops caused by maintenance work, you need to tell your customers. If there are unexplained drops, you need to tell your customers you're aware and keep them informed. I have had enough of days totally disrupted by service failures, with absolutely no-one able to tell me what is going on and when I can expect to be able to rely on consistent service delivery again. Leaving your customers totally in the dark is beyond unacceptable.
Round these parts external works are clearly identified via roadsigns or on barriers erected by those carrying out said works.
This thread reminds me of Basil Fawlty for some reason. You should also note that even if you are a hot shot IT director, on here you're just another VM customer (like the rest of us) nor are you in a position to demand 100% uptime 24/7.
If you do it really well, no-one informs the service status, the CMDB drives the updates eg you get (threshold level) of calls to support which are logged against individual customers... the CMDB recongises the common cabinet and updates the service status for customers connected to the cabinet - because it knows who they are - to say 'We are aware of (and investigating) a problem in your area'. Automated call-handling announces same message to customers who call the support desk. All not only entirely possible, but exactly what happens in the real world in many infrastructure orgs today. Immediately removes unnecessary call handling and tells customers that V are aware of the problem.
Identifying works via roadsigns achieves virtually nothing and will likely not cut a single support call or leave customers any less frustrated.
I'm not a 'hotshot IT director' and have made no claim as such. I haven't demanded 100% uptime or even alluded to it - but it's more fun for you to claim that I have I guess. I've simply questioned the poor quality of the service management around V's provision, which gives a poorer customer experience than necessary and will, in the long run, cost V far more than doing it well - both in immediate operational cost and in competitive position.