kmount

Yes very much so. - - - Updated - - - Yes very much so.

Good call on the link there @psydii

I'd just clean it / rebuild the machine. Plenty of mention of this particular infection on the internet suggesting it's legit so worth cleaning up and moving on.

No worries, good luck, will be interested in the outcome!

Hang on, that makes some sense. If the hosts are taking time from a VM that is running on one of them that could explain some of the jumping around if the real time clock (rtc) on the hosts themselves is off. Look in the BIOS on the vmware hosts and see what they're on, they will boot with that time (and then change / sync to the configured one).

If the hypervisor time is jumping too, is it pointing to something else for time? (and that it may be is the one jumping). As twin--turbo said, even without NTP you should have a fixed time source internally so your stuff is in sync with each other, not necessarily the rest of the world but for most things that is fine. Would be useful to know what the hypervisors are doing for their time configuration, it could be the root of the problem. Also worth checking timezone configured on your server builds just incase, that can account for 'big hour' jumps.

Is your domain controller virtual or physical? I've seen instances where if the host time (VMware hypervisor) is wrong then the guests pick up from this which helps to explain big jumps. If the domain controller is the physical server it's likely not relevant.

Well worth being aware that starting in u51 that the lack of a jar manifest permission attribute 'blocks' running of the applet instead of just warning as it did on u45. A lot of java applications will break as a result of this, contact your vendors for updated applications that have this attribute in place. The alternatives I'm aware of at the moment are you could use deployment rule sets to whitelist applets, or in dire emergency turning off java security (but we wouldn't want to do that of course!).

Good luck fella! What doesn't kill us makes us stronger, good learning experience too. You'll get through this and be stronger for it.

Phew, yikes I'd get yourself a new DC up on the other host per ChrisH advice so you can at least have something you have control of. I don't know a lot about DPM sorry, but if I was you, I'd fish out a copy of Veeam Free Edition from Veeam: Modern Data Protection too ( Veeam Backup Free Edition : Free Backup For Hyper-V | Veeam Software Official Blog ) so you can get backup your 'new' DC to give you some comfort! If the service is hung on 'stopping' you might find something like procmon may help show you what's happening or at least try and point you in the direction if a process is hung that needs to be killed to let your stuck process go. Sometimes though, a reboot is unavoidable

Are the hosts joined to the domain that the virtual domain controllers manage? If so that could cause you some chicken and egg problems for sure though if they are standalone workgroup members it should be less frightening. If RDP is enabled you should be able to connect to the host from your PC assuming you can log onto it without the domain being around (make sure you know the local admin password if it is domain joined just incase!) I don't know as much about 2008R2 Hyper-V but certainly on 2012 it's quite flexible when it comes to host failure so there's always a way forward and having it on shared storage helps here too. Backups will be crucial here just incase it does go wrong though. Inclined to agree with ChrisH though that another DC on the working host would be sensible if for nothing more than to protect you from shenanigans with no DCs should the problematic host have issues getting the DCs back up.

Sorry, I didn't see your message. OEL 6.4 was released in Feb https://oss.oracle.com/pipermail/el-errata/2013-February/003307.html If they won't budge, what other distributions do they support? I'd be surprised if they didn't support RHEL 6.4 or CentOS 6.4 which OEL is pretty much identical to (bar a different kernel if you're using UEK).

Yeah, that's what I'd do, shut them down cleanly and spin the host. If they are on shared storage even if the host doesn't come back you can at least fire them up on the other host. If on local storage, check your backups work first.

What backup solution are they using? OEL is a Red Hat clone, 6.4 was out back in Feb so not that new (6.5 just released days ago). Veeam etc all support is just fine.

Perhaps How to Change a File Association With Group Policy | Chron.com will help.

Folks on here might find it useful to know that the new patch2 (called R2 now) for Veeam B&R v7 has been released. This adds vSphere 5.5, Hyper-V 2012 R2, and vCloud Director 5.5 support. Fixes etc at KB1831: Veeam Backup & Replication 7.0 R2 update This will install on top of a B&R v7.0 or v7.0 patch1 installation and tends to be straight forward.

I thought that was for vCenter on 2012 R2. (per VMware KB: Installing vCenter Server 5.1 Update 1/5.5 on a Windows Server 2012 R2 system fails after displaying the message: Installing Directory Service)

The link didn't copy/paste well. It was actually for "Guest OS": VMware Compatibility Guide: System Search - Select Guest OS "What are you looking for" - Select Server 2012 in the OS Family name drop down - Click View/Update results - Click Server 2012 R2 in the list of results I suspect they're using the data from 2012 without R2 due to the date of support commencement but the HCL does say supported so ...

VMware Compatibility Guide: Guest/Host Search seems to say it is supported. I'd suppose like in the early days of 2008 R2 you'd need to just select 2012 in the drop down.

Where in the country are you?

Add more beer!

Hi MrWu, If you nailed an infected PC it may well be worth requesting a delisting (I did this with my customer to make sure it was a 'current' infection too) and once it clears keep an eye on it daily though you do want to make sure you have your ISP/filtering ready to provide you logs when needed. If your ISP look after your firewall it would be worth asking them if all of your outbound internet traffic is sharing one IP or whether your exchange could possibly be moved off onto its own (or more likely, everything else moved and leave exchange on it to save reconfigurations!) Enjoy your beer, sounds like you've had a hell of a week and a good break is due. Cheers, Kim

Had this with a customer recently who had a couple of infected PCs. Firstly, you have the best clue at your disposal: Get onto your filtering and see who has accessed that domain and that'll tell you who is infected. (recently managed to nail this in a few minutes using a LightSpeed Rocket report, though I'm sure Smoothwall et all will be just as easy) Do not request removal until you are confident you are clean as per the warning at the bottom, they'll stop listening to you if it keeps happening. Also, you really should have your exchange using it's own outbound IP to stop this happening if a PC(s) is infected it shouldn't stuff your email service.

Hi Nick, It's most definitely a problem with VMware if you can't even take a snapshot from the vSphere client. Are you using any RDMs? VMware KB: Creating a snapshot for a virtual machine fails with the error: File is larger than maximum file size supported VMware KB: Storage vMotion or cloning a virtual machine fails with the error: File is larger than the maximum size supported by datastore What type of datastore are you using? NFS or VMFS? (& how big is it?)

Which version of Veeam? Which version of vCenter & ESXi? The servers you are backing up, do they have any other snapshots? Can you create snapshots yourself on this particular server? (to see whether Veeam is a victim)