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. --

When I deployed SCCM 2012 SP1, I tore down my previous SCCM installation and rebuilt it on a Windows Server 2012 server with SQL Standard 2012. I managed to update the majority of my clients running XP and Windows 7. Today I tried installing the client on my first 2012 server, with the error code 80004005 in the subject. The following ccmsetup.log entries appear. What makes me scratch my head is that the client installed on the new SCCM server, which is also Server 2012. It does install by hand though; it says it couldn't install the Microsoft Policy Platform component. However, if I install this component separately (a simple "next next finish" install) I can do the rest of the setup. Is this a matter of Server 2012 being a little more paranoid about what's auto-installing? Do I have this to look forward to when I start rolling out Windows 8? <![LOG[Couldn't verify 'C:\Windows\ccmsetup\MicrosoftPolicyPlatformSetup.msi' authenticode signature. Return code 0x800b0101]LOG]!><time="10:21:36.257+360" date="02-05-2013" component="ccmsetup" context="" type="3" thread="636" file="util.cpp:1236"><![LOG[Sending Fallback Status Point message to '[censored].[censored]', STATEID='316'.]LOG]!><time="10:21:36.257+360" date="02-05-2013" component="ccmsetup" context="" type="1" thread="636" file="ccmsetup.cpp:9421"><![LOG[Failed to get client version for sending messages to FSP. Error 0x8004100e]LOG]!><time="10:21:36.257+360" date="02-05-2013" component="ccmsetup" context="" type="2" thread="636" file="ccmsetup.cpp:9503"><![LOG[Params to send FSP message '5.0.7804.1000 Deployment Error 0x80004005. Pre-req file name: C:\Windows\ccmsetup\MicrosoftPolicyPlatformSetup.msi']LOG]!><time="10:21:36.257+360" date="02-05-2013" component="ccmsetup" context="" type="0" thread="636" file="ccmsetup.cpp:9552"><![LOG[State message with TopicType 800 and TopicId {8018722F-2C22-4912-8906-49C35B0FA4C2} has been sent to the FSP]LOG]!><time="10:21:36.272+360" date="02-05-2013" component="FSPStateMessage" context="" type="1" thread="636" file="fsputillib.cpp:752"><![LOG[InstallFromManifest failed 0x80004005]LOG]!><time="10:21:36.272+360" date="02-05-2013" component="ccmsetup" context="" type="3" thread="636" file="ccmsetup.cpp:7086"><![LOG[Deleted file C:\Windows\ccmsetup\ccmsetup.xml]LOG]!><time="10:21:36.272+360" date="02-05-2013" component="ccmsetup" context="" type="1" thread="636" file="ccmsetup.cpp:9156"><![LOG[CcmSetup failed with error code 0x80004005]LOG]!><time="10:21:36.272+360" date="02-05-2013" component="ccmsetup" context="" type="1" thread="636" file="ccmsetup.cpp:10544">

I've had better luck using the intranet zone settings to make IE change transparently between native and compatibility modes. This does mean making sure DNS works properly, if this is an intranet site or internal web application you're having issues with. I've gotten some old web-based apps working with this, even some using Java GUIs and such. Most likely, absolutely every site isn't having this problem. You could edit the Intranet Zone list to include entire domains if you had to, or use Group Policy to specify a list across all PCs in an AD domain. IE9 and IE10 will hide the compatibilty button for those sites. The intranet zone should automatically include any servers with a short hostname only (like http://internal-server/) and you can add your internal AD domain to it (*.internal-domain.local) or internal IPv4 subnet (192.168.0.*) if you don't have DNS working right. So this isn't a 'permanent' F12 mode for all sites, but more of an on-demand switch depending on site.

Glass Houses, Google. :-p It's good to see those double standards alive and well eleven years after the fact.

That's what I found. The SP1 release also included a SQL 2012 Standard download and license. What I'm hoping to determine is if this release is newer than the SP1 beta and SP1 MSDN releases. The RTM release had version 5.0.7711.

As a VL customer I have access to a SCCM+SCEP 2012 that appears to be version 5.00.7804. What version numbers were the SP1 beta or MSDN releases?

Am I the only Windows / IE user on the entire internet that doesn't seem to have IE problems? Or am I the only Windows / IE user that doesn't install every bit of random garbage presented to me by advertisers when I surf? Running IE 9 at home since launch, no issues that weren't solved with the compatibility button. Running W8 / IE10 now, also no issues. Running W7 / IE9 at work with some broken Java-based web apps that still work, by making sure DNS works and browsing internal web application servers by hostname instead of by IP, and invoking the Intranet Zone settings automatically by doing so. (derogatory ASUS comment self-censured)

The SC 2012 client won't install on Windows Server 2003 unless BITS 2.5 is installed first. It also appears BITS 2.5 isn't available on Windows Update or the Update Catalog to push out using WSUS, so I had to push it out by hand. http://mnscug.org/articles/blogs/186-sccm-2012-and-server-2003x64xpx64.html Fortunately we're not deploying any new 2003 servers.

Way back in the earlier days of NT Server, I was taught to use permissions on the file system instead of on the share so I had more granular control over the permissions. Granting Everyone (or Authenticated Users) Full Control over the share should be OK, as long as the NTFS permissions are not like that. In my case I set this permissions scheme up: SYSTEM and BUILTIN\Administrators: Full Control BUILTIN\Users and [domain]\Domain Computers: Read and Execute (Also likely replacing with Authenticated Users: Read and Execute would also work) This allowed automatic download to work. I don't believe this had a bearing on my other problem (client auto-updates only working via WSUS) as my windowsupdate.log keps telling me it was trying to update from the internet instead of from System Center. Though I suppose it's possible System Center-based updates use a different API than the Windows Update API; I was told to check windowsupdate.log. (About that last bit: I had even enabled auditing on the share to determine if I had a permissions problem, and of course I had failure auditing turned on for object access. I didn't see any failure audits unless I deliberately tried to cause one.)

I'm going to have to keep an eye (that is read logs) on my test PCs overnight. My web filter log shows they're still trying to access Windows Update on the internet (and are failing due to filter rules) when left on their own. If I open up access to windowsupdate.com and update.microsoft.com they can auto-update or hand-update. This happens even though I only have the one checkbox (obtain updates from SCCM) turned on. The client does say it's using my custom malware policy and not going to the default malware policy (help / about shows me the applied policy). If you get a chance, would you or someone else see if this problem is reproducible? My test environment has a SCCM server that can access the internet but has clients that cannot, or at least cannot unless an authorized domain user is logged on. I happen to use a Barracuda web filter that authenticates against Active Directory, but you need only isolate your client PCs from the internet to reproduce this problem, say on a subnet or VLAN that can't route out to the internet but can still see the SCCM server. The environment is otherwise identical to this lab. I'm going to go out on a limb and suggest that the lab environment in these examples permits internet access from the servers and from client PCs by default. Our environment happens to restrict internet access per-user, but other environments could just as easily block internet access from desktops completely, while still permitting it from servers. In our production environment, WSUS manages updates for PCs that don't have internet access, and I suppose I could configure WSUS in parallel with SCCM to deliver definition updates in my case. [12 DEC] My test PCs were left on overnight and the windowsupdate.log clearly shows repeated (and failed) attempts to auto-update via windowsupdate.com and update.microsoft.com. I just created an auto-approval rule in WSUS instead of SCCM for Forefront 2010 updates and changed the malware policy to update from WSUS alone. This seems to have taken effect as the update checks (and windowsupdate.log) show me successful updates coming from WSUS without my input. Hand-update seems to work, too. [12 DEC] Reproducing this might be as simple as removing the IP Default Gateway setting from your SCCM client PCs, if the SCCM server, domain controllers (DNS) and client PCs share the same subnet. You also need not leave the clients turned off for an extended period; a FEP client might be up to date but still fail to retrieve new updates and you'll see the errors in windowsupdate.log.

Now I'm confused. For a while I noted that the FEP client wasn't obtaining updates and it seemed to be trying to fetch them from Microsoft Update and the MS malware center when I tried a manual update. This would fail because I have internet access blocked on desktops by default. But if I left the clients alone for a while, they'd come up as updated and running. Is there no manual process to update FEP then, if the only update source selected is the System Center server?