Sponsor post Veeam Special Offers until the end of December: Take on the NEW v8 There are only 2 weeks left to save with these special offers before the price increase! Improve your modern data center with 200+ new features and improvements of the NEW Veeam Availability Suite v8, including Veeam Backup & Replication v8: Save up to 10% + upgrade to v8 for free Offer ends December 31st Veeam Special Offers Or have a look at Full list of Veeam's special offers and promos
Today I deployed applications for Application Catalog usage. During installation the following error message was showed: The software change returned error code 0x643(1603). This is just a generic MSI error and tells you very little. Within Event Viewer the following error message was showed: Administrative Privileges Required. For it seems the user doesn't has enough permissions here?
Within the application deployment, User Experience tab, you can choose Installation behavior. There's "Install for user", "Install for system", and "Install for system if resource is device; otherwise install for user". Mine was configured on last one. Changed that to "Install for system", and all my issues were gone.
So long story short, when deploying to "Install for user", the account must have permissions to run the command-line provided in the chosen deployment type. When deploying to "Install for system", this isn't needed, and deployment is done under SYSTEM permissions.
When looking on Microsoft Technet HERE and HERE it seems that administrator permissions are needed indeed. When using "Install for system" this isn't needed. Issue solved.
Within ConfigMgr 2012 it's possible to update images with offline servicing functionality. When doing that on server media however, it's possible that multiple indexes are found. When that's the case, updates will be installed on all indexes, which takes a lot of time. In this scenario I'm installing 75 updates on a Windows Server 2012 R2 image with 4 indexes, which are:
When starting offline servicing on this image, a total of 300 updates (4x 75) will be installed. Let's have a look at the ConfigMgr logfile (OfflineServicingMgr.log):
4 images are detected
300 updates are installed
When using DISM however it's possible to remove existing indexes from an image, so offline servicing can do a way better/faster job. This can be done with the following command: DISM /get-imageinfo/imagefile:<path to WIM file>
Now that we know which index to keep and which to remove, use the following command: DISM /delete-image /imagefile:<path to WIM file> /index:<index number to remove>
In my case I removed 3 indexes, because the only index needed is SERVERSTANDARD. Let's have a look again with: DISM /get-imageinfo/imagefile:<path to WIM file>
There's only 1 index left now. Let's start offline servicing again on this image and have a look at the logfile (OfflineServicingMgr.log):
1 image is detected
75 updates are installed
As you can see this did the trick on my Windows Server 2012 R2 image. Did see another image with 8 indexes before also, which is crazy when using offline servicing. Just use above steps for removing them in the future. Just great isn't it?
Offline servicing is still very handy for updating images easily/quickly, when MS Office is not included in the image.
Option: /Get-ImageInfo Displays information about the images that are contained in the .wim, vhd or .vhdx file. When used with the /Index or /Name argument, information about the specified image is displayed, which includes if an image is a WIMBoot image, if the image is Windows 8.1 Update, see Take Inventory of an Image or Component Using DISM. The /Name argument does not apply to VHD files. You must specify /Index:1 for VHD files.
Option: /Delete-Image Deletes the specified volume image from a .wim file that has multiple volume images. This option deletes only the metadata entries and XML entries. It does not delete the stream data and does not optimize the .wim file. This command-line option does not apply to virtual hard disk (VHD) files. /CheckIntegrity detects and tracks .wim file corruption when used with capture, unmount, export, and commit operations. /CheckIntegrity stops the operation if DISM detects that the .wim file is corrupted when used with apply and mount operations.
Today I started a Cumulative Update 3 installation, which is the most recent one on ConfigMgr 2012 R2. As always (?) a reboot is needed before installation is started. This will be mentioned in the prerequisites wizard. After reboot however, installation hung on the first step. Stopping services.. This on the Windows Management Instrumentation (WMI) service. Let's have a look how to stop this service manually.
First have a look in the Services console for the service name. In this case the service is called WinMgmt. Then open a Command Prompt and type in the following command: -sc queryex [servicename] Replace [servicename] with the services registry name.
After running the query the PID is showed, which is 836 in my case. Type in the following command to stop it definitely: -taskkill /f /pid [PID] Replace [PID] with the number showed before.
This will forcefully kill the hung service! After that installation can be continued as expected.
When deploying the ConfigMgr client on Windows 8 or 2012 systems, it's possible that remote installation fails. This because off User Account Control (UAC) which cannot be completely disabled. Remote Endpoint Agent installation requires that UAC is disabled on the Endpoint. This can be fixed however with a registry change and service restart. Let's have a look.
Deploy the following rule to Windows 8 or 2012 systems to enable Remote installation: REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f net stop LanManServer net start LanManServer
Deploy the following rule to Windows 8 or 2012 systems to disable UAC: REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v EnableLUA /t REG_DWORD /d 0 /f
After that Remote installation is enabled and UAC disabled, and deploying the ConfigMgr client from the Management Console will be fine.
Great news for this month. This because Jalasoft started their special End of the Year Promotion today! You can purchase ANYof their solutions throughout the month of December with a 40% OFF discount. Isn't that good news? The End of the Year Promotion includes the following solutions from Jalasoft: -Xian Network Manager -Xian Wings (mobile solution!) -The Xian SNMP Device Simulator -XIAN Network Manager includes a FREE Xian Wings license!
One month ago my new work device was delivered, a Microsoft Surface Pro 3. I decided to order one because of great look & feel, very good feedback (reviews) and Windows 10 in pipeline. A blogpost about my first experience can be found HERE. Let's have a look at my second experience, after using it for over one month now. Most of my experiences are positive, but some negative ones also!
Still very happy with my device, it's fast, quiet, and have a good battery. It's both a notebook and tablet. Let's have a look!
Pro's -Fast (with i7 CPU, i5 performance don't know) -Quiet (on battery always, on power not all the time) -Battery (approx. 6/7 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 (free?) -Kickstand (can be placed in all positions) -It's both a notebook and tablet
Con's -Fan blowing (on power only, not all the time) -Out of sleep (when in sleep mode, it will wake up. for it seems because of the keyboard?) -One USB port only (far too little to connect multiple devices!) -Keyboard function keys (sometimes Fn is needed, sometimes not, which is confusing)
That's it for now. As you can see more pro's than con's are mentioned, so my total experience with the device is still very good. Hope that Microsoft can fix fan blowing with a future system firmware. Then it will be even better. Microsoft did a great job here!
When capturing Windows 7 SP1 on VMware with a VMXNET3 network onboard, the following error is displayed during Capture media: -Unable to read task sequence configuration disk -ConvertBootToLogicalPath failed to convert 'MULTI(0)DISK(0)RDISK(0)PARTITION(2)\_SMSTASKSEQUENCE\WINPE\SOURCES\BOOT.WIM' (0x80070003) -Failed to find the current TS configuration path -Failed to find the configuration path. The system cannot find the path specified. (Error: 80070003; Source: Windows) -Execution failed with error 80070003
This because of the following configuration: -VMXNET3 Network device in virtual machine -VMware Tools installed/running in virtual machine -VMXNET3 Ethernet Adapter driver missing in boot image -VMware PVSCSI Controller driver missing in boot image
Just use a virtual machine with Intel E1000 or VMXNET3 Network, and uninstall VMware Tools when installed/running. Make sure that both VMware Ethernet and PVSCSI drivers are installed in the boot image(s) used for Capture media.
Last month a new ConfigMgr hotfix became available, specific for Mobile Device Management devices in Microsoft Intune. This hotfix greatly reduces the time that's required to execute a successful retire or wipe of an MDM device by using a notification to "push" these tasks. Without this hotfix, retire and wipe operations could require 24 hours to run successfully, because they relied on a "pull" mechanism of this frequency. This happens with me on installations also, where retirement could require 24 hours of even more! After you apply this hotfix, retire and wipe operations are pushed to the following MDM device types: iOS, Android, Windows 8.1 These operations now run on the device in a matter of seconds, assuming the device is reachable by Microsoft Intune. The device must have an active data connection for Intune to communicate with it. Just great that this ConfigMgr Hotfix speeds up retire and wipe operations to seconds! Note: If a device is not reachable by Intune when a retire or wipe operation is requested, the operation will run the next time that the device comes online and connects with the Intune service. This could require up to 24 hours.
To apply this hotfix, you must have Cumulative Update 3 for ConfigMgr 2012 R2 installed.