|
IT Guy posted:Our site servers are Windows XP boxes Username/avatar/custom title/post of the year.
|
#
?
Apr 16, 2010 16:48
|
|
|
|
| # ? Apr 25, 2024 09:46 |
|
|
IT Guy posted:Our site servers are Windows XP boxes So you don't have servers at the branch locations? Anyway, to try to answer without questioning why you're hosting files off a Windows XP computer, I would look to your AD structure. For customers with multiple sites, my company sets up AD one of two ways: 1 -domain.local --Main OU ---HQ ----Computers ----Global Groups ----Groups ----Users ---Site 1 ----Computers ----Groups ----Users ---Site 2 ----Computers ----Groups ----Users 2 -domain.local --Main OU ---Computers ----Site 1 ----Site 2 ----Site 3 ---Groups ----Site 1 ----Site 2 ----Site 3 ---Users ----Site 1 ----Site 2 ----Site 3 ----Parent Company Code (for users who work between multiple locations) With either structure, you could create separate GPOs for the computers at each site. So for Site 1, create a policy that installs OfficeScan from \\serv1\publishedapps\officescan.msi , then apply the policy to domain.local\Main OU\Site 1\Computers or domain.local\Main OU\Computers\Site 1 . Then for Site 2, create another policy, and so on. Bonus tip: Define a naming scheme for your GPOs. The format I like is "Computer/User - Site - Description (OS if computer policy)". For example, for the GPO to install OfficeScan at Site 1, I would name it "Computer - Site 1 - OfficeScan App Deploy (XP)" . I can see doing this with 1 GPO if you had DFS in place (or maybe even BranchCache). Without servers at each site, I think this would be your best bet.
|
|
#
?
Apr 17, 2010 06:13
|
|
|
Ridge posted:So you don't have servers at the branch locations? Want to hear something even better? A few of the branches have over 10 people trying to connect to the XP Edit: Also, to add to ^^^ that. I dream every day that if only we had a multi domain forest with cached global catalogs at each branch, maybe the users would stop calling me everyday complaining about boot times and slow performance. Our Domain structure looks like this and I hate it, but it's been like this since before I started: -domain.com  --Computers ---Site1 ----Sales ----Management ----Other Departments ---Site2 ----Sales ----Management ----Other Departments ---Site3 ----Sales ----Management ----Other Departments --Users ---Site1 ----Sales ----Management ----Other Departments ---Site2 ----Sales ----Management ----Other Departments ---Site3 ----Sales ----Management ----Other Departments --Groups --Global --Distribution The first directory structure you listed is exactly how I would propose a change if I knew they would accept a change. Also, I was trying to avoid making multiple policies in hopes I could make one that just linked to a mapped drive and the computers would look at their respective mapped drives and be linked to their own IT Guy fucked around with this message at 19:03 on Apr 18, 2010 |
|
#
?
Apr 18, 2010 03:59
|
|
|
Do I have to do anything special to get my .PAC file working for Windows 7 clients? We have an SBS 2003 server, and all the clients are XP except for the 2 new laptops we just bought, which are Windows 7 Pro. Basically I have GPO that loads a .PAC from a networked drive and also disables access to the connections page in IE. It works fine for the XP clients, but the two new Windows 7 computers don't seem to load that GPO. You can change your proxy settings (and it doesn't load the PAC file) edit: We have another policy that forces the screen saver to activate after 5 minutes and lock the workstation, and that one seems to work fine. Bob Morales fucked around with this message at 14:14 on Apr 28, 2010 |
|
#
?
Apr 28, 2010 14:06
|
|
|
IT Guy posted:
I've still never really seen a convincing argument for not doing this. It's probably not the best idea, but things seem to work fine with the internal and internet domains of an org matching.
|
|
#
?
Apr 30, 2010 19:28
|
|
|
sanchez posted:I've still never really seen a convincing argument for not doing this. It's probably not the best idea, but things seem to work fine with the internal and internet domains of an org matching. It's not anything you should lose too much sleep over, no. However, if you're in a position to make that decision early-on, do you a) make the choice with potential problems later on b) make the choice with no potential problems later on There's just no good reason to NOT use .local or whatever. That's really the argument.
|
|
#
?
May 10, 2010 15:56
|
|
|
Mierdaan posted:It's not anything you should lose too much sleep over, no. However, if you're in a position to make that decision early-on, do you It's annoying with Direct Access and the NRPT (name resolution policy table). You need entries for each entity with your FQDN that has to be accessible to DA clients on public IPs.
|
|
#
?
May 10, 2010 23:03
|
|
|
da sponge posted:It's annoying with Direct Access and the NRPT (name resolution policy table). You need entries for each entity with your FQDN that has to be accessible to DA clients on public IPs. *15 minutes of technet reading later* Oh, yeah, I could see that being a problem.
|
|
#
?
May 11, 2010 16:03
|
|
|
This isn't a group policy question, but it's a stupid question that doesn't really fit anywhere else: can I remove a domain user from domain\users? I have a new user that doesn't need (and shouldn't have) access to anything other than one application on one server. This is the first time we've had a user that needs to be this restricted. All shares on all of the servers were set up before I started and domain\users has at least read access (in many cases modify) to 95% of everything on the network. The simple solution is to pull him out of domain\users. I guess I could just try it, but maybe there's a problem that I wouldn't notice at first. Is there a better/easier way to handle this?
|
|
#
?
May 14, 2010 17:13
|
|
|
Erwin posted:Is there a better/easier way to handle this? Set his account "Log On To..." to only login to his workstation (and the server, if necessary)?
|
|
#
?
May 14, 2010 17:25
|
|
|
sanchez posted:I've still never really seen a convincing argument for not doing this. It's probably not the best idea, but things seem to work fine with the internal and internet domains of an org matching. Mierdaan posted:It's not anything you should lose too much sleep over, no. However, if you're in a position to make that decision early-on, do you Everything I've read is there can be some DNS issues. We use the corp.domain.com model and it works just fine for us. Internal stuff is dc1.corp.domain.com and external stuff is just normal domain.com Erwin posted:This isn't a group policy question, but it's a stupid question that doesn't really fit anywhere else: can I remove a domain user from domain\users? Without getting a bigger picture of your needs, can you get away with just creating a local account on the resource for him? This would depend on a whole lot of things, specifically the application, etc, but a server01\user login would limit his access instead of domain\user If he needs a domain account you should be able to pull him from domain users and add him as a domain guest. It'll still let him authenticate, but he'll have very limited privileges via the guest user account by default. I would test this out before doing it though
|
|
#
?
May 14, 2010 17:41
|
|
|
El_Ergo posted:Set his account "Log On To..." to only login to his workstation (and the server, if necessary)? I think this would still give him access to network shares from that machine, no? Basically he is a contractor that will be using his personal computer at home to connect to a RemoteApp through our Terminal Services Gateway. The problem is, he can click file->open in the app and browse around the network. A local account on the application server may work, but the TSG server is a separate server, so he'd need two local accounts. That may actually be the way to go... I'll try the domain guests thing as well.
|
|
#
?
May 14, 2010 17:57
|
|
|
Erwin posted:I think this would still give him access to network shares from that machine, no? Couldn't you just drop him into a "Contractors" group and Deny Full Control on each file share for that group? You could script it out if you're talking about a lot of shares.
|
|
#
?
May 14, 2010 18:13
|
|
|
Erwin posted:This isn't a group policy question, but it's a stupid question that doesn't really fit anywhere else: can I remove a domain user from domain\users? There needs to be a default primary security group, but it does not need to be a member of Domain Users. So long as you grant user (or admin, whatever) rights to the one system that person will have access to, they will be isolated to there. They would still have access to anything defined through the Authenticated Users or Everyone group, so watch out for that.
|
|
#
?
May 14, 2010 18:26
|
|
|
I wound up putting him in Domain Guests as well as [app] contractors. Changing "Log on to" settings for a user disables that user from using Terminal Services Gateway for anything for no good reason, so I just limited him using TSG settings. I'll go around double-checking for "everyone" and "authenticated users" on any share permissions, but otherwise it was fairly simple. Also, RemoteApp and Terminal Services Gateway/Remote Desktop Gateway is awesome.
|
|
#
?
May 14, 2010 21:20
|
|
|
Been having lots of fun with Group Policy and ADMs (2003 servers still). Just a quick question, as I'm attempting to make a policy for enabling SEHOP in some organizations; is there a way, through ADMs, to automatically have them only apply on systems that can use it (a.k.a. Vista SP1 or higher), some form of IF OS_VER>=6001.xxx whatever. If it isn't, does that SEHOP key do anything to XP machines? I support a few mixed environments.
|
|
#
?
May 26, 2010 23:23
|
|
|
univbee posted:Been having lots of fun with Group Policy and ADMs (2003 servers still). Just a quick question, as I'm attempting to make a policy for enabling SEHOP in some organizations; is there a way, through ADMs, to automatically have them only apply on systems that can use it (a.k.a. Vista SP1 or higher), some form of IF OS_VER>=6001.xxx whatever. If it isn't, does that SEHOP key do anything to XP machines? I support a few mixed environments. What you want is a WMI filter that detects for OS build greater than 6. In this case: code:
|
|
#
?
May 26, 2010 23:40
|
|
|
I just want to say that I am goddamned tired of being labeled as desktop administrator without having access to Group Policy to effectively make changes and implement better things.
|
|
#
?
May 27, 2010 00:04
|
|
|
BangersInMyKnickers posted:WMI filter Holy crap, that's handy. Is there a master list somewhere of the different things you can look for? I'm just finding random examples in my online search. I'm mainly interested in checking for existence of specific files/folders and registry keys, if such a query exists. I have a serious Ninite automation plan...
|
|
#
?
May 27, 2010 00:15
|
|
|
loving bookmarked, this thread is a goldmine of info, thanks a lot dude
|
|
#
?
May 27, 2010 00:23
|
|
|
univbee posted:Holy crap, that's handy. Is there a master list somewhere of the different things you can look for? I'm just finding random examples in my online search. I'm mainly interested in checking for existence of specific files/folders and registry keys, if such a query exists. I have a serious Ninite automation plan... I'm not exactly sure about scanning the filesystem (I'm guessing the Hey Scripting Guy! stuff at Microsoft would be useful), but this PowerShell WMI Explorer is really handy for cruising around the WMI namespace and finding useful things to put detection clauses on http://www.powershellpro.com/wmi-explorer/160/
|
|
#
?
May 27, 2010 13:37
|
|
|
Is there a way to control which printers are visible to users in which OU on the same terminal server? Including the ones for which there are local drivers on the Terminal Server box? ie. Users in OU A can only see these printers, and users in OU B can only see these printers from their TS session. Even though a poo poo load of printers are using that TS box as a print server? Edit: Basically the Server running Terminal Services is on one location and the users who run terminal services are in 4 locations so we don't want those users to contend with the huge list of printers in the main location as well as every printer in every other location. CISADMIN PRIVILEGE fucked around with this message at 20:30 on Jun 11, 2010 |
|
#
?
Jun 11, 2010 20:26
|
|
|
I've been tasked with redoing our group policies at my company. I started by breaking up each department for things like printers, and drive mappings. I then went to muck around 2500+ options to make a new policy for the entire domain, WUS and the like. I ran into an issue that when I implemented the new policy it effectively broke all database connections. For the most part it was simple enough to fix, rebooted the servers (my boss wouldn't let me enforce the policy while we had the servers down to begin with), however, there were a few boxes that just died. Our encoders are proprietary hardware and the SID's turned to 0's, breaking the entire system. Is this normal and if I go to make further changes is there a way to avoid this? Also, we have 10 departments, so I have individual policies for each of those and then one for every day behavior. Is there a better way of making this happen? What special things besides WUS, security policies, etc, can I leverage to make our environment smooth like butter?
|
|
#
?
Jun 11, 2010 20:44
|
|
|
bob arctor posted:Is there a way to control which printers are visible to users in which OU on the same terminal server? Including the ones for which there are local drivers on the Terminal Server box? Are these locally installed printers or network printers we're talking about?
|
|
#
?
Jun 11, 2010 21:11
|
|
|
Tooter posted:I've been tasked with redoing our group policies at my company. I started by breaking up each department for things like printers, and drive mappings. I then went to muck around 2500+ options to make a new policy for the entire domain, WUS and the like. I ran into an issue that when I implemented the new policy it effectively broke all database connections. For the most part it was simple enough to fix, rebooted the servers (my boss wouldn't let me enforce the policy while we had the servers down to begin with), however, there were a few boxes that just died. You really shouldn't ever dick around with the default domain policy too often. I personally don't like creating one giant rear end GPO, for reasons you just mentioned, when poo poo goes down it's hard to pinpoint. I find it easier to make specific GPO's for one or two common settings and apply them selectively to needed OU's rather than creating a new blanket policy for the entire domain.
|
|
#
?
Jun 11, 2010 21:24
|
|
|
BangersInMyKnickers posted:Are these locally installed printers or network printers we're talking about? The printers are networked, but the users who use TS are not members of the same domain as the TS on their home networks. The printers of issue have drivers locally installed on the terminal services box it's beginning to look like that might be the issue.
|
|
#
?
Jun 11, 2010 21:27
|
|
|
No, I mean are the printers attached to the print server and the users add the print to the profile and use that, or is there just a giant mass of locally installed printers that do raw IP mappings without a print server in the middle?
|
|
#
?
Jun 12, 2010 00:00
|
|
|
skipdogg posted:You really shouldn't ever dick around with the default domain policy too often. That's the way I was going originally but my boss wanted it the other way. I do what he wants to stay employed, told him what would happen but he thought I was wrong. Then everything broke. I'm slowly going through now and applying specific things to our groups, waiting for our servers to break again.
|
|
#
?
Jun 12, 2010 01:09
|
|
|
bob arctor posted:The printers are networked, but the users who use TS are not members of the same domain as the TS on their home networks. The printers of issue have drivers locally installed on the terminal services box it's beginning to look like that might be the issue. If the printers actually have their queues on a printer server somewheres else other than the terminal server, your users should only see printers to which they have attached themselves. Shared printers on other machines are actually part of a user's profile so they are specific to that user. If you set up the printers as direct IP printers as the administrator though, its as if the printer is a locally installed device and every user who hits that terminal server is going to see those printers and there is nothing you can do about it.
|
|
#
?
Jun 12, 2010 14:09
|
|
|
Ok, here's a silly question. We have these computers that shop employees use on a regular basis for punching in and out of a program that tracks their efficiency on jobs and whatnot. They're base XP machines, and pretty much need to be locked down as much as possible, otherwise they get abused. I've already done stuff like removing Internet Explorer shortcuts, etc, but they have still figured out ways to gently caress with me. They change the themes of the computers and set pictures of their kids as the wallpaper and gently caress with the screensaver. Setting Bliss.bmp is no problem, nor is changing the screensaver back to logon.scr, but the thing that has stumped me is this: How do you change the color scheme back to the normal Luna Blue? I've probably got 15 different color schemes set across the entire company, and it just looks like garbage. Some are set so it looks similar to this:  When in reality, I want them ALL to look like this:  (neither image is my own, blatantly stolen off of Google Image Search. Thanks Nick Perla, whoever you are) So, I ask of thee, how would one accomplish forcing color schemes on an XP Pro machine using Group Policy?
|
|
#
?
Jun 15, 2010 19:49
|
|
|
Phuzion posted:Ok, here's a silly question. User Configuration\Policies\Admin Templates\Control Panel\Personalization "Prevent changing theme" and some other related policies in that folder.
|
|
#
?
Jun 15, 2010 19:54
|
|
|
Syano posted:If the printers actually have their queues on a printer server somewheres else other than the terminal server, your users should only see printers to which they have attached themselves. Shared printers on other machines are actually part of a user's profile so they are specific to that user. If you set up the printers as direct IP printers as the administrator though, its as if the printer is a locally installed device and every user who hits that terminal server is going to see those printers and there is nothing you can do about it. We figured it out. The TS administrator installed every possible printer on the terminal server so not only could we see the ones directly installed on the terminal server, but also every printer in every other office. Since all the drivers have been yanked users only see the printers which they have installed on their machines.
|
|
#
?
Jun 15, 2010 20:50
|
|
|
BangersInMyKnickers posted:User Configuration\Policies\Admin Templates\Control Panel\Personalization "Prevent changing theme" and some other related policies in that folder. Bummer, I don't have that, looks like I'll be doing some work in the Windows 7 box sitting downstairs tomorrow. I'll let you know whether it works or not. Without that, it looks like my only option is to either nuke the user registry settings, and prevent it from happening again with group policy, or import parts of a known-good registry hive.
|
|
#
?
Jun 15, 2010 21:08
|
|
|
I'm just popping in to see what the general consensus is on the Windows 7 Aero theme. Do you guys disable it through GPOs and send that bitch back to the classic theme or do you let the user have the Aero theme and the new task bar? I'm currently modifying GPOs and a good part of me wants to let the user have the Windows 7 Aero theme because it is just that much better but then I think about how god loving awful my users are at computers and that maybe I should just give them something they are used to. What do you all think or do currently?
|
|
#
?
Jun 30, 2010 18:45
|
|
|
I let people have the Aero interface because it is pretty and makes people less scared of the upgrade, not to mention that the desktop acceleration is nice when it comes to overall responsiveness.
|
|
#
?
Jun 30, 2010 19:00
|
|
|
There is a real good reason to not use .local - mDNS/DNS-SD/ZeroConf/Bonjour. .local plays havoc with that stuff.
|
|
#
?
Jul 1, 2010 00:37
|
|
|
Running Win7 with the classic interface just seems counterproductive to me, but to each his own. I suppose some users are more amenable to interface changes than others, I guess it depends on personality types, etc. You'd be surprised how much the "Ohhh, pretty!" aspect of it can help ease people into it, though. To contribute, we've run Aero since rolling out Vista. Most users prefer it, although some do still insist on the classic Start Menu. And others refuse to search for anything, even though it's a super powerful part of the OS now. Also it just seems to run better/smoother on modern hardware. Graphics acceleration and whatnot. The Office 2007/2010 interface was much more of a dramatic change, IMO. But people got used to it anyway. We'll be pushing out 2010 pretty soon.
|
|
#
?
Jul 1, 2010 04:39
|
|
|
Trying to get Windows 7 UAC squared away through group policy. I have the following settings set: Admin Approval Mode for the Built-in Administrator account: Enabled Allow UIAccess applications to prompt for elevation without using the secure desktop: Enabled Behavior of the elevation prompt for administrators in Admin Approval Mode: Prompt for consent on the secure desktop Behavior of the elevation prompt for standard users: Prompt for credentials on the secure desktop Detect application installations and prompt for elevation: Enabled Only elevate executables that are signed and validated: Disabled Only elevate UIAccess applications that are installed in secure locations: Enabled Run all administrators in Admin Approval Mode: Enabled Switch to the secure desktop when prompting for elevation: Enabled Virtualize file and registry write failures to per-user locations: Enabled - I wish this could be enabled/disabled per-application, not just for everything Since there's no "set the UAC slider all the way up" setting, I set the most secure settings I could while allowing me to also work on stuff remotely. I can't find any "best practices" lists on these settings, so did I miss anything? P.S. It really annoys me when some GP settings are "Allow this: enable/disable" and some are "Don't allow this: enable/disable"
|
|
#
?
Jul 2, 2010 13:47
|
|
|
Erwin posted:Trying to get Windows 7 UAC squared away through group policy. I have the following settings set: Yeah, being able to control that slider is one that that drives me insane. It doesn't appear in the registry because I've watched the UserAccountControlSetting.exe as I change the setting and I don't see any noticeable registry or config file writes. My solution so far has been to manually set it to full prompt mode and remove the UAC control panel applet through policy, but that is more of a hack than I prefer. I can't even figure out where that setting is defined in the Technet documentation. gently caress you, Microsoft.
|
|
#
?
Jul 2, 2010 14:15
|
|
|
|
| # ? Apr 25, 2024 09:46 |
|
|
I have a question about best practice when it comes to deploying upgraded applications through Group Policy. One of my clients has a web-app that for whatever reason breaks in IE, so they're forced to use Firefox. I use the .MSI deployable FireFox distribution from FrontMotion (https://www.frontmotion.com) which makes my life a thousand times easier. Now the MSIs are smart enough to upgrade each other so what I've been doing up until now is just adding each successive version to the same policy, but since I started doing this I haven't had to image any PCs so I don't know if it will install the lowest version, then the next and the next and so on until it's up to date, or whether GP is smart enough to only install the latest version right off the bat. Can someone tell me whether I should be removing each previous version as I add new ones, if I should leave one older version to allow for a "smooth" upgrade (e.g. PCs with the version that is to be upgraded still existing don't wonder where it went in GP), or if I should just leave them all in the GP. I have enough disk space so I'm not too worried about that aspect, I just want to know if I'm doing it *right* or not.
|
|
#
?
Jul 2, 2010 16:11
|
|
