Dotdotdooda

Can anyone recommend a company (in the UK) that supports Splicecom? We've been using a company called IntraLAN and they've just hit us with a 48% increase with a forced 1 year contract. No warning!!! Not the kind of people we want to do business with. Happy to move everything to a new support company. We are all internal and it essentiall runs itself without problems. Splicecom is a great system.... pity about the greedy support company shareholders!

Hello Gurus I have an excessive number of useless templates created by innumerable Data Managers over several years, who all had their own idea of how templates should be created. I need to mark most of these (nearly 4000) templates as inactive to hide them from view. Is there any way of setting a bulk batch of templates as inactive? Your help would be appreciated.

Well done! This solved it for us.

It's not that I think I should or I shouldn't include the Linux VMs in the M$ licensing. Every license calculator (and even some of the comments on this very post) avoid drawing attention to the Linux 'fly in the ointment'. They refer to OSEs. Operating System Environments. They do not state that this does or doesn't need to be M$ OS. The ambiguity of the OSE factor is what I am questioning. Is Linux not an OSE? If it is, are M$ counting ALL OSEs as licensable entities? As Oaktech alluded to, this ambiguity may be entirely intentional to force excessive licensing. If there is documentation that specifically states that only M$ VMs need to be included, that's what I need pointing to (big neon light pointy thing would be best). Without this specific guidance, I cannot calculate whether Data Centre licensing is the most cost effective method.

I am truly baffled by the ever changing M$ licensing terms. Just about every year it changes so that the cost of licensing increases without any actual change to what the servers\processors are doing or what the software is doing. It's equivalent to charging per bag for rice, then charging by weight.... then charging by grain. This is how you increase your income with least effort. Don't change the product to be better... change the licensing model!!! My latest puzzle involves a VMWare\Linux\Microsoft combo dish that is just giving me indigestion. I'm hoping that there are some xenolinguists amongst you that understand the language of M$ licensing. Picture two servers, dual processors, 8 cores per processor (total 32 cores). The servers run VMware and host 14 machines (10 Windows Server and 4 Linux). I have read countless creative accounts of licensing for processors, cores, servers and VMs. However, I am confused as to where the Linux machines running on a VMWare platform come into the licensing. None of the information I have waded through suggests that you don't need to include the Linux VMs in the equation. This implies that, although neither the VMWare or the Linux OS installed are M$ products, you still have to include them in the OSE count and license the cores used to run the non M$ VMs. Am I missing something or are M$ now charging us to run other people's OS if they are within 20 feet of their immaculate conceptions? Any thoughts? If not, make something up.... that appears to be the way most people are interpreting the M$ licensing.

Well, I know this is a very old thread, but for anyone new to or contemplating RM CC4 (and up), read and consider carefully. I have worked in several schools with the RM 'overlay'. Yes, it makes some management task easier and possibly helps schools with no regular IT support to manage some complex tasks. However, from a technician\management point of view, this 'overlay' can be a nightmare, as well as the 'support' that comes with a maintenance agreement. For any given problem you encounter with the system, reporting the issue usually (and I emphasise 'usually') results in as response that includes 'self fix' tech articles. These tech articles invariably point to other tech articles, making the fix process laborious and frustrating. The RMMC, which is intended to make your job easier, tends to be the root of most of your support calls as the system fails to do what it says on the box. An example of this being the build process for new machines. The Trend AV (sold to us by RM) has been a constant source of failure for the last two years. Despite continuous tech articles (sometimes, the same article sent by different support member) and remote support, this regularly stops working we cannot build the machines without building them in a different location them moving them in the console to add the AV after the process. Least of all the frustrations is that the build process has to get to the very end, sometimes over an hour later, before it fails and the machine is unusable. Software rollout can sit waiting for machines to become visible, even though they show as being online on the RMMC. Group policies fail to become active unless the PCs are restarted several times (not just the two advised by RM). Processes can sit in the 'In Progress' Task area and most of the time can't be stopped until the timeout (four days!!!). There are so many quirks in the system and very little flexibility to do anything outside the system. New feature releases from M$ tend to create the most chaos and add disturbance. The latest release (as of writing) could not be tested under the RM test area as it failed to rollout, so we have been left to manually test and rollout the release. Any system that requires this dual approach should raise questions as to why do we need the overlay in the first place? In previous schools, I removed the RM overlay and everything became 'The Microsoft way', which was far simpler. However, for anyone who is no experience with Server OS, AD, GP, WDS, WSUS and all things MS, RM CC4 may still be the way to go. There will be people who love the CC4 overlay and there will be others that need far more flexibility and control over their network. There are undoubtedly other very good management overlay tools, but if you are a technician\manager of a network and you can keep up with M$, it's probably far better to stay the course and do it the M$ way. This is all personal experience and view, so it's only for consideration, not advisement.