gordonf

Ahh, there we go. The last line in the error message from the Remote Console told me what I needed: The WMI permissions were overwritten during the OS upgrade, and after I restored the site server's SMS Admins local group to them, Remote Console non-admins could use the Remote Console again. To fix this, on the site server launch wmimgmt.msc console, then bring up the local computer's properties and Security tab. Then browse to root / SMS and root / SMS / site_[site name]. Add the SMS Admins local group back to both of these, and make sure they have Execute Methods, Provider Write, Enable Account, and Remote Enable allowed.

Microsoft explains that an in-place OS upgrade from Server 2012 to Server 2012 R2 is supported (let's make that clear before someone pulls out the backup / reinstall / site recover copypasta, ok?) for a site server running Config Manager 2012 R2 SP1. So, I did just that, and after wrangling with some problems with WSUS, the site server is working as intended. Yes, even WSUS is working properly; I had to fix some site binding problems and edit the web.config to support Windows 10 clients, but that was it. I had to do the in-place upgrade because WSUS 3 broke after a recent Windows 10 update, and the fix was to update to WSUS 4, on Server 2012 R2. Some Remote Console users can't log on to the site server now, though. These users are not domain admins, but they are SMS admins; the site server's SMS Admins local group lists our IT Department's domain global group as a member, and this group also has the site server's Full Administrator role. I dug further and found the site server's SMS Admins local group has needed permissions in DCOM, too. I haven't yet checked the other requirements. Members of the Domain Admins global group can use a remote console, so I think I can eliminate network and firewalling as a cause. It's just members of the SMS Administrators global group or our IT Department global group that aren't also Domain Admins can't use it. What other permissions should I check? While local non-admins don't normally have write access to the AdminUILog folder on the remote console, I can grant Modify access to it and get this output from the SMSAdminUI log. It's pretty generic, though: [7, PID:5448][08/15/2016 10:16:09] :System.Management.ManagementException\r\nAccess denied \r\n at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode) at System.Management.ManagementScope.InitializeGuts(Object o) at System.Management.ManagementScope.Initialize() at System.Management.ManagementObjectSearcher.Initialize() at System.Management.ManagementObjectSearcher.Get() at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.Connect(String configMgrServerPath)\r\nManagementException details: [7, PID:5448][08/15/2016 10:16:09] :Transport error; failed to connect, message: 'The SMS Provider reported an error.'\r\nMicrosoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlQueryException\r\nThe SMS Provider reported an error.\r\n at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.Connect(String configMgrServerPath) at Microsoft.ConfigurationManagement.AdminConsole.SmsSiteConnectionNode.GetConnectionManagerInstance(String connectionManagerInstance)\r\nAccess denied \r\nSystem.Management.ManagementException\r\nAccess denied \r\n at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode) at System.Management.ManagementScope.InitializeGuts(Object o) at System.Management.ManagementScope.Initialize() at System.Management.ManagementObjectSearcher.Initialize() at System.Management.ManagementObjectSearcher.Get() at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.Connect(String configMgrServerPath)\r\nManagementException details: [7, PID:5448][08/15/2016 10:16:14] :System.Management.ManagementException\r\nAccess denied \r\n at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode) at System.Management.ManagementScope.InitializeGuts(Object o) at System.Management.ManagementScope.Initialize() at System.Management.ManagementObject.Initialize(Boolean getObject) at System.Management.ManagementObject.InvokeMethod(String methodName, ManagementBaseObject inParameters, InvokeMethodOptions options) at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.ExecuteMethod(String methodClass, String methodName, Dictionary`2 methodParameters, Boolean traceParameters)\r\nManagementException details:

I successfully installed SCOM clients onto computers belonging to an external but trusted domain, but ran into authentication problems along the way. I had to change one trust relationship setting to make it work. Here's what I found I had to do to make cross-domain installation and monitoring work: * Changed my trust relationship from "External" to "Forest," to enable Kerberos authentication * Open needed network firewall ports, as the external domain's network is separated by a firewall router deliberately * Create an action account that matched a domain account in the external domain * Changed the trust relationship to permit forest-wide authentication, as it was originally selective authentication I'm comfortable with all of these except the last one. When I had selective authentication enabled, I would see event ID 20057 on the external domain PCs, indicating an error 0xC000413 (Authentication firewall); the external domain PCs were not permitted to log on to the SCOM management server. Usually if I want to grant cross-domain logon permission I would go to the computer account and grant the "Allowed to Authenticate" permission to the external domain's account, but that alone didn't work. I granted that permission to the action account first, and when that didn't work I tried granting it to an external PC's computer account. Only after permitting forest-wide authentication did clients start reporting in by themselves. If I want to restore selective authentication to this domain trust, what permissions do I need to grant to what accounts so SCOM clients can report in? --

Haven't yet tried it on 8.1 but this method works on 8 stand-alone. Enterprise, Server and 8 Pro in a domain should use Group Policy settings for this instead. I've done it on 8.1 Enterprise when not domain-joined using gpedit. --

I have one SQL server that is complaining about missing SPN principals. SCOM monitoring is saying SQL can't authenticate using Kerberos because it's missing the SPNs "MSSQLSvc/[server.domain.tld]:1433" and "MSSQLSvc/[server.domain.tld]". It's the default instance. This doesn't seem specific to SQL. I attempted to list SPNs in use with klist and setspn. klist will give me a list for the currently logged-on user, but setspn -L will fail, claiming this: C:\> setspn -L username@domain.tld FindDomainForAccount: Call to DsGetDcNameWithAccountW failed with return value 0x00000525 Could not find account username@domain.tld I'm also seeing odd security log entries, telling me the failure reason is "Account currently disabled," when it is not. The logon failures use Kerberos for the authentication package where the logon successes use NTLMv2. The setspn failure occurs on a domain-joined Windows 7 PC as well as on my affected SQL server. I can't list SPNs for any domain user account or domain computer account. I can log on using a username@domain.tld username from a console or remote desktop. Kerberos seems to work on at least two non-Windows PCs; there are two MacOS X 10.8 PCs that use Outlook 2011 and they log on to Exchange using Kerberos; the users log on to the domain from the MacOS logon screen and they get a Kerberos SPN they can select from Outlook. --

It's the AD DC Last Bind Monitor, in the v6.0.8228.0 version of the Active Directory Server 2008 and above (monitoring) management pack, that's complaining about the DC response time. The screen shot is a graph of the domain controller response time over the past 24 hours. The warning is that the response time is higher than the default warning level of 5 seconds. I determined why this was happening; a port scanning filter included with the Windows Firewall does this. I also found the override setting. When you bring up the Health Explorer for an alert (right click, Open, Health Explorer), you can navigate to what triggered the alert. Bringing up properties for the unhealthy item allowed me to set an override for the threshold warning, and save it in a management pack. This doesn't solve the original problem, but at least I can have SCOM stop complaining about it. I'm asking the firewall folks why this is happening and if I can tune the port scanning filter to not be so paranoid about this. --

Good to see a SCOM section here. Started using SCOM 2012 R2 to monitor a domain network. It's complaining that the DCs are lagging in AD queries: "The AD Last Bind latency is above the configured threshold." DCs talking to the PDC emulator are also complaining, "The Op Master PDC Last Bind latency is above the configured threshold." Turning off the Windows Firewall on the DCs stops the lag, but I don't consider that an acceptable solution. Further research told me that a firewall filter named, "Port Scanning Prevention Filter," is responsible. I won't go into the frustration about that filter here. Is there a way to adjust the threshold in the SCOM health monitors for Active Directory so it doesn't complain about this? The lag itself isn't a workflow-stopper, even if it is annoying at times. --

I got the SCEP client working on a pair of Exchange Server installations, where one was a mailbox and public folder server, and the second held the other needed roles. I did a managed installation, via SCCM, as opposed to stand-alone. The only thing special I did was I created an antimalware policy that avoided EDB and LOG files, put the two servers into their own collection, and applied the modified policy to the collection. Even if you never get malware in e-mail, this should avoid unnecessary scanning. I did similar modified policies for domain controllers (avoided SYSVOL) and SQL servers (avoided MDF and LDF files). --

I came to SCCM from managing software deployments via Group Policy, so the Active Directory environments I work in reflect my GPO-centric approach. For instance I'll create organizational units separated out by OS or CPU architecture, followed by physical location. Here's an example: mydomain.local - Windows 32-bit --- IT Office ------ PC1 ------ PC2 --- Marketing Office ------ PC3 ------ PC4 - Windows 64-bit --- IT Office 64 ----- PC5 --- Marketing Office 64 ----- PC6 This lets me deploy GPOs and other settings from the top down; I'd have a base set of defaults followed by specifics for a given location. My collections in SCCM will use the OU membership to tell which collection to put a PC in, usually as a consequence of migrating software deployments from GPOs to SCCM applications. When I introduce out-of-band management to this kind of AD tree, I'm not able to fit it. OOB Setup says I need to create or use an OU for OOB-managed PCs and ensure the appropriate SCCM servers have read/write access to that OU and can add and remove members to an AD group. But I have more than one OU set up; I can't pick them all. Say I pick "Windows 64-bit" as the OU that the OOB Service Point should use. As it discovers AMT-capable PCs it will create computer accounts in the root of this OU, so the resulting tree looks like this: mydomain.local - Windows 64-bit -- PC5$iME -- PC6$iME --- IT Office 64 ----- PC5 --- Marketing Office 64 ----- PC6 When SCCM does this though, the query rules that maintain my per-location collections will remove the original computer from its collection, and it will create new computer items named, for instance, "PC5iME" (without the "$") in that collection. If I don't have a collection for that OU, it will still have a computer object in the Devices list and it will appear in the All Systems collection, but with the new name. Hm, ok that isn't good. What if I created a new OU, and had SCCM's OOB service point create new computer accounts there instead? The resulting tree looked like this: mydomain.local - AMT-Managed PCs -- PC5$iME -- PC6$iME - Windows 64-bit --- IT Office 64 ----- PC5 --- Marketing Office 64 ----- PC6 ...only if I do that, the collections representing, say, "Windows 7 64-bit / IT Office 64" lose their computer objects entirely, and they don't appear in any other collection but "All Systems," and even then with the modified name like "PC5iME." I really don't want to destroy these OU trees just to accommodate AMT and OOB management, because I still have non-software GPOs that apply per-location, per-OS or per-CPU architecture. Or is SCCM the right tool for managing AMT in this environment? (By the way, why is "AMT" blocked as a search term?) --

Our environment has some dedicated virtual machines acting as file servers only. The largest one still runs Server 2003, with three big virtual disk volumes. I'm beginning to deploy Server 2012 and one file-only server is working well, including file deduplication. I would hand-copy files from one server to the other, but sysadmins are a lazy lot and I wondered if I could just detach a volume from the 2003 server, attach it to the 2012 server, and enable 2012 deduplication on it. I would then recreate the shares on the 2012 server and hope that the file system permissions remained in tact; both servers are domain members. I'd also have to edit logon scripts and home folders to point to the new mappings; no big deal there, and I'd have to do that anyway. The underlying environment is vSphere 5.1, but I wouldn't expect the server VMs to behave differently if this were Hyper-V. --

The only thing I can think of is putting a script in "RunOnce" Registry key for the default user's profile. You could write a script that does a "reg.exe import" or equivalent for the setting you want to change, then put it here: HKEY_USERS\[loaded hive from users\default\ntuser.dat]\Software\Microsoft\Windows\CurrentVersion\RunOnce You'd have to put this modified ntuser.dat file on all of the PCs in your charge, which you could do using SCCM by creating a configuration item (or baseline?) and deploying it, or using a GPO (ironically) to push a startup script out. I used to do something like this for non-Pro XP deployments. I still have the download available, but it was never updated for Vista or 7.

Exchange 2010 SP3 just came out last month. According to what I've read it supports Server 2012. I haven't read the installation steps yet; it might be as simple as ignoring the "this OS is unsupported" message during Setup and the applying SP3 right after. .

Just a wild guess: Did you change the current domain controllers' DNS settings to use the current domain controllers and not the former ones? Forgetting to check this is a pretty common thing to overlook, and I think every AD administrator makes this mistake at least once when demoting old DCs.

It's ben a while since I poked back to this thread. Applying the missing hotfix, or just applying the latest updates from WU, was enough. Thanks for the hints.

Having made so far, I want to know what other admins and PC handy-folks think of it. While I originally did this with the, "Windows can't be secured you id10t," crowd in mind, the first three parts are at least noob-friendly. --