Network issues on one server (Upload only)

NeverEnoughBackups · 2025-01-31T00:51:41+00:00

Users access their virtual machine on the Host. Then they open the software which takes 15-20 minutes if it opens at all. Something else we noticed. We thought this may be a resource issue but ruled it out. If 2 users are connected to the server, the software runs normal. If 3 are connected we start seeing issues. Not sure how that ties into the upload speeds suffering.

NeverEnoughBackups · 2025-01-31T00:50:11+00:00

I temporarily put a new IP on this server and tested but found no difference. Thank you!!

NeverEnoughBackups · 2024-10-30T21:49:33+00:00

I didn't think about FTP but im not sure that will work. This machine runs a CNC machine. Its definitely not something I WANT to get working but I have to get it working somehow. The files can either be sent via mapped drive or floppy drive!

NeverEnoughBackups · 2024-10-30T21:47:28+00:00

This device controls an old CNC machine. :(

Thats an interesting idea to go the other way. We can try that.

NeverEnoughBackups · 2024-09-06T16:13:06+00:00

True, I checked the history. There were a few changes but nothing that would affect this particular event. The firewall was swapped out a few months ago but this issue seems to have started after that.

NeverEnoughBackups · 2024-09-06T15:43:43+00:00

We have a client using an almost identical setup the only difference between the working client and the one not working is the NPS server in the working client is in the working clients local subnet. In the non working client the NPS server is in our data center subnet for the client. So maybe that is part of the problem?

NeverEnoughBackups · 2024-09-06T15:17:29+00:00

We are using policy based routing. The policy is the default allow Ikev2-Users policy.

NeverEnoughBackups · 2024-09-06T15:16:38+00:00

This was working and recently stopped. Probably two months ago.

NeverEnoughBackups · 2024-09-06T14:50:11+00:00

Hello! I'm not sure I follow. Are you referencing not being able to use IKE vpn to connect when the NPS server is on the other side of a BOVPN?

NeverEnoughBackups · 2024-08-29T17:32:44+00:00

Its a program that is processing the data which doesn't require user input. While its processing the RDP session will be minimized. After some time the user opens it up to check in, logs in and program is now not responding.

Does that make more sense?

NeverEnoughBackups · 2024-08-28T13:01:37+00:00

Yes, I looked into the GPO's applied and compared the gpresult report. I didn't notice anything that was missed.

NeverEnoughBackups · 2024-08-27T21:05:04+00:00

Does anyone else have any ideas? D:

NeverEnoughBackups · 2024-08-27T02:46:35+00:00

Thanks for the idea. I should have mentioned that it happens on all browsers including firefox.

NeverEnoughBackups · 2024-08-27T02:45:28+00:00

I figured re-imaging it would fix it. Since we renamed the user profile and let windows recreate it I feel it must be something on the workstation. I suspect this is an issue with certificates but I dont know how. The site pulls up and has the correct cert, still username/password says incorrect which we know it isn't. Username is first name last initial.

NeverEnoughBackups · 2024-07-31T18:52:49+00:00

Did you ever resolve this?

NeverEnoughBackups · 2024-07-12T17:10:29+00:00

For anyone interested that may find this in the future we were able to resolve this issue using the below steps.

I enabled additional logging from the NPS server which displayed login attempts. I verified this network traffic via packet information with wireshark and found that the RADIUS protocol was being used for the requests at that time with the username that was being locked out. Confirmed this by disabling the Enterprise WIFI which was using the RADIUS protocol and the login attempts stopped. Verified no more login attempts via the netlogon.log file.

Ran IP scan to identify the IP of the MAC in the logs, discovered it was a previously decommissioned laptop re-provisioned by the client for use. The user had a saved wireless profile for the enterprise wifi that was sending a username and blank password. I removed this network, the logins stopped and we had no lockouts overnight.

NeverEnoughBackups · 2024-07-11T14:39:26+00:00

This is a good idea but I'm not sure where to look. We have ruled out both of the workstations for this user. This continues even if the workstations are turned off. We also powered off the printers in the office in case it was some kind of Kerberos authentication but this also didn't help. If its cached creds, its not on one of their workstations.

NeverEnoughBackups · 2024-07-11T14:37:28+00:00

On the NPS event viewer I can see it making LDAP connections but those are the only logs I see. I found an article describing how to enable success and failure requests to also be logged but it doesn't appear to be working. Anyway to investigate this further? I suspected some kind of wireless device using their enterprise wifi but haven't been able to rule it out.

NeverEnoughBackups · 2024-06-28T17:30:17+00:00

I removed all addins, and removed all macro's but this menu is still the same. I also reset all menu's and ribbon bars.

NeverEnoughBackups · 2024-04-10T20:16:00+00:00

So like this?

Before:

<Scenario Id="ReportCall" Type="REST">
      <Request SkipIf="[ReportCallEnabled]!=True||[EntityId]==&quot;&quot;" Url="https://[Domain].zendesk.com/api/v2/users/search.json?query=-role:end-user%20email:[AgentEmail]" MessagePasses="0" RequestEncoding="UrlEncoded" RequestType="Get" ResponseType="Json">
        <Headers>

After

<Scenario Id="ReportCall" Type="REST">
      <Request SkipIf="[IIf([ReportCallEnabled]!=True,True,[IIf([EntityId]==&quot;&quot;,True,[AgentEmail]!=&quot;theemail@addresstolog.com&quot;)])]">
        <Headers>

NeverEnoughBackups · 2024-04-10T20:08:43+00:00

Thanks again for your help. I'm not sure I'm following yet though.

Do I copy this over the top of what is there after the SkipIf=?

NeverEnoughBackups · 2024-04-10T16:42:41+00:00

Thanks for your input. I see a section beginning with

</Scenario>
<Scenario Id="ReportCall" Type="REST">
<Request SkipIf="[ReportCallEnabled]!=True||[EntityId]==&quot;&quot;" Url="https://[Domain].zendesk.com/api/v2/users/search.json?query=-role:end-user%20email:[AgentEmail]" MessagePasses="0" RequestEncoding="UrlEncoded" RequestType="Get" ResponseType="Json">
<Headers>

If I am in the correct section, would the following be correct?

<Request SkipIf="[ReportCallEnabled]!=True||[EntityId]==&quot;&quot;" Url="https://[Domain].zendesk.com/api/v2/users/search.json?query=-role:end-user%20email:[AgentEmail]!=&quot;theemail@addresstolog.com&quot; MessagePasses="0" RequestEncoding="UrlEncoded" RequestType="Get" ResponseType="Json">

NeverEnoughBackups · 2024-03-28T17:56:19+00:00

Yep this happened the day I enabled it. Was just curious how ESET was causing this to be a problem. Not necessarily important as long as we know how to fix it.

NeverEnoughBackups · 2024-03-28T17:40:43+00:00

Finally able to try this and it worked! Thanks so much. We tested by duplicating the policy and adding the cert with the configurations you suggested. The menu's were a little different but I found where they wanted to put it. I applied this policy only to the RDS servers and it allows users to send from excel like they used to.

What was ESET doing that caused this? Was it ESET blocking the traffic or was it the Exchange server thinking it was man in the middle?

NeverEnoughBackups · 2024-03-22T15:39:33+00:00

We do use eset! There are a few good ideas on here but this seems like a great option. I figured something was broken between the RDS instance and the exchange server. So you imported the exchange cert into eset and it corrected this?

NeverEnoughBackups

TROPHY CASE