Since this week built-in mobile device management (MDM) is available for Office 365 commercial plans. With MDM for Office 365, you can manage access to Office 365 data across a diverse range of phones and tablets, including iOS, Android and Windows Phone devices, without the need for Microsoft Intune. The built-in MDM features are included at no additional cost in all Office 365 commercial plans, including Business, Enterprise, EDU and Government plans.
Office 365’s MDM capabilities work to keep your data safe in three ways:
-Conditional Access: Setup security policies to ensure that Office 365 corporate email and documents can be accessed only on phones and tablets that are managed by your company and are compliant.
-Device management: Manage security policies such as PIN lock and jailbreak detection to help prevent unauthorized users from accessing corporate email and data on a device when it is lost or stolen.
-Selective wipe: Remove Office 365 company data from an device while leaving personal data in place.
When looking at the Feature Comparison, there are big differences seen between Exchange ActiveSync, MDM for Office 365, Intune Standalone and Intune + ConfigMgr (Hybrid). This Feature Comparison can help to decide which solution offers the functionality needed.
When looking for protection beyond what’s included in Office 365, you can subscribe to Microsoft Intune, part of the Microsoft Enterprise Mobility Suite, and receive additional device and application management capabilities for phones, tablets and PCs. With Microsoft Intune actions such as cut, copy, paste and save as to applications can be restricted as well, keep corporate information even more secure.
Nice to see that Office 365 has MDM capabilities from now on!
Source: Office Blogs
In my daily work I'm doing ConfigMgr implementations a lot. Multiple features missing in ConfigMgr 2007 were implemented in the 2012 release, which is still an awesome product (if you ask me)! Let's have a look at the most wanted features requested by customers. Don't know for sure what the 'vnext' release will bring, but still want to mention them. When having more, just leave a comment.
1) Hash value error during deployment: When updating a single package during deployment, which is part of a OSD task sequence, it fails because of hash value. When having a large enterprise company, it's hard to explain this! Maybe OSD and packaging are different teams then. Or people are working 24 hours around the globe in a single ConfigMgr Site. Just offer both old and new hash for a few hours and don't let the task sequence fail because of this! A colleague mentions: When this is the case, ConfigMgr isn't an enterprise product, and I think he is right on this point. (Must check it again)
2) Continue task sequence after error: It's crazy that when a task sequence fails (which happens a lot during testing), you cannot restart the task sequence from the point it fails. One mistake and you can start all over again, or you must enable "continue on error" on every step or group. Why not ask a question if you want to continue OSD after all? Makes life a lot easier during imaging.
3) User Environment Management (UEM): When customers want UEM functionality, they must use Group Policy, Preferences, MS UE-V, RES Workspace Manager, Imideo Flex Profiles or AppSense. Why not building more of Group Policy and Profile management in ConfigMgr, so you have best of both worlds? Hope that this part is available in the 'vnext' release, because Windows 10 may be controlled with ConfigMgr completely! Source: Windows 10 enterprise management with System Center Configuration Manager and Intune
4) Application control after deployment: When customers using ZENworks Configuration Manager (ZCM), it's hard to sell the ConfigMgr product. This is not because of imaging, which is a very strong selling feature! It's because of UEM and application control, which is part of ZCM by default. No way you can deploy shortcuts and decide on which time an application becomes available and on which time it's removed. This feature is requested in education a lot, where exams must be available on specific times only. Hope this will be way better in the 'vnext' release, not only on Windows 10, but on applications also.
5) Show collection membership for systems: One of great features of Powershell Right Click Tools, which let you you see in which collections a system or user resides. Should be default functionality in ConfigMgr if you ask me. Why not adding more management tools by default on systems and collections?
6) Black screen when using remote control: Hide the screen from the end user, when typing in sensitive information. Can be a valuable feature, because other remote tools offers this functionality also. Instead of a black screen, a message like "work in progress, please wait" is a nice-to-have also.
7) Change Distribution point (DP) when not available: When you have multiple DP's in the same IP-range, and content is available on one DP only, ConfigMgr is waiting for content and fails afterwards. Content is randomly selected on DP's, so you don't know at forehand which DP is selected per package. When adding content during deployment on the other DP, it will still continue (lucky enough). Better would be, when ConfigMgr doesn't see the needed content on a DP, it will use another one automatically.
Update 15-4-2015:
8) Enforce installation or upgrade during logon/logoff: Software installation can take place when a user is logged on or logged off, but sometimes you want to update a critical component. Best thing to do is to enforce this during logon or logoff, like Group Policy, without the possibility to use the component on the system. This isn't possible at the moment, so companies which are in 24/7 business, have a challenge that way.
Hope that some of features mentioned here are build-in a next release, or added at a later time. Time will tell ;)
During deployment I'm using SCEP installation and update packages a lot. When using the script from Chris Nackers, new definitions can be downloaded automatically each day. Therefore a system is deployed with the latest SCEP update during deployment, and there's less security risk after deployment. Most of time SCEP installation, and antimalware/ antispyware (MPAM) updates goes fine, but Network Inspection System (NIS) updates goes wrong. Errors given are:
-Installation completed with exit code 0x80004005
-Installation failed with error (0x80004005)
-Install Software failed, hr=0x80004005. The operating system reported error 2147500037: Unspecified error
This because you're using the wrong version then. When looking on Microsoft Malware Protection Center, the following is mentioned:
1. Open your security software by double clicking on the icon in the system tray (you may need to click the arrow to see the icon) or, in Windows 8.1, search for Windows Defender:
2. Click the arrow next to Help and choose About:
3. Your software version number is displayed at the line labelled Antimalware Client Version
For version number 4.1.522.0 and above, you must download the Network Realtime Inspection definitions:
-For 32-bit versions of Windows, download 32-bit Network Realtime Inspection definitions
-For 64-bit versions of Windows, download 64-bit Network Realtime Inspection definitions
If you have a version number lower than 4.1.522.0, you must download the Network Inspection Service definitions:
-For 32-bit versions of Windows, download 32-bit Network Inspection Service definitions
-For 64-bit versions of Windows, download 64-bit Network Inspection Service definitions
So yes, there is a difference between Network Realtime Inspection (NRI) and Network Inspection Services (NIS) definitions.
Source: Malware Protection Center
More blogposts on this topic:
Install and update Endpoint Protection (SCEP) during a task sequence
During re-deployment on a HP EliteBook Revolve 810 G3 tablet, the following error message was shown: "An error occurred with the boot selection, verify media is present and retry". Because of that no WinPE is loaded at all, and deployment is not possible. Lucky me the solution was not that hard. Let's have a look at the solution:
Boot your laptop and press F10.
Select [System Configuration]
Select [Boot Options]
Scroll down to [SecureBoot Configutation]
Disable BIOS Secure Boot
Change BIOS Boot Mode to UEFI Hybrid or Legacy Mode
Save and exit
Now boot and press [F12] and PXEboot works
Hope it helps!
Source: HP EliteBook Revolve 810 Tablet - PXE Boot Failure
Update: An ever better solution is as follows:
-Change BIOS to UEFI Native and SecureBoot
-Remove options 060, 066 and 067 from DHCP settings
-Add IP-Helper which is pointing to the WDS and DHCP server
Besides of that the following information:
Try to get rid of DHCP options and use IPhelpers instead. Also make sure that you are using a boot images that matches the architecture of the OS to be deployed. (Torsten)
UEFI is a new beast that has issues with DHCP scope options. UEFI is *very* different than traditional BIOS. (Jason)
Source: UEFI PXE BOOT ERROR
Since November last year I'm using a Microsoft Surface Pro 3 as primary device for my daily work. I wrote multiple blogposts about my experience in November and December. For over 5 months I'm very happy with my choice, never had a doubt I made the wrong choice here. But still there are some minors left. Let's have a look at my experience so far. Pro's and Con's are taken from my post before.
Pro's (changes in bold)
-Fast (with i7 CPU, i5 performance don't know)
-Quiet (on battery always, on power not all the time)
-Battery (approx. 8/9 hours with Office and Internet open)
-12" display (sharp, resolution, pen support)
-Pen (great in presentations)
-Weight (1,1 kg with keyboard)
-New generation device, high wow factor!
-Windows 10 upgrade coming (waiting for RTM to upgrade)
-Kickstand (can be placed in all positions)
-It's both a notebook and tablet
Con's (changes in blue)
-Fan blowing (on power only, not all the time)
As mentioned in the links below, this is being caused by the Windows Installer Module and the Windows Installer Module Worker, which start in the background at random times and cause the CPU to work at higher speeds. This causes the heat and the fans to kick into overdrive. When stopping these processes in Task Manager, my Surface is as quiet as on battery in seconds! Hope that this issue is fixed when moving to Windows 10 in a few months. Otherwise a hardware replacement may be needed to resolve this.
-Out of sleep (when in sleep mode, it will wake up. for it seems because of the keyboard?)
Sometimes my device will go out-of-sleep, which is annoying because all open programs will be gone afterwards. Strange thing that no hibernation is used for this? For it seems the device stays on, till battery power is reached a critical state. After that the device turns down. Lucky me this happens around rarely and not always. Hope this issue is fixed also when moving to Windows 10.
-One USB port only (far too little to connect multiple devices!)
Last week I ordered a Microsoft Arc Touch Mouse Surface Edition, because of this. The mouse works really fine, and benefit of it is a free USB port which I have now. Again no doubt I made the wrong choice here, and it looks great next to my Surface!
-Keyboard function keys (sometimes Fn is needed, sometimes not, which is confusing)
Well, you will get used to it ;)
-There is no insert key on the keyboard (mentioned by @scambler)
Didn't miss it myself actually. What I am missing on modern devices is the lack of pause key, which is really handy during PXE boot. Just have a look HERE for a workaround on the insert key.
More information about the fan blowing:
Fix found for Microsoft's Surface 3 overheating issues
Excessively loud fan, constant overheating during idle and light tasks
Tools To Simulate CPU / Memory / Disk Load (for testing purpose)
More blogposts on this topic:
Microsoft Surface Pro 3 first experience
Microsoft Surface Pro 3 second experience
Last month I did a ConfigMgr upgrade from SP1 to R2, with Cumulative Update 4 afterwards. At first sight everything seems to be okay. After a few weeks however, customer was mentioning OSD was very slow at Driver package and ConfigMgr client stage installation. Default deployment before the R2 upgrade was around 45 minutes, but after R2 upgrade around 135 minutes! Lucky me I found the following post on Microsoft TechNet HERE and HERE.
It mentions:
It appears that MS support was able to find a solution for my environment.
Immediately after enabling the "allow clients to connect anonymously" setting on each distribution point the time it took for the MDT Toolkit package to download went from 30 minutes to around 20 seconds.
The support tech was unable to explain why this setting was required following the R2 upgrade in our environment. He verified that in his lab environment he did NOT have this setting configured on the DP and he saw no issue downloading the MDT toolkit package.
As much as I would like to have a root cause for this issue I'm just happy that my OSD process isnt taking 3 hours now!
At customer mentioned this was the solution also. Immediately after enabling the "Allow clients to connect anonymously" setting on each distribution point configured, deployment was done in 45 minutes again. Strange enough I did a lot of R2 installations, and a lot of SP1 to R2 upgrades also, but never had this issue before. Still happy with this easy to implement solution. Thanks again!
When deploying Windows 8.x with MDT or ConfigMgr, deployment may stop at the network selection screen. When press Connect in the selection screen, deployment will continue. Within this blogpost I show you how to skip network selection.
Within MDT:
The CustomSettings.ini (which can be found on Properties, Rules on the Deployment Share) needs to be changed as follows:
<OOBE>
<HideEULAPage>true</HideEULAPage>
<NetworkLocation>Work</NetworkLocation>
<ProtectYourPC>1</ProtectYourPC>
<HideLocalAccountScreen>true</HideLocalAccountScreen>
<HideOnlineAccountScreens>true</HideOnlineAccountScreens>
<HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
</OOBE>
Within ConfigMgr:
The unattend file (additional file which can be used in the Apply Operating System step) needs to be changed as follows:
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="oobeSystem">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<OOBE>
<HideEULAPage>true</HideEULAPage>
<HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
<NetworkLocation>Work</NetworkLocation>
<HideOnlineAccountScreens>true</HideOnlineAccountScreens>
<HideOEMRegistrationScreen>true</HideOEMRegistrationScreen>
<HideLocalAccountScreen>true</HideLocalAccountScreen>
</OOBE>
<RegisteredOwner>Microsoft</RegisteredOwner>
</component>
</settings>
<cpi:offlineImage cpi:source="" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>
For x86 systems, change "amd64" in "x86" to get the job done.
Source locations:
Windows 8.1 deployment in MDT 2013
Windows 8.1 prompting for network (some lines missing)
When using the script from TechNet, the red lines are missing. Therefore an error message is displayed during mini-setup (about /unattend) and deployment stops on that point. Now way you can pass a deployment error during mini-setup, so just use the unattend file mentioned here. Hope it helps!
When deploying packages within a task sequence you can add multiple steps with a single package in every step. When deploying lots of packages, the task sequence will be very large. There is however an alternative, using "Install software packages according to dynamic variable list". That way you can use a single step for as many packages you want. Just configure the following steps:
-Create a collection and add Collection Variables on it. Name must be APP001, APP002, APP003 (for example) and so on. Value must be the package ID value and Program installation name (which is Install in my case). Add as many packages needed.
-In the task sequence add a "Install package" step and choose for "Install software packages according to dynamic variable list": APP (for example). Mark "If installation of a software package fails, continue installing other packages in the list" when needed.
-Just make sure that on every package used, "Allow this program to be installed from the install package task without being deployed" is checked. Otherwise a 80004005 error will follow during deployment.
(instead of APP you can use any name you want, as long as numbers are used. The name used in task sequence must be same.)
Deploy the task sequence on the created collection. All packages will get deployed in a sequence based on the numbering of the collection variables choosed. Just another way for installing packages ;)
In my case I'm installing multiple packages in a single step. Not a problem at all, and very easy to configure.
More blogposts on this topic:
Deploy multiple applications using Dynamic Variables in a Task Sequence
