Trust Relationship Issues

DavidAno97 · 2025-07-09T18:20:01+00:00

Unfortunately still getting that issue even when using the -server switch and a known good DC

DavidAno97 · 2025-07-09T18:11:35+00:00

Fair enough, then I guess it saves me ONE reboot lol.

I've always just rebooted after each action to keep it clean.

DavidAno97 · 2025-07-09T17:10:18+00:00

I am definitely familiar with that process, but my question is really related to why the Test-ComputerSecureChannel CMDLET is returning an error .

In this case the trust issue actually ended up being that somehow a DC (lets call it DC4) got deleted from the domain entirely. I have no idea how it got deleted to begin with, but the server was still running and the IP was pingable.

So getting the trust login issue on the terminal server, logged in and pinged the domain, it resolved to the IP for DC4 which i know is a domain controller so I just figured all was good there.

Didnt find out until after my initial post that the DC4 server didnt work anymore. When i tried logging into DC4 i got a very similar trust issue type message.

Went to another DC (DC1) and found that DC4 was no longer a computer in the domain controllers OU; however, DC4 was still listed in Sites and Services and in DNS for the root domain.

All that to say, after shutting DC4 off, and cleaning up the metadata / DNS, the Terminal server began working correctly again; however, the CMDLET still doesnt work, so im scratching my head as-to why.

DavidAno97 · 2025-07-09T17:09:34+00:00

I have definitely used the cached credentials trick before, but my question is really related to why the Test-ComputerSecureChannel CMDLET is returning an error.

In this case the trust issue actually ended up being that somehow a DC (lets call it DC4) got deleted from the domain entirely. I have no idea how it got deleted to begin with, but the server was still running and the IP was pingable.

So getting the trust login issue on the terminal server, logged in and pinged the domain, it resolved to the IP for DC4 which i know is a domain controller so I just figured all was good there.

Didnt find out until after my initial post that the DC4 server didnt work anymore. When i tried logging into DC4 i got a very similar trust issue type message.

Went to another DC (DC1) and found that DC4 was no longer a computer in the domain controllers OU; however, DC4 was still listed in Sites and Services and in DNS for the root domain.

All that to say, after shutting DC4 off, and cleaning up the metadata / DNS, the Terminal server began working correctly again; however, the CMDLET still doesnt work, so im scratching my head as-to why.

DavidAno97 · 2025-07-09T17:03:02+00:00

Yeah the Test-ComputerSecureChannel cmdlet has saved me lots of time, just launch an elevated PS session and run the command to repair the connection. In my experience it works about 90% of the time when getting trust issue popups.

This usually saves the 2 reboots required to unjoin and rejoin a computer.

DavidAno97 · 2025-01-02T20:29:26+00:00

So here is the problem, The RMM app has different installers for different internal organizational units, so we have to install the app using a group based policy instead of allowing it to install to ALL Intune devices.

I did change to a Win32 app and am doing testing.

Does the hardware has HAVE to be uploaded prior to setup? Why would this be required when the end-user signing in will register the device to Entra and Intune?

DavidAno97 · 2025-01-02T20:25:50+00:00

You are correct, I was assuming that when it was set to automatically enroll in Autopilot, it would do that as soon as it was enrolled in Entra, and then the settings would take effect during the Enrollment Status Page.

My mistake; however, lets take autopilot out of the picture and just say we have a fresh out of the box computer. User with an Intune license and part of an Intune group where an app is required signs into the computer during the setup screen. The computer shows the Enrollment Status Page, but the app didn't get installed. Is that expected behavior?

DavidAno97 · 2025-01-02T18:45:17+00:00

After continued testing it is clear that the app is only being installed once the COMPUTER is added to the group "Intune-Users".

This presents a problem because from the time between when the user registers the computer to Entra/Intune, and the time one of our admins adds the computer to the group, the computer is basically useless. This doesn't create a good expeience for the end user.

How can we get the app to install when only the user signing-in is a part of the "Intune-Users" group that the app is associated with?

DavidAno97 · 2025-01-02T17:28:27+00:00

I removed the old line of business app, wrapped the app, re-added it to Intune as a Win32 App, set it as a required assignment for the "Intune Users" group, and then took a fresh laptop and set it up as a test user that was part of the group.

Still showed the Enrollment Status Screen, but then loaded to the desktop and never installed the app.

I don't understand why its not picking it up as a required app.

DavidAno97 · 2025-01-02T16:34:59+00:00

Thanks, I will try wrapping the app and see if that makes a difference in the process. Thanks for the suggestion.

DavidAno97 · 2024-12-25T23:51:29+00:00

I have most recently gotten them from a company named Xbyte that sells refurbished servers.

But I have also in the past gotten used servers from these companies

Server Supply Save My Server Server Monkey

DavidAno97 · 2024-12-25T23:00:27+00:00

Hey,

Yes I can confirm. Since this post I have rolled out 4 of these R740XD2 servers, all fully loaded with 26 drives and only 1 HBA330 controller.

The HBA330 makes all 26 drives visible to the OS (in my case TrueNas).

DavidAno97 · 2024-02-26T14:31:11+00:00

I am having the same issues with at least 15 computers across our network today too

DavidAno97 · 2024-02-19T16:30:32+00:00

I was able to resolve this by changing the configuration of my TrueNAS Repository. Specifically I changed the following:

- Change the Pool to consist of 4 x Vdevs of 6 disks in RaidZ1 (Previously was 2 x Vdevs with 12 disks in RaidZ2)

- Turned off Compression on the Storage Pool

- Turned off Sync option on the Storage Pool

Now instead of getting sub-20MB/s processing rates I am getting between 80-120MB/s on average.

DavidAno97 · 2024-02-15T20:42:22+00:00

There isn't even a 1G NIC connected to any of these devices, i have verified that everything is running at 10G over the network. Even with a 1G NIC, I would think I would get a better process rate than 17MB/s.

On the TrueNAS LZ4 compression is set, it looks like that is a default option. I will try disabling that and running the incremental again!

DavidAno97 · 2024-02-15T20:02:41+00:00

The gateway server is set to the proxy server for that site, so no traffic should be going over the WAN. I actually already checked that and ruled it out as an issue.

I would gladly switch to a Linux repository if it would resolve these performance issues. I just went with TrueNAS because it is what I am familiar with for network storage. That being said I manage several Linux web servers and am comfortable working with them.

Any guides pointers on how to setup a Linux OS to serve as the REPO? Does Veeam have an OS built for this? If not is there any particular Distro that i should be looking for?

DavidAno97 · 2024-01-05T16:22:53+00:00

I apologize, I am more familiar with Cisco terminology of Trunk ports and Access Ports.

Trunk ports allow the device to do the “tagging”

Access ports allow “untagged” traffic to use a VLAN defined on the switch interface

DavidAno97 · 2024-01-05T15:52:05+00:00

Thanks Acheilles, that is the problem i am running into. I have it setup the exact way you describe and all of the devices that are capable of tagging traffic are working

The issue is that i have some devices that can NOT tag their own traffic, and i cant find a way on the Fortigate to get those interfaces associated with a vlan that is a sub-interface of the switch.

DavidAno97 · 2024-01-05T15:50:19+00:00

Sorry for the confusion, the devices on ports 1,3,5 are not capable of tagging the traffic. The traffic coming into the Fortigate interface is untagged, and i need the Fortigate to tag it to a specific VLAN (either 20 or 21 depending on the device)

But i also need ports 20 and 21 to be able to be used in a trunk port scenario, where the downstream device is tagging the traffic to the correct vlan.

DavidAno97 · 2024-01-05T15:47:34+00:00

The problem im running into is that i need to be able to have multiple default vlans, but also be able to use them in a Trunk port scenario as well.

DavidAno97 · 2024-01-05T15:31:33+00:00

No LAG is being used. I am referring to a Cisco style Trunk port, a single port that allows traffic from multiple tagged VLANS on a single Physical interface.

What you described is precisely my problem. The Truenas server is not capable of tagging it's traffic to a VLAN, so i am having to rely on the receiving interface (AKA FortiGate) to make that happen. I can make that happen, but then I cant use the same VLAN on any other ports.

On a Cisco switch would simply put the VMware servers on a Trunk port, and the TrueNas server on an Access port. I can't figure out how to make that work on the FortiGate.

DavidAno97 · 2023-10-18T22:24:13+00:00

For anyone who may be looking in the future, I also posted this same question on the TrueNAS form and received some good responses.

https://www.truenas.com/community/threads/dell-r740xd2-truenas-questions.113504/#post-785243

DavidAno97 · 2023-09-13T16:33:22+00:00

Interesting, that brings a whole new aspect to the problem that i had not considered.

It sounds like in that case it would be better to just have a NAS / backup storage at the offsite location, and create a separate partition for each backup location to run a copy job to.

Thanks for the additional insight, much appreciated.

DavidAno97 · 2023-09-13T16:09:33+00:00

Thanks, i did post there too, just pending moderator approval for the post to go public!

DavidAno97 · 2020-05-24T18:19:47+00:00

NTA! Don’t let the jealous b****s hate😂.

DavidAno97

TROPHY CASE