The solution to “The source files could not be found” when installing .NET Framework 3.5 on Server 2012 (or Windows 8) is to:
- Pop in the DVD (or the ISO for the DVD)
- Start the ADD ROLES AND FEATURES Wizard and click the obvious choices up until the CONFIRMATION screen
- on the CONFIRMATION screen of the ADD ROLES AND FEATURES WIZARD, you need to click the SPECIFY SOURCE link (tiny link at the bottom of the window)
- Point the source path to D:\sources\sxs\ (obviously change D:\ to whatever your DVD drive letter is)
Also note that if you download the .NET 3.5 installer from the web and then try to run it, the install will error out with:
Install from roles and features
For more detail read MS KB2734782:
In Windows 8 and in Windows Server 2012, the .Net Framework 3.5 is a Feature on Demand. The metadata for Features on Demand are included in Windows 8 and in Windows Server 2012. However, the binaries and other files associated with the feature are not included. When you enable the feature, Windows tries to contact Windows Update to download the missing information to install the feature.
To get Windows 10 ready for imaging, use the audit mode prior to imaging. After you enter the audit mode, you can install device drivers, custom software etc. Then you can create your image for deployment.
Boot to audit mode manually (on a new or existing installation)
- At the OOBE screen, press CTRL+SHIFT+F3.Windows reboots the computer into audit mode, and the System Preparation (Sysprep) Tool appears.
The CTRL+SHIFT+F3 keyboard shortcut does not bypass all parts of the OOBE process, such as running scripts and applying answer file settings in the oobeSystem configuration pass.
See https://www.youtube.com/watch?v=m7YI3rtnZCA for more details on how the audit mode works.
Problem: When you try to reboot a remote computer using the command shutdown -m \\remotepc -r -f command, you receive an error message telling you that the Network path was not found. You know the remote PC is accessible via ping.
- Click Start, type regedit in the Start Search box, and then click regedit.exe in the Programs list.
- Locate and then click the following registry subkey:
- On the Edit menu, point to New, and then click DWORD Value.
- Type LocalAccountTokenFilterPolicy for the name of the DWORD, and then press ENTER.
- Right-click LocalAccountTokenFilterPolicy, and then click Modify.
- In the Value data box, type 1, and then click OK.
- Exit Registry Editor.
When you run sysprep under Windows 10 (Windows 8/8.1) you receive an error message saying that Sysprep was not able to validate your Windows installation. Review the log file at %Windir%/System32\Sysprep\Panther\setupact.log for details. When you look at the log file, the message tells you that you can not run the sysprep because there is an application that was installed for a user, but was not provisioned for all users. The application name varies. This error occurs because the Windows 10 installs a lot of bloatwares that you must uninstall before you can run the sysprep.
The following scripts will help you uninstall the programs from your image, so you can run the sysprep.
First you can run the following script to see what provisioned apps are running.
Get-AppXProvisionedPackage -Online | Select PackageName
Use this command to remove the provisioned package.
Remove-AppXProvisionedPackage -Online | Select PackageName
Or use this command to remove all of them all at once.
Get-AppXProvisionedPackage -Online | Remove-AppxProvisionedPackage -Online
You may also have to run the following command to uninstall more packages.
Get-AppxPackage | Select Name, PackageFullName
You can then use the following command to remove the packages.
Get-AppxPackage PackageFullName | Remove-AppxPackage (You can use wildcards such as * for full name)
Use the following command to uninstall packages all at once.
Get-AppxPackage -allusers PackageFullName | Remove-AppxPackage (Removes allusers program)
Get-AppxPackage -user username PackageFullName | Remove-AppxPackage (Removes particular users program)
Get-AppxPackage | Remove-AppxPackage (Removes all packages)
After you upgrade your VCenter to 6.5, you’re stuck at loading screen after you login.
This happens because the user you are logging in does not have the proper permission. To fix the issue, try logging in as user email@example.com (using the credential you used for setting up the single sign on).
Once you’re logged in as firstname.lastname@example.org, add the problematic user to proper group, so you can login and manage the VM.
From Home, go to Administration.
Under the Administration menu, go to Single Sign-On, and select Users and Groups. Chooose the user you want to assign permissions to.
Then you give the user the proper Assigned Role that you need.