Tony Toews's questions

I am getting the error "Port {GUID} was prevented from using MAC address xxx because it is pinned to port {GUID}" Source VMSMP, event ID 28 in the event log. And frequent network slowdowns. This is in a simple HyperV 2008 Server R2 environment with three guest OSs. The event log is showing these happening multiple times per day and sometimes within minutes of each other.

As per some suggestions I have assigned static MAC addresses to each of the three guest OSs. I have recreated the virtual switch. Some of the items in the event log mention SWITCHPORT but I think those were from before I recreated the virtual switch.

There are two NICs in the server.

The first of these events started 2014-09-29 but they only happened every few days back then. I'm suspecting some kind of patch in 2014-09.

Added later: There is only the one virtual switch. There are two RealTek PCIe GBE Family Controller NICs according to Device Manager. Not sure of the exact model. There are no other HyperV servers on the LAN.

Added later: The server is part of a small network. It's possible that the warnings started when I installed two TP-Link AC1750 Archer C7 dual band wireless access points in bridging mode. However there is a GB switch between the server and the one WAP. And I wouldn't think a wonky switch or WAP would cause this kind of problem.

I have two 9 GB SCSI hard drives in my very low volume web server. (We need to put some larger ones in soon but they're good enough for now.) Since the day we setup this server, back in 2003, the hard have noticably clicked. The clicking has been randomish every few seconds other than when installing software, copying files or similar activity where you'd expect a lot of hard drive acivity. I always thought this was because of all the random activity of being hit every few seconds from the Internet. And the logging of web pages hit, etc.

However for 16 hours it was down because of misconfiguration by the ISP and the hard drives still clicked. Is this normal behaviour?

One is a Seagate ST39102LW and the other a Quantum Atlas IV 9 WLS. I installed the Seagate tools and both failed the short drive test. But I wonder if those hard drives are so old the tool doesn't deal with them properly?

The IDE hard drive we installed as a backup/archive hard drive happily passed the Seagate short DST

This question is a follow up to Why do some admins dislike exes being executed from a server share? I have developed a utility which makes life much easier for Access developers. One option I will be making available, due to the feedback in the afore mentioned link, is making an MSI file available for install on the client systems by the IT department.

One option I was thinking about was to give the developers the ability to copy the exe from the server share to the users Application Data folder. Another possibility is an exe/msi which the user could execute which would also place the exe in the users Application Data folder.

Comments?

I notice that Google has installed Chrome, Google Talk and a whole bunch of update exes and dlls in the App Data folder. As well as a few other programs. Not that I'm trying to use that as an excuse.

Added

I've had comments from developers stating that they only need my utility on a small subset of the systems in use. IT departments will spend months and months evaluating things and don't want to deal with such programs unless they are part of the corporate imaging systems. Also the developers may want to push out updates of my utility a lot quicker than the IT dept will deal with it.

I distribute a utility for developers which is designed to reside on a server share and is executed from the server on the local PC or Terminal Services/Citrix session. It does not require any admin privileges. There is no install process other than dragging and dropping it on a server share. It is digitally signed.

I'm told some IT depatrtments don't like having exes on the server share in this fashion. What can I do to help explain to IT departments that my utility is benign.

Added

I'm the developer of the tool, Auto FE Updater, and it's deliberately designed to not require admin priviliges. It's a stand alone exe with no installation dependencies other than a few config (INI) files created by the developer using the tool.

This tool is executed by the users for brief moments of time while it checks to see if there are any updates to the Access front end database and associated files on the server. The developer using the tool might run it for two or five minutes while updating settings.