Server won't allow iSCSI to reconnect, print to shared printers, but traffic fine from server!

I have a Server 2012r2 DC configured through Hyper-V on a Server 2012r2 host that has shared printers on it and an iSCSI target attached for backup. It is acting very strange. I have had this server in use for about 2 years now working fine.

If someone prints from the shared printer to the main Konica copier, it will go offline. Once that happens I can not ping the copiers IP address from my server, but I can still print to the Konica directly from a locally installed driver on a workstation. Other shared printers however seem to be working fine.

The same thing is happening with my iSCSI device. I can not ping the iSCSI from the server, but I can ping it from anywhere else on the network, EVEN THE HOST (which is sharing the same NIC as my VM Virtual Switch). In iSCSI Initiator it is showing in a "reconnecting" state.

But whats really weird is, I have total network connectivity if Im on the server OTHER than accessing these couple of things that are trying to interact with the server! I can browse the internet, I can access shares and ping other networking equipment.

Another issue I noticed was I had an infinite ping going to the DC while I was there working on it. All of the sudden I started dropping packets while I was doing something else (but not making a change) and then it eventually came back up, but the pings were VERY high (something like 40-130ms), then after a while it dropped back down to >1ms.

I have the firewalls disabled on both VM and host. AV removed from both as well for troubleshooting purposes.
Switches are Cisco Small Business SG200 series. I upgraded them to the newest firmware. I have enabled Spanning Tree and Loopback detection and connected them to a syslog server. I don't see anything indicating a loop in the logs.
I have changed the port the server was plugged into on the switch. Moved it to a different switch. I have also changed from one on board NIC to another on board NIC on the server.

I just can't figure out how I can access the iSCSI device from the host and not the server. Also again, I can ping the iSCSI IP address from a workstation.
Because the same issue is with both printing and iSCSI I don't believe its a reconfiguration of the devices themselves.

System Event logs are clean other than logs referencing iSCSI not being able to communicate with the target. Here are whats showing up.
Event 1, iScsiPrt. Initiator failed to connect to the target. Target IP address and TCP Port number are given in dump data.
Event 7, iScsiPrt. The initiator could not send an iSCSI PDU. Error status is given in the dump data.
Event 20, iScsiPrt. Connection to the target was lost. The initiator will attempt to retry the connection.
Event 51, disk. An error was detected on device \Device\Harddisk1\DR2 during a paging operation.
Event 157, disk. Disk 1 has been surprised removed.
Those events are referencing the disk located on the iSCSI target.

Thats all there is for errors. Application logs are clean.

The Printer issue and iScsi issue both started at the same time, so they have to be related.
LVL 1
ppincAsked:
Who is Participating?
 
ppincAuthor Commented:
Thank you for your effort on assisting me.
It turns out after spending the day deconstructing and reconstructing the network that someone had plugged a router into a drop under a desk.
After I reconfigured all of my switches I found one that brought the network down after I plugged it in, and then I left it in and one by one went through each port until I narrowed down the drop it was coming from.
0
 
Casey WeaverNetwork EngineerCommented:
Any recent patches? Microsoft had a string of security roll ups mid last year that left ISCSI, printing, S2D and User Profile Disks all randomly broken throughout the day. Took 4 months for Microsoft to finally fix the problem. They had a running article for it with the security roll up KBs.
0
 
ppincAuthor Commented:
I had removed any patches from the last 3 months as well. Didn't fix the issue. Plus that wouldn't explain why I can't ping the iSCSI target (I can ping other locations) because ICMP wouldn't be effected with the patching.
0
 
Casey WeaverNetwork EngineerCommented:
It actually would not solve the problem to roll back from those patch sets. The issues required roll backs and registry changes to limp along until the fix came out. Our symptoms were also different, a lot of people reported issues with the ISCSI issue outside of the Microsoft issued KB. For example, users on our Remote Desktop servers used user profile disks from our file server. The file server was fine, but the rdsh servers would start saying they could no longer contact the mounted profile disks. They would drop from ping and you could no longer rdp to the affected system. Hyper-V console would not let you work with the VM either, you couldn't log into the VM. You had to force reboot the VM and it would come back up, lasting from a few hours to 1.5 days before it locked up again. Issue came out in the March 2017 Preview and April 2017 rollup. It was not fixed (and is caused by every update in between) until the August 2017 rollup. https://support.microsoft.com/en-us/help/4034672 I only mention it because as part of an MSP, I've been brought into other environments that were on the older patches and still getting some of the bugs of the bad updates because they weren't installing any roll ups that were at least August and newer.
0
 
ppincAuthor Commented:
It wasn't the suggestion.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.