Manage Server 2008 from 2012 Server Manager

One of the biggest improvements to Windows Server 2012 is the (almost) all encompassing Server Manager. From any 2012 server you can now manage any other 2012 server through WinRM - but if you add a 2008 or 2008 R2 server to Server Manager, you will get a manageability warning of “Online – Verify WinRM 3.0 service is installed, running, and required firewall ports are open“.

To get this working, there are 3 main steps to perform:
Install Windows Management Framework 3.0, Allow remote server management through WinRM (preferred method is via Group Policy), Create firewall rules.

 1. Install Windows Management Framework 3.0 Go and get the appropriate .msu from here: http://www.microsoft.com/en-us/download/details.aspx?id=34595 Windows Server 2008 R2 SP1 WINDOWS6.1-KB2506143-x64.MSU Windows Server 2008 SP2 64-bit versions: WINDOWS6.0-KB2506146-x64.MSU 32-bit versions: WINDOWS6.0-KB2506146-x86.MSU As you can see, there are some slight caveats. 2008 R2 requires SP1 while 2008 requires SP2 to be installed.

2. Allow remote server management through WinRM There are 2 ways you can do this. I would recommend use Group Policy wherever possible, so go to: Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service > Allow remote server management through WinRM Set it to enabled and if you want it to listen on all addresses, put a * in IPv4 and IPv6 filter boxes. Alternatively, you can run the command “winrm quickconfig” to enable remote access

3. Create firewall rules Do this again through Group Policy, allowing port 5985.

Configure PXE in SCCM 2012 (R2) failing with error 0x80041001

When configuring a DP as a PXE point you might see this line in the distmgr.log file stating SCCM failed to configure PXE. “CDistributionManager::ConfigurePXE failed; 0x80041001″

 Now, in SCCM 2012, config manager itself will usually want to do all the configuring of WDS and creating the RemoteInstall folder on the DP, but may not in all cases be successful.
If you see WDS is being installed, but no RemoteInstall folder and the error above in the log, try the following:

1. Deactivate PXE on DP from the Management Server and choose to not automatically uninstall WDS
2. Uninstall WDS from DP and restart
3. Install WDS from Server Manager and restart
4. Activate PXE on DP.

You should now soon see the RemoteInstall folder being created and boot images that you have specified as PXE bootable will be populated in the SMSImages folder.

Error importing drivers into SCCM 2012 SP1

While attempting to resolve what I thought was a malformed driver, I removed the Intel Chipset driver from SCCM. Upon attempting to re-import the driver again I was presented with this error (found in the DriverCatalog log).

“Import failed as \\server\share\driverpath\* is a Reparse Point that SMS does not support via downloads.                 DriverCatalog  06-03-2013 14:24:23”

It turns out to be a problem when the driver source location is hosted on a Server 2012 platform with data De-duplication enabled. After much googling, I found this post on technet.

"please be aware that you can run into issues with using server 2012 de-dupe.  ConfigMgr does not currently support re-parse points, so if you attempt to import a driver package or something else that has a re-parse point in it, it will fail."

One solution is to delete the files from the package source and re-copy, this will remove the re-parse points from the De-duplication database and allow SCCM to import the driver. 

The other is to exclude any directories that are used as replication parents from the data de-dupe schedule. Package source, Driver source and OS installation/updates sources should *not* be de-duped. It's annoying not being able to de-dupe these folders but it's safer than having driver packages suddenly (and randomly) become corrupted.

It's a shame that SCCM 2012 R2 still doesn't support re-parse points as we were enjoying a 71% de-dupe rate. Maybe in the next version Microsoft will fix this problem.

Fingers crossed !

Office Customisation Tool Adding desktopfolder shortcuts

When adding shortcuts in the Office Customization Tool for the desktop for Word, Excel, Outlook etc, you will get the follow error message, please note that if I look at the pre-configured shortcuts for the start menu, they do not have a Start In folder specified.



So I added the start in folder off: C:\Program files (x86)\Microsoft Office\Office15\
Fine, no problem right? Well by doing so and clicking OK, the OCT tool adds the same string to the Arguments field and if I try delete that and OK it, it comes back when I open it again:



Sure enough, after install when launching the programs with these shortcuts I get error messages starting with:
"Sorry, we couldn't find your file. Is it possible it was moved, renamed or deleted? (C:\Program.doc)"

The solution is quite simple. Delete the arguments string and replace it with a space and the shortcut will function normally.

Group Policy Preferences: Enabled/Disable settings

Have you ever noticed this:

Yeah I know. Everybody has seen the power options from Group policy preferences. But have another look. You will see that all the options are colored with green.

What this means is that this settings is Active. You can turn on and off this options by using
F5 F6 F7 and F8.

• F5 activates all the options you see. Turning every option Green
• F6 activates only the chosen setting. Turning it green (you can use TAB to choose or click it with your mouse)
• F7 Disables only the chosen setting. Turning the color to red/white
• F8 Disables all the settings. Turning every option into red/white

When the color is red/white the setting will not come into the play. In other words, 

you disable the option completely.

Here is a picture with all the settings disabled so you can see the difference.

Another interesting thing is that regional settings are red/white by default. Thereby these settings will not be turned on until you use the F5 or F6 key. I wonder how many people that did not know this. It was new to me at least.

You can also right click the setting you have made and view the xml to verify that the option is really on.

Update MS Doc: http://technet.microsoft.com/en-us/library/cc754299.aspx
* This post was copied verbatim from an article I found a while back. It was reposted here for my reference.

Configuring Wireless Settings from the Command Line or a Script

You can also configure wireless settings using commands in the netsh wlan context of the Netsh command-line tool, which enables you to create scripts that connect to different wireless networks (whether encrypted or not). To list available wireless networks, run the following command.

Netsh wlan show networks

Interface Name : Wireless Network Connection

There are 2 networks currently visible



SSID 1 : Litware

 Network Type  : Infrastructure

 Authentication  : Open

 Encryption  : None



SSID 1 : Contoso

 Network Type  : Infrastructure

 Authentication  : Open

 Encryption  : WEP

Before you can connect to a wireless network using Netsh, you must have a profile saved for that network. Profiles contain the SSID and security information required to connect to a network. If you have previously connected to a network, the computer will have a profile for that network saved. If a computer has never connected to a wireless network, you need to save a profile before you can use Netsh to connect to it. You can save a profile from one computer to an Extensible Markup Language (XML) file and then distribute the XML file to other computers in your network. To save a profile, run the following command after manually connecting to a network.

Netsh wlan export profile name="SSID"

Interface profile "SSID" is saved in file ".\Wireless Network

Connection-SSID.xml" successfully.

Before you can connect to a new wireless network, you can load a profile from a file. The following example demonstrates how to create a wireless profile (which is saved as an XML file) from a script or the command line.

Netsh wlan add profile filename="C:\profiles\contoso1.xml"

Profile contoso1 is added on interface Wireless Network Connection

To connect to a wireless network quickly, use the netsh wlan connect command and specify a wireless profile name (which must be configured or added previously). The following examples demonstrate different but equivalent syntaxes for connecting to a wireless network with the Contoso1 SSID.

Netsh wlan connect Contoso1

Connection request is received successfully

Netsh wlan connect Contoso1 interface="Wireless Network Connection"

Connection request is received successfully

Note that you need to specify the interface name only if you have multiple wireless network adapters—an uncommon situation. You can use the following command to disconnect from all wireless networks.

Netsh wlan disconnect



Disconnection request is received successfully

You can use scripts and profiles to simplify the process of connecting to private wireless networks for your users. Ideally, you should use scripts and profiles to save users from ever needing to type wireless security keys.
You can also use Netsh to allow or block access to wireless networks based on their SSIDs. For example, the following command allows access to a wireless network with the Contoso1 SSID.

Netsh wlan add filter permission=allow ssid=Contoso networktype=infrastructure

Similarly, the following command blocks access to the Fabrikam wireless network.

Netsh wlan add filter permission=block ssid=Fabrikam networktype=adhoc

To block all ad hoc networks, use the Denyall permission, as the following example demonstrates.

Netsh wlan add filter permission=denyall networktype=adhoc

To prevent Windows from automatically connecting to wireless networks, run the following command.

Netsh wlan set autoconfig enabled=no interface="Wireless Network Connection"

You can also use Netsh to define the priority of user profiles (but not Group Policy profiles). Group Policy profiles always have precedence over user profiles. The following example demonstrates how to configure Windows to connect automatically to the wireless network defined by the Contoso profile before connecting to the wireless network defined by the Fabrikam profile.

Netsh wlan set profileorder name=Contoso interface="Wireless Network Connection"

priority=1

Netsh wlan set profileorder name=Fabrikam interface="Wireless Network Connection"

priority=2

Netsh has many other commands for configuring wireless networking. For more information, run the following at a command prompt.

Netsh wlan help

Note

When troubleshooting problems connecting to wireless networks, open Event Viewer and browse the Applications And Services Logs\Microsoft\Windows\WLAN-AutoConfig event log. You can also use this log to determine the wireless networks to which a client is connected, which might be useful when identifying the source of a security compromise.

Windows Batch Script - Getting Script Location (Directory/Path)

Inside a Windows batch file (.bat or .cmd) you can reference the drive and folder where the batch file is located by: %~D0
CHDIR %~DP0
The first line causes the script to change to the drive where the script is located.
The second line causes the script to change to the directory where the script is located.
See Call command for further information.

Windows 7 Bug

Windows 7 has a bug in the handling of %~dp0 and %~f0 which can cause this to fail. When running a .cmd or .bat script and using %~f0 or %~dp0 to resolve the batch script name if the batch script name has spaces (ex: "my script.cmd") and you chdir within the script then further references to %~dp0 will incorrectly resolve to the new cwd instead of the correct batch script location.
This does not happen if the script name has no spaces in it.
Example script below:

@REM When this script is named "test.cmd" (no spaces) it works as expected for the value of %~f0

@REM When this script is named "test with spaces.cmd" it does not work

echo "Stage 1:  dp0 == %~dp0"

SET STAGE1=%~dp0


%~d0
cd "%~dp0"
mkdir TestSubFolder
cd TestSubFolder

echo "Stage 2:  dp0 == %~dp0"
echo Should have gotten value %STAGE1%

Work Around

I've filed a bug with Microsoft at https://connect.microsoft.com/PowerShell/feedback/details/617705/windows-shell-bug-with-how-dp0-is-resolved. In the mean time if you make the FIRST statements in your batch as follows you can still use this trick:

@REM Must set these first thing due to bug in Windows 7 when batch script filename has spaces in it
SET BATCH_SCRIPT_DRIVE=%~d0
SET BATCH_SCRIPT_FOLDER_PATHNAME=%~dp0

You could then do
%BATCH_SCRIPT_DRIVE%
CD "%BATCH_SCRIPT_FOLDER_PATHNAME%"
to make the current working drive and directory the same as your scripts.