Again, thanks @SYNACK - I'm going to try and work out exactly what you mention; not sure how, would appreciate a nudge in the right direction. Our Core switch is a HP Procurve 5406zl.
Hey hey hey some of us need our snow tyres. My car had 18" rims with Goodyear Eagle F1 GSD3 rubber on them, very very nice in the summer, fine on wet motorways and nice and quiet actually am very impressed with them and they have done nearly 31K and still got wear in them (for the cost per corner I'd hope so when it comes to replacing them!!).
However, as the reviews here - Goodyear Eagle F1 GSD3 | the Goodyear Eagle F1 GSD3 reviewed and rated | the online tyre guide say, I can 110% agree snow and slush = a very expensive sled!
I've just got some 16" rims and some nice proper winter tyres, now feeling very poor and have no space at all in the garage as its got a stack of 18" rims lol, however the new rims and rubber should work well with it and the off-road should be good on the car as VW have some very good reviews and I found out that the system on my car is the same as on the Freelander 2 which does well off-road.
Now I am sure @ZeroHour would need even better snow tyres than me but we had it bad last year, I live a mile off the main road and don't get ploughed or gritted for 3 days of below 0 and snow fall so we have to get about for 3 days and a normal car on general purpose road tyres just doesn't work so I am hoping that this does work
But I do agree that too many people have gone OMG and bought silly things that they will never need or use in winter
You could use a single NAT stage at the interface to the LA network and have all the internal stuff behind it. A decent layer 3 switch (possibly with the advanced firmware option - depending on vendor) could let you run one to one NAT so outside you have the LA subnet lets say 172.16.1.1 to 172.16.2.254 then inside have your network split into chunks that add up to at avalible range from the LA. This way you do not need to use NAT overloading (all on one IP and stacked by messing with port numbers).
This way the LA does not see anything different and can't throw fits but you still get to use propper routing and subnets inside despite the primative conditions imposed by the upstream network.
You do need to use different subnets for each VLAN otherwise it breaks tcp/ip routing to the point that it does not work.
Thanks @SYNACK - The problem is the we're on a particular scope from SWGfL, so can't route from one subnet to this subnet through their gateway, that's why we need to use NAT. I think I got that right anyway!
You want routing rather than NAT unless you have two seporate chunks using the same ip addresses and need to use double NAT and routing. Using seporate ip ranges and routing should be much simpler.
I have a fantastic diagram on how VLAN's work if you would like to see!
There is an update to this article in progress - as I now use NTLM as the users logon to the Thin PC as their own user, it still triggers the RDP, but then autologs in to the RDP.
It was just a standard limited account. Group policy locked out to prevent anything other than a "Cancel" box showing from a CTRL - ALT - DEL.
Using Shelly to replace the shell to use the script calling an RDP file (yes with the domain prefix included - as highlighted by other comments), prevents any access to the account itself. It has no desktop, user home folder, or even profile. All it is is a network access account, to allow calling of the RDP with the GPO for "ignore certificates" set.
Hi Pal, what restrictions did you place on the network account ?
Incidentally we get the user problem that edugeekdan outlined on our older CE4.0 terminals, not found a solution yet.
This isn't a comment. If I was commenting, I would be expressing how funny I found this.
Beautiful, thank you very much! I'll give that a shot with my thin-client machine hopefully today.
Originally Posted by simpsonj Do you have a link to the Shelly utility? Try this... @simpsonj www.insidetheregistry.com/content/authors/user177/file/shelly.zip
A co-worker of mine has previously added other staff here on FB (without worrying whether she can trust them or not) and one of them decided post comments and have a go at her.
Myself, I only add those I trust. Yes, the point about the BTRD is valid but if your a member of your SMT has to spend time looking for such places, then it makes you wonder why they're not doing their job.
Just out of interest this is a USER policy so placed in the student or staff OU.
How do you deal with different locations? e.g. In the library students need a different start menu to the ICT Suite.
Currently with have loopback processing enabled and a GP in the COMPUTER OU for that group?
Is there a better way? GPP ?
If you run the following command Code: Add-PSSnapin Quest.ActiveRoles.ADManagement -ErrorAction SilentlyContinue in a standard shell, you can then run the above Quest cmdlets
Add-PSSnapin Quest.ActiveRoles.ADManagement -ErrorAction SilentlyContinue
I'm going to ask probably what is a really stupid question, but I'm trying to improve our setup again (after several modifictions of other bit's you've posted).
I notice in the Top Screenshot you have 3 User Policy Settings, management, staff and Students.
What is the security filtering on the policies to make the changes to the different user groups? Does just removing all users and adding the Server and the relevent user group do that filtering?
(and not really relevent to this but might as well ask here - what difference does having the Run is User's secuirty context have? I've never ticked that on any of my printer deployments yet....)
Do you have a link to the Shelly utility? Looks like InsideTheRegistry has had an update, and I can't find the program as all links point to a dead page.
@Browolf - the latency you mention is the hazard of using a network path for the redirect. I actually use a local path - with some scripts that keep this up to date. I will do an updated copy of this post with the changes I actually use...
Interestingly, Apple's employees are trying to organise a union entirely for themselves.