u/2012BKIT

Can't recall, but I found a post online related to it. I have had zero issues with FSLogix and profiles since implemented. Around 140 daily users.

POI

That would be a hard, not my job. Our company had an operations manager who used to do that thing all the time, until our manager finally said, our IT team are highly skilled individuals who don't do office maintenance work. The person didn't ask for anything again going forward. I think the average office worker thinks anything that plugs-in...call IT!

For firmware, bios etc. - DELL System Update, v.2.0.2.3 https://www.dell.com/support/home/en-ca/product-support/product/system-update/drivers

install, then from CMD run

dsu /u

I found if you have a UNC path in the AD account under Profile/Home Folder local path, it slows everything way down logon wise. If I remove the entry, no issues with RDS logon.

I think I had this issue when I setup up a new RDS environment last month. I had to enable or add the following to the FSLogix GP settings

Flip Flop Profile Directory Name - Enabled

Sid Directory Name Match - Enabled

Sid Directory Name Match = %username%_SID

Yes, this solution works well. You can setup escalations, schedules for your team etc. It's not cheap though. Once you get the API key from them, you can setup a state trigger called iLert or whatever and if the monitor goes down, you get a call/text/email immediately. They have a mobile app for managing the alerts, rerouting them to other people on the team and marking them as resolved.

https://www.ilert.com/integrations/prtg-network-monitor

Outstanding! Thank you! I got it to work. I was hoping to use it by pointing to a HV failover cluster IP and monitoring that way for redundancy and avoid issues when server is offline or VM fails over to another host. Seems to only work with individual HV servers though. Which is still a solid solution.

There are two types of managers: Those who manage what they do not understand, and those who understand what they do not manage.

Lost opportunity to use E-literate

My co-worker had this issue after applying the Windows 11 update. https://winaero.com/microsoft-has-confirmed-the-bug-with-udp-in-rdp-on-windows-11-22h2/

I've been using it at work for about a month. 22,840 trackers blocked.

If you do a search, you'll see a lot of guys are switching to Storage Replica with DFS Namespace. DFS-R works well, but it can completely shit the bed if something happens infrastructure wise or on a config level. Used it for about 10 years and have seen it go sideways about 4 times. We're moving to SR & DFS Namespace in the next month. I'm just doing a bunch of validation tests.
This has great info on a lot of aspects - https://github.com/MicrosoftDocs/windowsserverdocs/blob/master/WindowsServerDocs/storage/storage-replica/server-to-server-storage-replication.md#replacing-dfs-replication-with-storage-replica

https://github.com/MicrosoftDocs/windowsserverdocs/tree/master/WindowsServerDocs/storage/storage-replica

We had DFS-R running for about 3 years with no issues. Then did some work on our DR "hardware rollover" when the DFS VM was brought online staging volume didn't mount properly. This was the last server in the referral order. Somehow it went postal and the two primary servers started deleting mass folders automatically on the day of month end! So you can imagine how well that went over.
Oddly the DR server had all the data intact but it was over a week old...it was a total gong show. I've setup Storage Replica from HQ to DR with DFS Namespace and it works very well. There are a few things to be aware of like only enabling DEDUP and Shadow copies on the source, and the failover has to be executed manually. I use PDQ to failover and it brings the volume online on the DR target in about 10 seconds. The way we look at it, the source server is not likely going to have issues and you don't have to worry about secondary servers going rogue and delete crap...which I've seen a few times over the years.

That's not at all correct. It's actually recommended over DFS-R. It does block level replication instead of file replication. For a file server that means your users don't get file lock issues. The replication is miles faster. I replicated 1.2 TB of data to our DR in less than 48 hours. That would take about a week using DFS-R. Storage Replica with DFS Namespace is the recommended method on new servers. There are caveats of course. DFS-R is great when it works, but I've seen it shit the bed badly when something goes sideways on it. https://github.com/MicrosoftDocs/windowsserverdocs/blob/master/WindowsServerDocs/storage/storage-replica/storage-replica-overview.md

"submitted 9 days ago by ntw2 "
You ARE the OP of the crosspost in the PRTG subreddit. This original post was not even created by you. What is the point of posting this then in r/prtg??

Honestly, the download is hit and miss, but seems to work best using sconfig, if you read through threads on technet and Reddit, you'll find peoples biggest harp is the DL AND install time.
Even using PDQ to push a CU I've seen 2016 servers take upwards of 1.5 to 2 hours to finish installing. 2019 downloads/installs are polar opposite, super fast DL and really fast installs. 2019 has it's faults like HV replication being broken since November when replicating from 2016 to 2019...you can do a MacGyver workaround, but it's ridiculous how long they've let it stay borked and have already missed the timeline for it to be pushed out.

2016 for the most part has been pretty solid. My biggest complaint about it has always been the WU issue.

....great so you both just proved you have no clue how long it takes and don't have short maintenance windows.

You must be an anomaly
https://old.reddit.com/r/sysadmin/comments/chtu1x/seriously_annoyed_with_the_time_server_2016_takes/

Really? Doing updates on 2016 is an absolute dogs breakfast. Probably the worst of any server version since NT. https://www.google.com/search?q=windows+2016+updates+slow+site:social.technet.microsoft.com&sa=X&ved=2ahUKEwjrnqzT15znAhVMRqwKHfKDDJcQrQIoAzAAegQIBhAQ&biw=1920&bih=941

This guy does really deep dives on security cams.

Just an FYI on Storage Replica replication differences.

Storage Replica supports synchronous and asynchronous replication:

Synchronous replication mirrors data within a low-latency network site with crash-consistent volumes to ensure zero data loss at the file-system level during a failure.

Asynchronous replication mirrors data across sites beyond metropolitan ranges over network links with higher latencies, but without a guarantee that both sites have identical copies of the data at the time of a failure.

Ahhh...I see.

I was trying to achieve something similar monitoring cluster shared volumes. I was wanting to monitor the CSV volume size and set a thresh hold where we'd be alerted when it exceed that thresh hold parameter we set.

In HV HA FOC the volumes get spread across the HV host servers depending on load etc. Monitoring that would be problematic if a server crashed or was in maintenance as the volumes would be dynamically migrating to different servers.

I was monitoring each host's CSV's but as I said it was not fullproof if a host went offline. The obvious then stared me in the face when I thought about it. I created a device monitor with the IP of the cluster which floats to whatever HOST is monitoring the cluster. If the managing host changes it doesn't matter as the device you register is the floating IP.

So I just created a new device with the floating IP and added the CSV sensor for each volume with thresh holds set.

If you have a floating IP, you should be able to do the exact same thing.

PRTG will determine a sensor going offline, soon as it can't ping it. It will then pause all other sensors associated with that Server. The SLAVE server will see that exact info and it will show paused on the SLAVE server. Soon as PRTG is able to PING the server, it will then resume monitoring on all other sensors on that server and will be reflected on both MASTER/SLAVE servers.

Not really getting what you are trying to achieve.

I'll give you an example and see if you're doing the same thing. Forget the physical redundancy I mentioned earlier and just think this is using PRTG built-in clustering.

We have a few 3 DFS servers. We monitor on all 3 basic things like CPU/MEM/Uptime/CPU Load/Ping. We also monitor Disk I/O on the drives that have the STAGING and actual file server data. We monitor Current Disk Queue Length. One of these servers is at a DR and gets monitored through a VPN tunnel.

The way the PRTG clustering works is the MASTER server is the server that is write mode, meaning gathering logs etc. That is where you'd change config/ add monitors etc. The SLAVE is always in READ-ONLY and is always active, so there is no need to pause anything if the MASTER server goes offline for whatever reason. As soon as the master server comes back online, it assumes it's master role. The MASTER and the SLAVE both have unique URL's that we save in our bookmarks. Everything is identical in the slave, maps etc....but they are all in R/O mode.

Is that what you are looking for?