Wes Sayeed's questions

I have a GPO with printers mapped via the user preferences. Each printer needs to be item-level targeted only to computers in a specific IP range. I have a list of about 92 ranges that need to be added to a dozen or so printers.

The only way I know of to add an IP range is to do it through the GUI by clicking New Item -> IP address range, then type each of the start and end addresses of the range, then hit Item Options -> OR (default is AND), then hit OK... 1 range at a time... for 12 printers.

There's no way in hell I'm doing this by hand!

Is there a way to script this? Or at least add ranges in a batch?

When implementing Folder Redirection via Group Policy, there is a checkbox on the Settings tab that says "Also apply redirection policy to Windows 2000, Windows 2000 Server, Windows XP, and Windows Server 2003 operating systems."

When I Google this checkbox, all I find are how-to articles on folder redirection in general, support articles saying one bad thing or another is happening because it is or isn't checked, or forums full of advice from people clearly have no idea what they're doing.

I know how folder redirection works. I also know how to read. What I want to know is, what does this setting actually do from a technical standpoint?

We do not have any XP or Server 2003 machines in our environment, so this checkbox is irrelevant to me. But today I found a rogue group policy that is screwing up permissions on a file server, and it's because it had the "Grant the user exclusive rights..." checkbox enabled. I need to disable it, but that policy also has this option set, and I want to know how/if this will affect the terminal server it's being applied to.

I have an SCCM OS deployment task sequence that works just fine -- with one caveat that I can't seem to figure out...

Once the task sequence completes, it takes anywhere from 4-16 hours to process its client settings. This means that freshly-imaged computers do not get any of their deployments or AV settings during that time. The SCCM client will eventually sync up with the server and when it does, everything works normally after that. But because of this issue, we basically have to let computers sit overnight before we can deliver them to users. Reimaging a wonky computer out in the field isn't an option unless we do it right before the user goes home for the day, so that it will be ready for them when they get in to work the next morning.

One particular issue is the Endpoint Protection client. On Windows 10 there is no way (that I know of) to put Windows Defender into managed mode since it's a built-in component of the operating system. We absolutely have to wait for the SCCM client to do its thing in order for that to process exclusions correctly (which are required for a particular application we use).

Here are the relevant details:

• We're using SCCM 1710
• This happens on all our images, in both Windows 7 and Windows 10.
• No amount of manually triggering client actions in the Config Manager control panel makes it apply policy any faster.
• Rebooting the computer in question makes no difference.
• Everything works normally after the client finally syncs up. Deployments, software updates, and policy evaluations are all processed on schedule after that.
• SCCM management console shows the client as installed and active.
• Our SCCM hierarchy only has one site server with the DB, DP, MP, and SUP roles all running on it. All the boundary groups are configured correctly.
• AD system and user discovery happens every 24 hours, with delta discovery enabled at 5 minutes.
• No maintenance windows are defined on any of our collections (we are mostly a 24/7 operation). All deployments are set to ignore maintenance windows anyway.
• Logs don't have errors or anything unusual in them (although I'll admit I'm not really sure what I am looking for there).

Is there any way to force the client to download and apply policy during the imaging process?

UPDATE:

I have traced this issue down to the discovery process on the server side.

When looking at an affected machine in the SCCM console, it shows that the client is installed, active, and healthy BUT Resource Explorer shows no data for it. SCCM does not know anything about the device -- what OS is installed, what hardware it has, what software is installed, what OU it's in... nothing.

All our collections are based on queries, so until data becomes available to query on, SCCM has no idea what collection it should be in, and therefore nothing gets advertised to it. The client should be populating this data to the server during its discovery cycle, but for some reason it isn't.

IF I go forcing AD system rediscovery, forcing collection member reevaluation, and manually triggering site actions on the client, THEN I can get SCCM to behave within an hour or so. But I'm really just mashing buttons randomly at this point. I don't know what combination of timing and ordering of actions is the magic sauce here.

• AD system discovery is set to run every day with delta discovery set to 5 minutes.
• Collection evaluations are set to run every 7 days, with delta discovery also enabled at 5 minutes.

But none of that makes sense because it doesn't take a full 24 hours to populate. If I image a machine up first thing in the morning, it will usually be ready by late afternoon, but discovery doesn't run until the middle of the night.

Also:

• If I re-image an existing machine with the SAME OS, I've had success with getting the computer to evaluate correctly after an hour or so by simply triggering the site actions on the client. But this is because DB already had a record for those computers, and none of the information about them changed.

So does that updated information help anyone?

We have many kiosk-style computers that automatically log into Windows with a generic domain account and launch an application that is meant to be a "kiosk jail" that users cannot break out of. This system works very well most of the time.

The problem I'm having is that occasionally (maybe 1 in 10 boots), the generic account will fail to automatically log on to the network, and the user sees a normal Windows sign-in screen. The correct solution to this is simply reboot the kiosk again and it'll be fine. Some staff, however, are typing in their own credentials at the login screen, and then they get a fully interactive Windows session, which is not what I want.

I can restrict logon through Group Policy so that only the Kiosk account (and Administrators) can sign in locally. This works fine, except that the kiosk application itself has certain "elevated" tasks that it can do which require the user's network password to use. Setting this group policy also blocks these features from working (the app basically does a "Run As..." with the user's credentials).

Is there a way to configure Windows so that it will not accept their credentials at the main login screen, but will accept them at other Windows security prompts?

I'm running SCCM 1702, and I've always wondered how I can automatically clean up the SCCM database of computers that have been decommissioned.

I've looked at the "Delete Aged Discovery Data" job in the site maintenance tasks, but I'm unclear exactly what it does.

Here's what I want:
We have an official PC decommissioning process and our Active Directory database is pretty clean. When we remove a computer account from AD, I also want that account to be removed from the SCCM database within a reasonable amount of time (I'd prefer within 24 hours, but 7 days is also acceptable).

Here's what I don't want:
We have a lot of laptops that don't get seen by the network for sometimes months on end. However, these machines are still active, still in AD, and should still be in the SCCM database. I don't want those with an inactive status getting removed.

The documentation on this particular job in the Site Maintenance tasks is as clear as mud. Computers that are in AD will still be picked up by system discovery, but they might not have a heartbeat for a long period of time.

Will this job accomplish what I want? If not, is there another method to achieve this?

I am installing a rather complex piece of software using a task sequence in SCCM 1607 (aka SCCM 2016). Within the task sequence, I have a try/catch block so I can restore the computer to a working state if the TS fails.

Like so:

The problem here is that when there is an actual failure within the task sequence, the error handling routine does its job and the task sequence exits gracefully. I'm capturing my own logs within the sequence to reflect the error, but as far as SCCM is concerned, the installation was a success. The user does not receive any kind of notification and the application shows in Software Center as installed even though though it isn't. I have to look at my own logs to get any kind of reporting on the errors, and SCCM will never retry the installation on its own.

How can I force the task sequence to fail as the last step in my error handling block? I want the user to see an error and call the help desk. I also want to be able to see the failure in the SCCM console, and I want to have the TS retry on its own (the old version fails to uninstall if it's in use and almost all of the failures I've seen in testing are because the user logged in and launched it before the TS had a chance to remove it).

I recently used the Adobe Customization Wizard to create a custom transforms (.mst) file for the latest version of Acrobat Reader DC and deployed it to our network. Today I discovered that the customizations are blocking Sharepoint documents on our own intranet from opening. It was a single checkbox I had clicked by mistake. I have corrected the error and updated the distribution points.

The problem I have is that Windows Installer doesn't let you apply an .mst file after-the-fact. You have to do a complete uninstall/reinstall of the application to apply a different set of transforms. SCCM has no option to do this. If I update or create a new application, SCCM will just detect that it's already been installed and won't apply the fix since it's the same version of the same application.

The only thing I can think of at this point is to "tag" each computer with a .txt file or something and use that as part of the detection method. But of course then I have to use a script to do the uninstall/reinstall and tag the machine and that'll take all day.

Is there a simpler solution?

I'm using SCCM 1607, BTW. The workstations are a blend of 32- and 64-bit Win7 and Win10 computers.

I have an OU structure for computers that looks like this:

Workstations
  |--  Building
  |    |--  Floor, Department, or Approximate Location
...

I want to create a child OU called "3 North" in that building's OU, but I am getting the following error:

Windows cannot create the object 3 North because:
An attempt was made to add an object to the directory with a name that is already in use.

First of all, the OU name shouldn't matter; you can have multiple containers with the same name in AD as long they appear in different parts of the tree, but secondly, the only other "3 North" that exists is an email distribution list in an entirely different container.

Why is this error happening, and how can I get around it?

We have a 6-server TS farm running Server 2008 R2 and using a WSUS server to do updates. Group Policy for the farm has updates configured to automatically download and install as soon as they're approved, but automatic reboots are disabled. The operation is 24x7 and the servers are on a rolling drain/reboot schedule of their own. The desired behavior is that updates install and sit pending the next scheduled reboot. Users are not supposed to see any notifications whatsoever.

I approved a new batch of updates yesterday, and this morning users are calling the help desk reporting seeing this on their screens:

The Restart button is grayed out (thank god!), but I don't know if this is new behavior or if users have just never reported it before. I double-checked Group Policy to verify I have the "Allow non-administrative users to receive update notifications" set to disabled, and it is:

I also ran a gpresult on the servers themselves, and they are receiving and (allegedly) applying the policy:

What can I do to stop this notification from appearing to users? It nags them to perform an action that they do not have the ability to do, and it's generating help desk calls. It's also annoying them because in the best-case scenario, they could be seeing this popup every 4 hours for up to a week.

Consider the following scenario:

• I have previously deployed the application Foo v1.0 to all of my workstations.
• A new version of Foo 2.0 comes out and I need to upgrade everybody.

In this scenario, I have to create a new application package for Foo 2.0 and deploy that.

Assuming the installer takes care of an upgade vs. a new install on its own, what is the advantage of making Foo 2.0 supersede Foo 1.0, rather than just ignoring that feature and deleting the deployment for Foo 1.0?

What benefit does this get me?

I'm using SCCM 2012 R2 if that makes a difference.

Our network admin recently enabled HTTPS inspection on our firewall/router. For IE users this is fine because the certs have all been distributed via Active Directory for domain-joined machines. However, we have a number of Firefox users that are now throwing certificate errors on practically every HTTPS site.

Firefox uses their own CA store, and they're real proud of it too. Is there any way to get Firefox to trust the system certificate store by default? I see a lot of posts on how to do this in Linux, but nothing for Windows.

I suspect from this post that it's not possible, but that post is almost 4 years old.

I am working with a non-profit organization that just had a pallet of computers donated to them. The computers have had their hard drives wiped so there is no operating system installed. They are a small agency and they do not have an IT department, so I have volunteered to set them all up. Since the new computers will be replacing their existing equipment, my plan is to pre-stage them in my lab and then transfer the activation keys over once I deploy them (this is perfectly legal by the way).

All of the old computers have Windows 7 Pro installed on them. The problem is that they do not know how they acquired their licenses. Windows 7 Pro has both a retail channel (which only accepts retail keys) and a volume license channel (which only accepts KMS/MAK keys). I have access to the install media for both, but if I stage these computers with the wrong one, I will be in for a rude awakening when I go to transfer the licenses over and the keys don't work

Is there a way to tell what kind of key was used to activate a Windows 7 license?

NOTE: This is not a question about proper licensing or product licensing in general. It is a technical issue related to product activation.

We have a lot of thin clients running Windows Embedded Standard 7 and an SCCM 2012 R2 server to manage them. The thin clients have their write filters enabled (FBWF) so machine changes are not persistent. On the rare occasion we have to update something on them, we just deploy it via SCCM and it automatically takes care of turning the write filters off and back on to commit changes.

Here's what should happen:
SCCM client gives notice to the user and a 30-minute countdown to save their work and get off the system. The thin client then reboots and disables the write filter. The log-on screen displays a padlock and notice that the unit is being serviced, and will not allow normal (non-admin) users to log on while SCCM is doing it's thing. When SCCM is done, it re-enables the write filter, reboots, and then users can log in again.

The problem I'm having is that we use proximity card readers to log into the system. Employees do not type passwords. They just tap their badge. This system is nice, but the software that runs it breaks the write filter automation with Windows Embedded.

Here's what actually happens:
SCCM client gives the usual 15-minute notice before rebooting with the write filter off. When it reboots, the normal login screen is displayed. Users can log into the system and use it while SCCM is installing software. And because a user session is active, it again gives another 30-minute notice before rebooting with the write filter back on.

In this scenario, not only does it add an extra 30 minutes to the deployment time, but it also gives ordinary users a solid 30-60 minutes of unprotected time on the thin clients with whatever changes they make becoming permanently baked into the image when the write filter gets turned back on.

The issue stems from the fact that Windows Embedded 7 uses a different credential provider (a.k.a GINA) than regular Windows 7 does, but the SSO product must replace the Windows credential provider in order to function. I've contacted the vendor about it, but they just say it's a known issue and there is no fix or workaround for it.

So here's my question:
How can I simulate the desired behavior another way? I know that there is a group policy setting where you can deny local logon to specific user groups. I was thinking I could flip the corresponding registry setting before and after the install, but I am open to other ideas.

I'm not above scripting installs if I have to. I am fluent with scripting, PowerShell, VBScript, etc. I just wonder if anyone has any bright ideas on how to solve this.

Update:
I neglected to mention that these devices are being used in a hospital environment for staff to chart on their patients. They must be available 24 hours a day, so we can't restrict logon hours or configure maintenance windows. We manage downtime by giving advance notice to shift supervisors, but anything that takes more than an hour becomes a legal compliance issue and requires official downtime procedures to be put into effect.

I have set up a Windows Server 2008 R2 terminal server for the sole purpose of running a web-based application that has utterly ridiculous system requirements (IE7, Java 6 update 3, Acrobat 9.5). It's terrible software, but we're stuck with it.

Because of the security implications of running such out-of-date software, the terminal server is isolated from the rest of the network and has a fully locked-down group policy applied to it so that it can only run Internet Explorer, and can only browse to that one URL. This server does not receive any Windows updates whatsoever. The server also reboots itself nightly and purges all user profiles.

For the convenience of our users, I set it up to run IE as a RemoteApp so it just appears to the user as a normal application that they double-click on their desktop. This used to work fine, until one day it just stopped for no reason I can think of.

Here are the symptoms:

• If the user double-clicks the RemoteApp icon from their desktop, IE opens up to a blank page with the correct URL in the address bar. Refreshing the page doesn't do anything, nor does copy/pasting the URL into the address bar.
• If the user signs into the terminal server using a fully interactive desktop session (not via the RemoteApp), then the page works fine.
• After having navigated to the page successfully in full desktop mode, the user can then log off and use the RemoteApp version just fine for the rest of the day.

This obviously has something to do with the user profile. I can break it again on-demand by purging the profile manually. The problem is that I do not want to remove the nightly profile purge because we start running into caching problems later on (this is why the profile purge was implemented in the first place).

The application does not use any custom ActiveX controls. The vendor says that running it in a terminal server environment is an unsupported configuration (because of course they would say that), so they're no help.

Any ideas?

I manage a network of about 1200 workstations and about 200 or so servers. We have migrated away from McAfee in favor of System Center Endpoint Protection for our corporate Anti-Malware solution. Currently, the policy is set to update directly from Microsoft, but I would like to trim the amount of traffic on our external WAN, so I would like to set our SCCM server as the definitions update source.

Currently, we're using WSUS to keep our workstations patched, and I would like to continue using that, as I don't like the way SCCM does patch management. However, where WSUS fails in this regard is that virus defs will not update via WSUS if the user is pending a reboot from a previous round of updates (we do not force reboots around here).

Therefore, I would like SCCM to push out virus defs daily via an automatic deployment rule, but rely on WSUS for everything else. If I enable the Software Update Point role on the SCCM server, will it break existing WSUS functionality?

I have configured BitLocker and TPM settings in Group Policy such that all the options are set and the recovery keys stored in Active Directory. All our machines are running Windows 7 with a standard corporate image and have their TPM chips enabled and active in the BIOS.

My goal is to make it so that all the user must to do is click Enable BitLocker and away it goes. Microsoft even provides automation samples that can be deployed via script. But there is one small hiccup to making this a smooth process.

In the GUI, when the user enables BitLocker, it must initialize the TPM with an owner password which gets generated automatically. However, the recovery password is displayed to the user and they are prompted to save it to a text file. I can't seem to suppress this dialog and the step cannot be skipped. This is an unwanted (and unnecessary) prompt as the key is backed up to AD successfully.

If I script the deployment, I must supply the owner password in the script when I initialize the TPM and I want it to be randomly generated the way the GUI does.

Is there any way to make a BitLocker deployment truly zero-touch the way I want it?

When you click on an update that has been superseded in WSUS, you get a warning that says you should verify the update is no longer needed before declining it. According to Microsoft, you're supposed to approve the superseding updates first, wait for computers to take them, verify the old ones are no longer needed by clients, and then you can safely decline the superseded updates. Yeah, umm... that's not very practical, Microsoft.

For years I've just blanket declined superseded updates, but I recently came across an article that says you shouldn't do that.

So my question is this: Why not?

Is there ever a scenario in which a particular update is not applicable to a client but the update it supersedes is? Can anyone give me a compelling reason why blindly declining a superseded update is not a good idea?

I am trying to set up a Server 2008 R2 terminal server as a Hyper-V VM on a brand new Cisco UCS blade running Server 2012 R2.

I need the terminal server to support modern display resolutions at 32-bit color, as it will be used to display medical images. Unfortunately, this blade only contains a Matrox G200e video chipset with a whopping 8MB of video ram.

Does there exist a purely software-based video driver that I could use to emulate better graphics hardware? It doesn't have to support DirectX, Aero Glass, video games, or anything like that. It just need to be able to support 32-bit color at 1920x1200. The blade itself has 16 CPU cores with 256GB of RAM, so performance is not an issue.

We're deploying thin clients connecting to a terminal server farm. The computers have high visibility to the public and I would like them to at least look presentable and not like something out of 1995. So I installed the Desktop Experience feature and enabled the Theme service.

The server will not support Aero because it has no 3D graphics, but we can enable the Windows 7 Basic theme, which has the Aero look without the 3D effects. The problem with that theme is that you can select any window color you want, as long as it's baby boy blue.

Is there a way to make those windows another color? The window color controls do nothing.

So we have a situation where a contractor deployed about 200 Windows 7 computers that were cloned improperly. The SCCM cert was not cleaned off the reference machine before it was sysprepped. Now because of the duplicate certs, the SCCM console is getting crapped up with invalid device records all over the place.

I need to script the removal of the bad cert on all these machines but I don't know how to do it from the command line. I assume I would be using Certutil.exe but I can't figure out what arguments to pass. I'm also familiar with WMI and VBScript, so if there were a certificate class I could use that would would work too.

I appreciate any help anyone could offer.