This message was deleted.
# _general
s
This message was deleted.
d
The key here will be the Resultant Set of Policy (RSOP) for the user/computer context. Quite often I'll see this when filtering or permissions are in place for policies and they need the script to run in both scenarios (HORRIBLE design, btw, but I see it a lot). You can just run an RSOP model and determine what will run, but no it will not run twice if it's the same policy result (logon scripts).
j
log your script and you will know.
s
Thanks for the replies. @jvitech I can't add logging to the script because it would stop running due to AppLocker. Also, I cannot log onto the RDSH server and do anything as they are FULLY Locked down. RSoP might be my best chance. which is running now, I did try a GPResult, but that errored out with "The user <username> does not have RSoP data". so, that was not helpful. Oh, and when I run the RSoP, it will not let me specify the user that I am interested in, It only presents about 15 users and none of them are what I'm interested in
d
Yeah, just their OU or group typically
You may need to check permissions on the OU itself
s
but, Interestingly enough, @DJ Eshelman Both entries for that script show up in the RSoP for the user I pulled.
which I leaves me still wondering if they will both run. And, the filtering and scopes are identical.
its a head scratcher (at least for me.)
d
If it were easy... lol ADGPO is a pile of snakes sometimes, and rarely documented well.
I highly doubt the script would run twice, as it's just not how RSOP works at logon. The message about failing to find RSOP is concerning, of course. When it comes to this, I think of Plinko (I credit Nick Rintalin for putting this into my head). I wrote about it in Be a Citrix Hero as well - but think of each peg as a decision point as the puck goes down to the bottom. The very first peg is Context (OUs), then Permissions (groups, etc), then Filtering... etc, etc.. When I'm faced with challenges like this I ALWAYS start at that beginning and work myself downward in the same way RSOP does this at every logon. Hope that helps calm the storm a bit...
s
Thanks, (and Nick is awesome). Unfortunately, we have such a large RDSH farm that is so locked down and I have such little control over anything, and at the end of the day, if our Login VSI accounts are seeing some errors is a low priority. I wish I had that Login Process Diagram that Brian Madden put together 15 years ago, but updated for today. 🙂
d
LOL. I was just talking to Martynowicz this morning and we were talking about how security teams need to start waking up to how much being in the way is costing. The chickens are likely coming home to roost soon, and this is one of many areas that will be under scrutiny in the coming years... But until then, yeah. Blind lockdowns and draconian measures sometimes are a thing.
s
In my day to day, I am usually swearing under my breath about having to jump through hoops to get things done, But, considering how much these guys have actually accomplished just learning on their own, I'm usually more amazed and totally understand how/why we are here. For instance, we're the 4th largest RDS farm in the world (pure RDS, no Citrix or Horizon). The company has just discovered RemoteApp (published apps) and RDGateway (Netscaler/Universal Gateway) and are implementing it. BUT, with the limitations that RemoteApp has (it is broke-ass), they are writing code to get around it. It's almost like they are re-writing Citrix. We're also working with a app vendor whose writing practice is abysmal and the things this company has come up with is pretty amazing, if a bit convoluted. for instance we have written our own redirector for registry and are using a sophisticated folder redirection process. Things you and I would probably not do, but they got it to work and it works fairly well. Two aphorisms: • There's more than one way to skin a cat. • Design for purpose, not 'best practice'
d
interestingly, I just put on the schedule a workshop on automation where we will be covering bits of that topic... like when to just use the industry tool and stop trying to re-invent the wheel to appear you're saving money (spoiler alert, you very rarely are). https://courses.thrive-it.com/live-webinar/i-t-automation-testing-is-for-smart-people-not-lazy-people/register