Author Archives: Adnan

Deploy Java Runtime Environment Application using SCCM 2012

I am going to take you through the process of deploying the latest Java Runtime Environment installation using SCCM and making that available to your users.

Firstly we need to download the latest offline version of Java (currently Version 8 Update 25) and extract the MSI file – http://java.com/en/download/manual.jsp.

Launch the Executable file you just downloaded and when the Welcome to Java screen appears, browse to the following location so we can extract the MSI file:

C:\Users\UserName\AppData\LocalLow\Oracle\Java\jre1.8.0_65

Copy the MSI file from this directory in to your SCCM Source directory for your Applications. I like to keep things organised to make it easier in the future when you are adding newer version, For example my folder structure will be similar to this: \\SCCM\Sources\Applications\Java\8.0_65\

Create SCCM Application

image

Launch your SCCM Management Console, click Software Library from the left pane and go to Applications (Overview-Application Management and select Applications).

Click Create Application button from the Ribbon along the top.

Browse to the UNC path for the Java application files on the SCCM Application Source directory, select the MSI and click Next.

Verify the Imported Information and Click Next to add some additional information as shown in the screenshot below. Ensure the Installation Program has the /qn switch at the end.

image

Follow through the rest of the wizard and click Next on the Summary Screen. Click Close to exit the Wizard.

Edit the Application

Select the newly created Application and open the Properties from the Ribbon along the top.

Under the General Information screen, select the checkbox to Allow this application to be installed from the Install Application task sequence action without being deployed.

Click the Deployment Types tab and select Edit for the MSI Deployment Type. Amend the deployment name to Java Runtime Environment as shown below.

image

Select the Programs Tab and enter the information as shown below.

  • Installation Program: msiexec /i “jre1.8.0_65.msi” /qn
  • Uninstall Program: msiexec /x {26A24AE4-039D-4CA4-87B4-2F83218065F0} /qn
  • Product Code: Click Browse and specify the MSI file from the source application directory

image

Select the Detection Method tab, and click Edit Clause for the MSI product clause. Select the second Radio box to make sure the MSI Product Code checks for a specific version of 8.0.650.17.

image

Click OK to close the Detection Rule screen.

Select the Requirements tab and amend the run time details to suit your needs. Click OK twice to close the Application properties.

Distribute Application

Distribute the Application to your Distribution Point/Distribution Point Group by selecting the Application and select Distribute Content.

image

Click Next on the wizard, click Add and select the appropriate Distribution Point/Groups. Click Next and Close to distribute the application files.

Deploy Application

You will now need to Deploy the Application to the your desired collection. I prefer to base my collections on Active Directory Security Groups – Click here for a quick blog on how this can be done in Powershell

Select the Application from the list and click Deploy

image

Click Next on the Content screen as you have already distributed the application.

Select the option to Required or Available for the Application.

  • Available: Will Allow the user to choose to install the application. If this is being deployed to a Device Collection, the application will be visible in the Software Center. Applications which are deployed to User Collections can be viewed from the Application Catalogue, they are only shown in the Software Center once the user has requested the Application.
  • Required: This will force the application on to the workstation within a given time period.

image

You can choose to make this application available after a specific date/time period. Click Next to leave as default.

The User Experience can be configured to display all notifications to the user or only show notifications for required restarts. I prefer to select Display in Software Center and show all notifications.

image

Select the required Alert level and click Next to complete.

The Java Runtime Environment application will now be made available to the ConfigMgr client. You can force the client to check in with SCCM and pick up new policies instead of waiting for the next Application Evaluation Cycle.

Launch Control Panel on the Users workstation and select Configuration Manager. Click the Actions tab and select Application Deployment Evaluation Cycle and click Run Now.

image

The application will now be listed in the Software Center (or the Application Catalogue if you deployed to a User Collection)

image

SCCM 2012 R2: Managing Drivers for your Operating System Deployments

There are a number of different approaches you can take with managing drivers and deploying those drivers to your workstations. These are Auto Apply Drivers and Apply Driver Packages.

Auto Apply Drivers

The most common approach is to add drivers in to the central repository and using the Auto Apply Drivers task. This uses the Plug and Play (PnP) detection to scan the hardware during an Operating System Deployment (OSD) and sends this to the management point, the management point responds with all available drivers on the distribution point and the drivers are downloaded for Windows to install.

We can build on the previous process by filtering out certain drivers using Categories. When we import drivers in to the central driver repository we can apply categories to the drivers, this allows us to customise the Apply Drivers task based on device make and model by adding a Query WMI condition to the Apply Drivers task. The benefit of this approach is we can reduce the amount of drivers the management point needs to retrieve from the distribution point.

The above two approaches share the following disadvantages:

  • Driver Versions: if all drivers are added to a central repository and this includes different version of the same driver you do not have any control of which drivers are applied to which device – this can result in the wrong driver version being applied to a device because they are considered a better match while that driver may in fact cause instability or blue screening.
  • Missing Drivers: During an OSD you may find some device drivers are missing for example Bluetooth drivers, while on the next deployment that particular driver installs successfully. This can occur if the device is not detected when a Plug and Play scan is carried out during an Operating System Deployment – This could be caused due to the devices being switched off (e.g. bluetooth switch is off). If the device cannot be detected during this short period of operating system deployment then this will not be installed.

Driver Packages

I have found the most effective approach to be using Driver Packages for each models of devices, while this can take longer initially, it will prove easier to manage in the long term. Driver Packages does not use plug and play detection to install drivers during an OSD, instead all drivers included in a Driver Package are installed on the device regardless of the device being present.

Despite the initial administrative effort it provides the SCCM admin with greater control on what drivers are deployed regardless of the device being present on the workstation – for example we can install drivers for a USB Bluetooth Device which is not present during an OSD.

I have documented the full procedure to correctly get the driver management process configured using driver packages.

Create Driver Repository

The first step is to create a central source store for both your drivers and driver packages, this can be your existing source folders for your distribution point. For this example I have created a shared folder on my SCCM server with the path E:\Sources and shared as \\SCCM\Sources.

Add drivers to the Central Repository:

  1. From the Laptop, launch Command Prompt and type the following command:
    wmic computersystem get manufacturer 

    and then

    wmic computersystem get model
  2. Make a note of the manufacturer and model of the machines (its important you note the information listed in command prompt rather than what is on the laptop sticker).
  3. Browse to the location of your SCCM software repository: \\SCCM\Sources\DriverSources\Windows7\ and create the folder for the manufacturer you noted earlier
  4. Create a new folder and name it the model number you retrieved earlier.
  5. Launch SCCM Console, Software Library, Operating Systems, Drivers and select Import Driver to launch the Import Driver Wizard
  6. In the Import all Drivers in following network path, click Browse and enter the source path: \\sccm\sources\DriverSources\Windows7\MANUFACTURER\MODEL and click OK
  7. Ensure the option Import the driver and append a new category to the existing category is selected
  8. Click Next
  9. Click Categories, and create a new Category names MANUFACTURER – MODEL e.g. TOSHIBA Satellite Pro C850-10X
  10. Click New Package and create new package with the following settings:
    1. Name: Windows 7 MANUFACTURER MODEL
    2. Path: \\SCCM\Sources\DriverPackages\Windows7\MANUFACTURER\MODEL\
  11. Click Ok and click Next.
  12. You will not need to add the driver to Boot image unless you are creating an updated boot image with new Network/Display drivers. Click Next and complete the Wizard
  13. The Final step after closing the wizard is to deploy the package to the distribution point. This can be done by going to SCCM, Software Library, Operating Systems, Driver Packages and select the newly created Driver Package.
  14. After selecting the driver package, click the Distribute Content button from the ribbon along the top, this will launch the Distribute Content Wizard.
  15. Click Next and click Add and select Distribution Point
  16. Select your distribution point checkbox and click OK.
  17. Click Next and then Finish to close the wizard. Wait a few moments while the package is distribution to your distribution point. This can be monitored using the information view along the bottom of the SCCM Console when you click on the package. Clicking the Refresh button from ribbon along the top will let you view if the package has successfully been targeted to a distribution point.

Adding New Drivers to Task Sequence for Client Builds

  1. From the SCCM Console, Click Task Sequences, right click the task sequence you use to deploy the image and click Edit.
  2. Click Apply Drivers folder, if a folder for your manufacturer is not listed under Apply Drivers, then click Add dropdown menu and select New Group. Enter the Name for your manufacturer and click the Options tab.
  3. Click Add Condition and select Query WMI, under WQL Query enter the following string and edit the manufacturer:
    SELECT * FROM Win32_ComputerSystem WHERE Manufacturer LIKE '%TOSHIBA%'
  4. Click the Manufacturer and click Add Condition and select Drivers > Apply Driver Package
  5. Edit the name of the newly created Apply Driver Package task with the full model of the machine.
  6. Click Browse and select the Driver Package created earlier
  7. Select the checkbox for Do unattended installation of unsigned drivers on versions of Windows where this is allowed.
  8. Click the Options tab and click Add Condition and select Query WMI, under WQL Query enter the following string and edit the model:
    SELECT * FROM Win32_ComputerSystem WHERE Model LIKE '%C850-10X%'
  9. Click Apply and click Ok to complete the Task Sequence.

You should now test your task sequence to confirm all drivers have been installed successfully.

Powershell: Create SCCM 2012 Collections Based on Active Directory Security Group

This script will significantly decrease the length of time taken to create device collections in SCCM. I created this script for a college where I deployed SCCM 2012, it allowed the college to mass create the device collections required for their environment.

First of all we will need to import the SCCM Powershell Module as shown below.
Note the SMSSITECODE variable will be your 3 letter SCCM Site Code and the location of the Module will need to match the installation path of SCCM.

Import-Module "C:\Program Files\Microsoft Configuration Manager\AdminConsole\bin\ConfigurationManager.psd1" -Verbose
cd SMSSITECODE:

There are two parts to this script, the first is the command to create the new device collection (New-CMDeviceCollection) with its given parameters. The second is to add a query membership rule which will specify how the collection is populated (Add-CMDeviceCollectionQueryMembershipRule)

The RefreshType parameter in the example has been set to ‘Both’, this ensures the device collection is populated on the schedule which has been specified and it also uses the Incremental Updates setting of SCCM 2012 to ensure newly added devices in between the schedule are also added. The alternative options for this are ‘ConstantUpdate’, ‘Periodic’ or ‘Manual’.

The script below requires the following parameters in order to run:

  • Schedule Date: In the format of DD/MM/YYYY H:MM AM/PM
  • Schedule Day: Day of the week schedule will begin
  • Limiting Collection
  • Collection Name
  • Security Group Name: In the format of DOMAIN\\SecurityGroupName
#**************************************************************************
#      THE FOLLOWING SCRIPT WILL CREATE A COLLECTION BASED ON AN
#      ACTIVE DIRECTORY SECURITY GROUP
#**************************************************************************
#
#*******************PARAMETERS**********************#
#
#ENTER COLLECTION SCHEDULE DATE#
$ScheduleDate = "16/10/2014 9:00 PM"
$ScheduleDay = "Thursday"
#
$Schedule1 = New-CMSchedule -Start $ScheduleDate -DayOfWeek $ScheduleDay -RecurCount 1
$LimitingCollection = 'All Systems'
#
#ENTER NAME OF COLLECTION#
$CollectionName = "COLLECTION_NAME"
#
#ENTER NAME OF ACTIVE DIRECTORY SECURITY GROUP#
$SecurityGroupName = "DOMAIN\\SECURITY GROUP NAME"
#
#***********END PARAMETERS*********************
#
#*****DO NOT EDIT THE FOLLOWING SECTIONS********
#
#***NAME OF QUERY RULE WILL MATCH COLLECTION NAME#
#
$QueryRuleName = $CollectionName

$SecurityGroupQuery = "select *  from  SMS_R_System where SMS_R_System.SystemGroupName = '$SecurityGroupName' "

New-CMDeviceCollection -Name $CollectionName -LimitingCollectionName $LimitingCollection -RefreshSchedule $Schedule1 -RefreshType Both

Add-CMDeviceCollectionQueryMembershipRule -CollectionName $CollectionName -QueryExpression $SecurityGroupQuery -RuleName $QueryRuleName

I am working on an improvement to this script, which will allow you to choose from multiple queries to form the membership rule. Once complete I will post the complete script up on here.

Deploying System Center EndPoint Protection Client to your Golden Image

When building golden image for your SCCM Workstation, theres a couple of changes you will need to make to the antivirus client before you deploy the image. The following steps can be incorporated in to the Build Task Sequence or alternatively while building your VDI base image.

Software you will need:

Install the Systems Center Endpoint Protection client with the following switches:

scepinstall.exe /s /q /NoSigsUpdateAtInitialExp

Install the latest EndPoint Definition Updates

Next, we will need to modify some registry entries using the PSexec utility, launch an Administrative Command Prompt and run:

c:\psexec.exe -s -i regedit.exe

Delete the following registry keys if they exist:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\InstallTime
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\Scan\LastScanRun
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\Scan\LastScanType
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\Scan\LastQuickScanID
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\Scan\LastFullScanID
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RemovalTools\MRT\GUID

Its important this step is done right at the end of your build image, if this is for your sccm image then ensure your image is captured straight after this. If your building your VDI base image ensure this is the last step prior to shutting down the virtual machine for your snapshot.

Install NVIDIA GPU Drivers on ESXi 5.5

Obtain the latest drivers for specific NVIDIA GPU from the NVIDIA Downloads page – http://www.nvidia.com/Download/index.aspx?lang=en-us, the download will be in a .VIB format.

Upload this VIB file to a datastore on the ESXi host using the vSphere Client/Web Console.

You will need to enter the host in to maintenance mode using the vSphere Client or via the shell:

hostsvc/maintenance_mode_enter

Initiate the install of the driver:

localcli software vib install --no-sig-check -v /vmfs/volumes/DATASTORENAME/PATHTOVIB/FILENAME.VIB

Monitor the Shell window for the progress of the installation, you will see the following message on the window:

Installation Result  
  Message: Operation finished successfully.  
  Reboot Required: false  
  VIBs Installed: VIB NAME

Reboot the host, once rebooted you will need to exit the maintenance mode using the vSphere or Shell:

hostsvc/maintenance_mode_exit

Confirm the installation of drivers

Check the status of the Xorg service by running this command:

 /etc/init.d/xorg status

This should confirm the xorg service is installed.

Troubleshoot the NVIDIA GPU installed in the ESXi Host

You will need to open a SSH connection to the ESXi host to run these commands.

First lets confirm ESXi can pick up the GPU.

nvidia-smi

nvidia smi

The above results show there is a NVIDIA GRID K1 GPU installed.

However, this does not confirm that the GPU is being used.

Confirm if Xorg Service is Running:

/etc/init.d/xorg status

If the service is not running, we can attempt to start the service:

/etc/init.d/xorg start

if the service is started, we can run the following command to list the virtual machines which are using the GPU memory

gpuvm

If successful we should see a list similar to below:

image

Keep an eye out for my next post on the installing the NVIDIA GPU drivers on ESXi 5.5.

Outlook AutoDiscover on Non Domain PCs

I was recently asked about a user reporting problems accessing their Out of Office and Shared Outlook Calendars when accessing Outlook from a Non-Domain Computer. Additionally the user was not able to create an Autodiscover record on the DNS for their public Domain.

Outlook uses the domain of your smtp email account in outlook to try and contact the Exchange Client Access Server using the default methods as described in the Exchange 2007 Autodiscover Service Whitepaper.

However when the computer is in a WORKGROUP and the email domains FQDN cannot be resolved from the Internet then Outlook will be unable to connect to Autodiscover. In order to address this a local Autodiscover.xml file will need to be created and referenced on the local computer.

A local Autodiscover.xml file needs to be created, a sample of which can be found below. This files needs to be copied to a location which the PC can access, if no network share is available then copy the file to a folder on your C drive, and share that folder as hidden share.

<?xml version="1.0" encoding="utf-8"?>

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">

<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">

<Account>

<AccountType>email</AccountType>

<Action>redirectUrl</Action>

<RedirectUrl>https://autodiscover.EMAILFQDN/autodiscover/autodiscover.xml</RedirectUrl>

</Account>

</Response>

</Autodiscover>

Launch RegEdit from Start-Run

Browse to the key HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\AutoDiscover

Right Click AutoDiscover and create a new STRING value

  1. In the Name field, enter the smtp domain of the user. E.g. wordpress.com
  2. In the Value Data field, enter the location of the XML file as UNC path. E.g. \\LOCALPC\c$\autodiscover.xml

Right Click AutoDiscover and create a new DWORD value

  1. In Value Name enter: PreferLocalXML
  2. In Data enter: 1

Close RegEdit

Now, launch Microsoft Outlook and test OOF and Calendars. If this fails – Press the CTRL key and right click the Outlook icon in Task Bar and select Test Auto Configuration. Enter the email address, password details, untick Use Guesssmart and click Test. This should detail any issues with the Autodiscover.

Powershell: Active Directory – Set Change Password at Logon for all Users

When faced with a situation where you have an OU full of users who need to be forced to change password at logon your first option may instinctively be the GUI – Active Directory Users and Computer. This may seem a lot easier than powershell as you only need to highlight all the users, select properties and set the checkbox and there you have it.

However, if you needed to reverse the situation, you are not able to use the same procedure to select the checkbox for all users. This is where powershell saves the day. Here are the steps you need to take:

First things first, Launch a Powershell Window with the Active Directory module

Next, we need to get a list of Active Directory users that match our parameters, for this we will use the Get-ADUser cmdlet with a filter for all users in the OU called Users in my domain.

Get-ADUser -Filter * -SearchBase "OU=Users,DC=justinfra,DC=co,DC=uk

The next step would be to use the | (pipe key) to pipe the results from that search and set the properties for each user account. A quick reference from TechNet Library for the Get-ADUser cmdlet will list -changepasswordatlogon as an available parameter. So we would need to use a foreach-object command to set this property. Here is the full powershell command:

Get-ADUser -Filter * -SearchBase "OU=Users,DC=justinfrastructure,DC=co,DC=uk" | foreach-object {set-aduser $_.SamAccountName -changepasswordatlogon 0 }

Migrate WSUS Content in Server 2012

The Windows Server Update Services content can be moved after the role has been installed and configured using the WSUSUTIL.EXE utility. This can be found on your WSUS server at the following location: “%PROGRAMFILES%\Update Services\Tools\”

You will need to create the directory on the destination location first before running this command, for example D:\WSUS

The command to run is:

wsusutil.exe movecontent "CONTENT PATH" "LOG FILE"

for example:

wsusutil.exe movecontent D:\WSUS\ D:\wsusmove.log

Recover Exchange 2003 Public Folders

There is a great utility by Microsoft which can be used to view the Public Folders in Exchange Server 2003 called
PFDAVAdmin. This can be used to recover Public Folders which have been accidentally deleted.

Note: It will not be possible to recover the items if Exchange has carried out a maintenance cleanup after the deletion of the Public Folder.

Download PFDAVAdmin direct from Microsoft here

Once you have downloaded PFDAVAdmin, extract the files to location of your choice. This version of the utility no longer requires you to run it from the same forest of your Exchange.

Launch PFDAVAdmin.exe and select File, Connect.

PFDAVAdminConnect

Enter the details for your environment and click OK to connect.

Once connected, any Deleted Folders will appear in red, Right click on those folders and select options for recovery.