When doing deployment on modern ultrabooks or devices like Microsoft Surface, no ethernet adapter is build in. You must use external adapters by using USB connected to have the same behavior. When using multiple cables however, or using the same ethernet adapter for multiple devices, ConfigMgr is going crazy. When that happens it's good to know that SMBIOS GUID's can be used as well instead of using a MAC address. Let's have a read on that one.
The MAC address of a network interface is its unique identifier. Think of it as the serial number of that network interface. When switching network interfaces between devices, MAC addresses wil change also. Therefore we need a SMBIOS GUID. ConfigMgr 2012 uses SMBIOS to identify computers, and falls back to MAC addresses if SMBIOS information is not available. SMBIOS is the GUID that is stored in the Device’s BIOS or UEFI. It’s unique to the device and ConfigMgr uses it to recognize prestaged computers.
When importing systems in ConfigMgr, a computer name and MAC address or SMBIOS GUID must be filled in. MAC addresses can be found in command prompt when typing in "ipconfig /all". SMBIOS can be found in BIOS or by typing in "wmic csproduct get uuid". After re-deployment, where I switched network interfaces, the correct computer name was still used. So when using SMBIOS instead of MAC, it's allowed to switch network interfaces. Good news!
When importing of many new systems is needed, just ask your hardware vendor for a list of SMBIOS GUID's. That way it's easy to import them in ConfigMgr, and prevent MAC address isues. For example: SurfacePro3, 00:1E:8C:17:F0:E5, 3164B0C0-AB47-11DC-A63B-001E8C17F0E5 (for usage in a CSV file). The future is bright, ConfigMgr is still in lead on this one ;)
For more information, have a look on: Microsoft blogs
Last week I did some ConfigMgr client installation on DMZ workgroup servers. Installation of the client went fine, but they went on internet mode after that. There was no possibility to add them to a Site either. Looking in locationservices.log the following lines were showed:
-Failed to resolve 'SMS_SLP' from WINS
-Unable to find lookup MP(s) in Registry , AD, DNS and Wins
-LSIsSIteCompatible: Failed to get Site version from all directories.
-failed to get dp locations as the expected version from mp
The installation line used was as follows:
Ccmsetup.exe /mp:<FQDN> /logon SMSSITECODE=XXX FSP=<FQDN>
After a few installations I found the following website:
About Client Installation Properties in Configuration Manager 2012
It mentions:
/source:<Path> = Specifies the location from which to download installation files. You can use a local or UNC installation path. Files are downloaded by using the server message block (SMB) protocol.
/mp:<Computer> = Specifies the source management point for downloading installation files. Files are downloaded over an HTTP or HTTPS connection, depending on the management configuration for client connections. This download uses BITS throttling, if BITS throttling is configured. If the management point is configured for HTTPS client connections only, you must verify that the client computer has a valid PKI client certificate.
/logon = Specifies that the client installation should stop if any version of the Configuration Manager 2012 or SMS client is already installed.
SMSMP = Associates the Configuration Manager 2012 client with the specified management point. You can specify a fully qualified domain name as this property.
In the end I used the following installation line to install ConfigMgr 2012 Clients on DMZ workgroups servers successfully:
Ccmsetup.exe /source:<path> SMSSITECODE=XXX FSP=<FQDN> SMSMP=<FQDN>
Hope it helps!
Source:
Install SCCM 2012 Client on DMZ workgroup servers
Managing workgroup clients in Configuration Manager 2012
Today I did another ConfigMgr upgrade from SP1 to R2 with 3 remote Distribution points (DPs). Nothing to worry you will say. After the upgrade (which was 100% fine) the Primary server and 1 remote DP was working fine. Deployment could be done, everything okay. Nothing to see in Site and System status. The other 2 remote DP's however didn't want to PXE boot because of error "PXE-E53: No boot filename received". Last line in SMSPXE.log was ================= PXE Provider shutdown. =====================
I did a lot of things after that:
-Restart WDS services
-Update both boot images and checked properties
-Restart multiple Site servers
-Checked logfiles (On primary and Site servers)
-Checked DHCP scope options
-Checked local security
-Checked SMS Component Manager
-Checked firewall status
-Checked no antivirus in place
SMSPXE.log was showing me the following lines:
-RequestMPKeyInformation: Send() failed.
-Failed to get information for MP: http://FQDN. 80004005
-PXE::MP_InitializeTransport failed; 0x80004005
-PXE::MP_LookupDevice failed; 0x80004005
-RequestMPKeyInformation: Send() failed.
-Failed to get information for MP: http://FQDN. 80004005
-PXE::MP_InitializeTransport failed; 0x80004005
-PXE::MP_ReportStatus failed; 0x80004005
-PXE Provider failed to process message.
-Unspecified error (Error: 80004005; Source: Windows)
-98:4B:E1:7E:6D:89, 39C6D000-9BED-11E0-0000-984BE17E6D89: Not serviced.
-Cannot read the registry value of MACIgnoreListFile (00000000)
-MAC Ignore List Filename in registry is empty
Nothing didn't work here! When looking on MS TechNet they say you must reinstall WDS, PXE, DP all over again. Not exactly what I had in mind here. Long story short, after a few hours checking I rebooted the Primary Site server, restarted WDS services on both DPs again, and everything was working in a few minutes. First line in SMSPXE.log was now ================= PXE Provider loaded. =====================
Very happy with the (easy) solution, but very strange ConfigMgr didn't gave me an error. There's no mentioning of rebooting a Primary Site server after the upgrade also. Lessons learned: Reboot the Primary Site server and Site servers after an migration always.
Source:
Upgrade ConfigMgr 2012 SP1 to 2012 R2 Preview
Management Point PXE Boot Error 80004005 After SP1 Upgrade
SCCM 2012 R2 upgrade broken WDS/PXE
PXE-E53: No boot filename received
Microsoft has announced the first build of Windows 10 Technical Preview for Phones. I used Windows 8.1 Technical Preview several months on my device. After using my Samsung Ativ S for almost 2 years now, i'm still very happy with my choice. My next Phone will run Windows 10 for sure, no doubt about that. The reason that multiple favorite apps are missing, is no obstacle for me. Microsoft rocks!
When you want to run Windows 10 Technical Preview, just make sure to follow the next steps:
-Join the Windows Insider Program
-Register your device to receive builds as over the air updates
-Builds will come to you automatically as they are ready, after being validated by engineers at Microsoft and used on their own phones
-Use the built-in Windows Feedback app to send us problem reports and suggestions
-Updates will continue all the way up to the final build that goes out to all customers
-You can roll your phone back to the previous OS any time you’d like
If you’re a Windows Phone customer and love to try the latest stuff before anyone else, or a Developer or IT Pro who works with Windows Phones, joining the Windows Insider program and trying out this build may be right for you. You’ll be getting an insider’s view and getting builds that normally would have only been available to Microsoft engineers in the past. Same as on Windows 10 Technical Preview.
There are a lot of known issues mentioned already. Just have a look at them to see what to expect. Still great to have the opportunity to try the earliest publicly available preview for Windows 10 Technical Preview. Do you take the risk or not, that's the question.
Source: Blogging Windows
When creating a new report on the ConfigMgr server, the following error message is displayed: "The Report Builder click-once application does not exist on the report server. Ensure that the report builder application manifest exists on the server and try again." Point is Report Builder 3.0 must be installed first. In my situation I use a single ConfigMgr server and a remote SQL server with Reporting database. After installation however the error message displayed is still the same. What's going on here!?
Lucky me I found the following website: TechNet blogs
It mentions: On the computer running the ConfigMgr console, open the Windows Registry Editor. Browse to HKLM/ SOFTWARE/ Wow6432Node/ Microsoft/ ConfigMgr10/ AdminUI/ Reporting. Double-click the ReportBuilderApplicationManifestName value to edit the value data. Change ReportBuilder_2_0_0_0.application to ReportBuilder_3_0_0_0.application, and then click OK.
After that additional steps were needed also:
Use Notepad or any text editor to open the file: *Note Open Notepad as Administrator, otherwise you won’t be able to save the edits.
"C:\ Program Files (x86)\ Microsoft Configuration Manager\ AdminConsole\ bin\ Microsoft.ConfigurationManagement.exe.config"
Scroll down to the <ReportBuilderMapping> section.
In my case it originally contained
<ReportBuilderMapping>
<add key="11.0" value="ReportBuilder_3_0_0_0.application"/>
<add key="10.50" value="ReportBuilder_3_0_0_0.application" />
<add key="10.0" value="ReportBuilder_2_0_0_0.application"/>
<add key="DEFAULT" value="ReportBuilder_2_0_0_0.application"/>
</ReportBuilderMapping>
We want to replace the 2's in those last two lines with 3's, so it looks like this:
<ReportBuilderMapping>
<add key="11.0" value="ReportBuilder_3_0_0_0.application" />
<add key="10.50" value="ReportBuilder_3_0_0_0.application" />
<add key="10.0" value="ReportBuilder_3_0_0_0.application"/>
<add key="DEFAULT" value="ReportBuilder_3_0_0_0.application"/>
</ReportBuilderMapping>
After that it was finally possible to open the SQL Report Wizard.
Sometimes there are multiple Management points installed for high availability or communication reasons. With Distribution points you set boundary groups to decide with one to use. With Management points they will be randomly selected. This can be seen in ClientLocation and LocationServices logfiles. With Cumulative Update (CU) 3 however there's a possibility to set the Management point also. In this scenario you have MP1 and MP2, where MP1 is forced (for example). Let's have a look at the logfiles after applying the key:
Key: HKLM\SOFTWARE\Microsoft\CCM:AllowedMPs
Type: Reg_Multi_SZ
Value Data: <Management point>
ClientLocation.log
-Rotating assigned management point, new management point is: 'MP1'
-Assigned MP changed from 'MP2' to 'MP1'
This will be applied daily. (every 25 hours)
LocationServices.log
-The MP name retrieved is 'MP1'. MP 'MP1' is compatible
-The MP name retrieved is 'MP2'. MP 'MP2' is compatible
-Retrieved MP 'MP1' from Registry
-Attempting to retrieve lookup MP(s) from AD. Lookup Management Points from AD: 'MP1' and 'MP2'
-Not persisting assigned management point 'MP2' because it is not in the list of allowed MP's
-MP list is forced, ignoring MP 'MP2'
-Default Management Points from MP: 'MP1'
This can be handy when you want to enforce Management points for static systems. For roaming systems this is not recommended, because it will still be communicate with the Management point, even when on another location. Still great to see that Management point can be enforced, when no use of a Secondary site is made.
More information: MS TechNet Blog
This week I had a strange issue in Remote Tools. Everything was working fine on the ConfigMgr client, and Remote Tools for it seems also. But when starting the "Send Ctrl-Alt-Del Key" nothing was happening. Strange issue, never seen that before! The solution for this is not that hard, because other people has already found a solution for it. As far as I know a GPO is blocking this functionality.
Just create or edit a Group Policy, browse to Computer Configuration, Policies, Administrative Templates, Windows Components, Windows Logon Options. In there enable the setting "Disable or enable software Secure Attention Sequence" and configure it on "Services and Ease of Access applications". After a GPupdate you will see the "Send Ctrl-Alt-Del Key" is working (again)! Happy again :-)
Source: Microsoft TechNet
Today Cumulative Update (CU) 4 for ConfigMgr 2012 R2 is released. It fixes 27 issues and 4 additional changes are included. No need to install CU3 anymore when using this one.
Here's a list of issues that are fixed, there are quite a lot of them:
- Client (2 fixes)
- Software distribution and application management (6 fixes)
- Network Access Protection (1 fix)
- Operating system deploymenjt (2 fixes)
- Administrator Console (1 fix)
- Site servers and site systems (6 fixes)
- Mobile devices (5 fixes)
- Migration (1 fix)
- Reporting (2 fixes)
- Software updates (1 fix)
Additional changes that are included in this update:
- Windows PowerShell (lot of changes)
- Data replication (performance replications)
- Endpoint Protection (anti-malware platform update)
- Operating systems other than Windows (Mac OSX 10.10, Suse Linux Enterprise Server 12 (x64)
Just install it in your environment when experiencing problems described in this article. When not affected by these problems, Microsoft recommends to wait for the next service pack that contains this update. The version that is displayed in the About System Center Configuration Manager dialog box is 5.0.7958.1501.
This update replaces Cumulative Update 3 for System Center 2012 Configuration Manager R2
For more information or download the update have a look here: Microsoft Support
When System Center Endpoint Protection (SCEP) updates are not applying and the following errors are mentioned, Windows Update is not configured right. Let's first have a look at the errors:
WindowsUpdate.log
-CNetworkCostChangeHandler: RegisterForCostChangeNotifications: CoCreateInstance failed with error 80004002
-RegisterNetworkCostChangeNotification: Error 80004002
-Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037
-Network Cost is assumed to be not supported as something failed with trying to handls to wcmapi.dll
-CSerializationHelper: InitSerialize failed: 0x80070002
UpdatesDeployment.log
-Job error (0x87d00692) received for assignment
WUAHandler.log
-Failed to Add Update Source for WUAgent of type (2) and id {}. Error = 0x87d00692
Long story short, there was an unknown WSUS policy in-place! After changing few settings everything was working immediately.
Just make sure "Allow Automatic Updates immediate installation" is enabled, and "Specify intranet Microsoft update service location" is pointing to the ConfigMgr SUP server on port 8530/8531. Then you will be fine after all. Hope it helps!
Source: SCEP updates pushed out to clients through SCCM 2012
