Wednesday, July 1, 2015

Automating Office 365 Updates in SCCM with Powershell!

Hello everyone!  It has been way too long since the last time I posted here, something I hope to rectify.  Today I would like to talk about Office 365, specifically the Office Click-to-Run package and how you can automate updates in a more controlled manor using PowerShell and Group Policy!

For those who do not know, there are two ways to install Office on your system when you are licensed through Office 365.  There is the standard MSI version that you know and love (if your subscription level allows), as well as the new "Click-to-Run" method, or C2R for short.  C2R is really neat since it is basically a self-contained App-V package that doesn't require the full App-V experience installed on your system.  The biggest benefit (or frustration) of C2R is that the update mechanism changes which allows updates to come in faster ... but it does not use traditional methods such as WSUS or Windows Update.

A bit of back story, at my company we recently deployed Office 365 out to everyone and made the decision to let updates stream automatically from the web.  According to documentation systems should only download the delta difference between the current version and the previous version, so the update traffic shouldn't be too bad.  In hind-sight, this was a terrible idea for a couple of reasons.  The first reason is that we have just shy of 1000 systems/O365 licenses so the sheer number of systems weren't taken into account.  The second is that for some reason, all of our systems decided to download the ENTIRE OFFICE INSTALL instead of just the delta.  To make matters worse, all of this download traffic started on a day that we launched a user outreach program which focused on training and implementation of the Modern Workplace (i'll post about that another time).

So, on to the fun bits.  How we solved our updates issues:

Basically, I wrote a PowerShell script that does the following:

  1. Deletes the current Office 365 Install Source from SCCM Server and from a Shared Network Location
  2. Downloads the latest version of Office 365 and copies the content to a Shared Network Location
  3. Connects to SCCM Database
  4. Updates the Application Version to the version being deployed
  5. Updates Distribution Points with the latest Office package
For the Shared Network Location we are using a path that is replicated to all of our offices so that the actual update happens locally and not streaming over our WAN.

Here is the PowerShell Script with comments:

#  Here you are only removing the "Office" folder inside your source package.  Don't remove the parent folder which has Setup.exe and your XML files, you can reuse these.  For your Shared Network Location you can delete everything.  This assumes that you are not specifying a version in your XML file

Remove-Item -Path "\\SCCMServer\PathTo\Office365\Office" -Recurse
Remove-Item -Path "\\SharedLocation\Path\Office365" -Recurse

# Downloads New Office 365 Content based on your XML and waits until the download is complete

Start-Process setup.exe -WorkingDirectory "\\SCCMServer\PathTo\Office365" -Verb open -args "/download configuration.xml" -Wait

# Grabs the name of the folder that contains the actual office content and stores it as a variable

$a = Get-ChildItem -Path "\\SCCMServer\PathTo\Office365\Office\Data" -Directory

# Copies Office data to your shared network location

Copy-Item -Path "\\SCCMServer\PathTo\Office365\Office" -Destination "\\SharedLocation\Path\Office365" -Recurse

# This line is needed if you are not running your script from SCCM.  The path here is the installation directory of SCCM on your server.  You can also use the installation path for the SCCM console if you wish.  This loads the SCCM Powershell modules so that the rest of the script will work

import-module "\\SCCMServer\Installdir\AdminConsole\bin\ConfigurationManager.psd1"

# Connects to your SCCM Database, where PRI = your site code

Set-Location PRI:

#This updates the Application version number.

Set-CMApplication -Name "Your Application Name" -SoftwareVersion $a

#This Updates your distribution points with the latest version of the Office 365 package

Update-CMDistributionPoint -ApplicationName "Your Application Name" -DeploymentTypeName "Your Deployment Name"

There you have it!  I'm sure many of you are asking "Why am I deleting everything before downloading?" and the answer is simple:

When you download the Office 365 deployment it creates a folder under Office\Data with the new deployment version, and will not remove the old one.  Deleting the old version ensures that your Office deployment package doesn't contain any stale information.  Also, the script runs on the assumption that there is only one folder inside Office\Data, and uses that to update the SoftwareVersion later on.

Here is the script without all the comments:

Remove-Item -Path "\\SCCMServer\PathTo\Office365\Office" -Recurse
Remove-Item -Path "\\SharedLocation\Path\Office365" -Recurse

Start-Process setup.exe -WorkingDirectory "\\SCCMServer\PathTo\Office365" -Verb open -args "/download configuration.xml" -Wait

$a = Get-ChildItem -Path "\\SCCMServer\PathTo\Office365\Office\Data" -Directory

Copy-Item -Path "\\SCCMServer\PathTo\Office365\Office" -Destination "\\SharedLocation\Path\Office365" -Recurse

import-module "\\SCCMServer\Installdir\AdminConsole\bin\ConfigurationManager.psd1"
Set-Location PRI:

Set-CMApplication -Name "Your Application Name" -SoftwareVersion $a
Update-CMDistributionPoint -ApplicationName "Your Application Name" -DeploymentTypeName "Your Deployment Name"

Tuesday, July 16, 2013

SCCM 2012: Maintenance Windows and Business Hours

We all know by now that System Center 2012 Configuration Manager is a client-centric product.  Meaning that, while it gives us admins some power over the system to perform certain tasks, the user is ultimately in control of their device.  One way this is acheived is by the inclusion of "Business Hours" on the client.

I'm not going to go into too much detail on how Business Hours works along with Maintenance Windows, instead please see this wonderful blog post from the MS Server and Cloud Platform Team:

http://blogs.technet.com/b/server-cloud/archive/2012/03/28/business-hours-vs-maintenance-windows-with-system-center-2012-configuration-manager.aspx

Basically, regardless of the Maintenance Window the power is truely in the hands of the end-user for mandatory deployments.  Lets say, for example, that you have an OOB patch that must be pushed out immediately ... soo immediate that you bypass your maintenance windows in order to do it.  If the time is within the Business Hours of the machine (by default its 5AM - 10PM) then the user gets to decide if the installation happens immediately, or if it posponed.

Depending on your patch deployment framework, this can have some serious rammifications if your maintanence windows don't jive properly with Business Hours.  Whats worse is that since Business Hours is a client-side ONLY setting, you can't set this via the ConfigMgr console.


- BUT -

You CAN set this via VBScript or via PowerShell.  Rather than rinse/repeat, here are links to two blogs that outline how to do this:

VBScript (Piped through Google Translate)
http://translate.google.ca/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fwww.mssccmfaq.de%2F2012%2F03%2F26%2Fsoftware-center-business-hours-auslesen-setzen%2F&act=url

PowerShell:
http://powersheller.wordpress.com/2012/11/20/sccm-2012-setting-software-center-business-hours-with-a-compliance-configuration-item/

Given the nature of this I would suggest applying this script at logon to ensure that all systems get updated with an appropriate time.  It should also be added to your Task Sequence so that reimaged systems start with the adjusted Business Hours.

Have Fun!

Friday, July 12, 2013

How to Configure TimeZones dynamically during Imaging (Take Two!)

A few years ago I had posted what I "THOUGHT" was a method to resolve the TimeZone issue that many of us struggle with but it turned out that not only was I completly wrong, but I was actually barking up the wrong tree!

TimeZone configuration can be a major headache when your enterprise spans multiple timezones, or multiple countries, if you are trying to keep your imaging strategy basic and easy to maintain.  I'm not a huge fan of splitting imaging into numerous collections with each collection given their own Task Sequence Variable to identify TimeZone since that just takes too much work, and I'm lazy!  Up until now I have been just dealing with imaging in one TimeZone then manually adjusting based on the region, totally not efficient!

I came across this excellent blog post which explains it quite well:

http://blogs.technet.com/b/eugenev/archive/2012/12/28/task-sequence-time-zone-fun.aspx

Basically, rather than rely on a TS Variable, instead use a VB Script at the end of your Task Sequence that will automatically adjust the timezone based on the DHCP server it is connecting too.  As the blog states, the account used to run this script needs to have read rights to the registry on the DHCP server, but it works qutie beautifully.

Check it out!

Friday, June 28, 2013

Fix: Unable to update User GPO via gpupdate

Group Policy issues are always a pain in the but, I've found.  This one was particularly annoying because of the impact that it had on the user.  The user was unable to access his personal drive on our server (G:\ Drive) as it would not map it during login.  Also, what he didn't mention, the system takes up to 5 minutes to log in.

At first I was strictly working on the drive map issue ... out of 3 network drives that he should get he was only getting one.  Manually running the login script seemed to clear that up temporarily but not permanently.  I then decided to do a GPO update (gpupdate /force /wait:-1) but it threw up an error.  In the System Event Log, I saw this:

The processing of Group Policy failed. Windows attempted to read the file \\domain.local\sysvol\domain.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F\}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:

a) Name Resolution/Network Connectivity to the current domain controller.
b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).
c) The Distributed File System (DFS) client has been disabled.

Since this was the only system on the network having this particular problem, I wasn't convinced that the issue was limited that computer and ... since it was late in the day ... was just going to reimage the box and be done with it.  I decided to check the Details tab for this particular event and noticed something rather peculular:

+ System

- Provider
[ Name] Microsoft-Windows-GroupPolicy
[ Guid] {AEA1B4FA-97D1-45F2-A64C-4D69FFFD92C9}
EventID 1058
Version 0
Level 2
Task 0
Opcode 1
Keywords 0x8000000000000000
- TimeCreated
[ SystemTime] 2013-06-27T23:33:35.377468900Z
EventRecordID 65946
- Correlation
[ ActivityID] {E6ACB131-AEEC-45A4-98D7-118272AA0081}
- Execution
[ ProcessID] 428
[ ThreadID] 3744
Channel System
Computer VAND105.mh.local
- Security
[ UserID] S-1-5-21-2823908405-3494369649-3172151183-3327

- EventData

SupportInfo1 4
SupportInfo2 816
ProcessingMode 1
ProcessingTimeInMilliseconds 16864
ErrorCode 1317
ErrorDescription The specified account does not exist.
DCName ServerName.domain.local
GPOCNName CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=domain,DC=local
FilePath \\domain.local\sysvol\domain.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini

Since I knew what stage the GPO was failing at (applying User Settings) and I knew what was able to complete successfully (applying Computer Settings) I think I figured it out ... and it was a nice easy fix:

Re-create the User Profile on the local machine!

To test I logged the other user out and logged in as myself and noticed that there were no GPO issues under that account.  Then I did the following:

  1. Restarted the PC and logged in as local administrator (you can use any account with admin rights as long as its not the affected account)
  2. Go to C:\Users\ and back up the users content.
  3. Right-Click Computer and select Properties
  4. Click Advanced System Settings
  5. On the Advanced Tab, click Settings under the User Profiles heading
  6. Click the Profile you wish to delete, then click delete
I should point out that at this step I received an error regarding the deletion of the Profile.  I had to hit Delete a 2nd time to remove it from the list, but it didn't actually delete anything ... solidifying the determination that the local user profile is at fault.  I continued on and did the following:

Deleted the profile store manaully (C:\Users\
Launched Regedit
Went to HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList

**Take care when editing the registry as you can cause major system damage if edited incorrectly, resulting in a reinstalltion of Windows.  Only proceed with working in the registry if you are comfortable

Within this key I deleted any sub-keys related to the damaged user profile.  You can discover this by clicking on each sub-key and looking at ProfileImagePath to see if it matches the username.  Also, delete any keys that reference TEMP.  After that, restarted the computer and allowed the user to log in locally ... GPO issue resolved!

Friday, April 19, 2013

Fix: Unable to make a bootable USB stick via the USB/DVD Tool or Manually

NCIX had a great sale on a while ago for some inexpensive 32GB USB 3.0 flash drives so I just had to pick up 3.  After all, I try to travel around with a full set of device drivers, various software tools for troubleshooting, and a bootable WinRE stick just in case.  Imagine my surprise when I went to create a bootable USB stick with Server 2012 when I came across this error:

"We are unable to copy your files.  Please check your USB device and the selected ISO file and try again"

I thought that I had a bad USB stick, so I moved on to the next one ... same thing ... the THIRD one ... same thing!

I left it on the side-burner for a while but today really needed to do some manual server installs.  Came across this excellent post by Devin which outlines the fix (THANKS DEVIN!)

http://www.devinonearth.com/2012/08/cant-make-a-bootable-usb-stick-for-windows-8-join-the-club/

If you don't feel like clicking through to Devin's site (its excellent btw), here are the nitty gritty steps you need to do:

  1. Connect the affected USB stick
  2. Open either CMD or PowerShell (I really need to work more in PS)
  3. Run Diskpart
  4. Type List Disk to bring up the list of current disks on your system
  5. Type Select Disk x where x = the disk number for your USB stick
  6. Type Clean to clear the configuration of that USB stick (Caution, make sure you don't have any files on there that you need as this will erase everything)
  7. Type Create Partition Primary to create a new partition
  8. Type List Disk to verify that the new partition is made.  If you see an offset of 1024KB then the fix worked
  9. Type Exit to close diskpart, then disconnect the USB stick from the system
  10. Plug it back in, it will ask if you wish to format the USB stick, say Yes or Format
You should now be able to make a bootable USB stick!

From what I can tell, this has something to do with how the USB stick was partitioned at the factory.  Maybe it was created without Windows in mind ?

Enjoy!
Terry

Friday, March 15, 2013

Fix: Scrolling in the Application Catalog

For the longest time I've been trying to figure out why, on some of my workstations, users have to scroll horizontally in order to see the Install button when they select a program.  Even when they fullscreen the browser, same issue.

At first I though it was a problem with page scaling; when someone zooms in on their browser.  In actuality I wasn't that far off!

The solution?

DPI Settings!!!

If your DPI settings are anything other than 100% then the Application Catalog will have scrollbars all around.  To change this, do the following:

Windows 7/Windows 8

  1. Right-click anywhere on the Desktop and select Screen Resolution
  2. Click Make text and other items larger or smaller
  3. Click the 100% radio button, then click Apply

You will need to log out/log in for the DPI setting change to take affect.  But, after that .. NO MORE SCROLL BARS!!  Some laptop screens will actually use 125% DPI as the default setting.

How I came across this solution has to do with an in-house application that was developed some time ago (and retired now, thank goodness).  If your DPI was set anything over 100%, you would only see part of the input screen.

Enjoy!

Tuesday, February 26, 2013

Fix: You need permission to perform this action ...

So this is frustrating.  In an earlier post I detailed how to repair WDS/PXE when it is no longer talking properly to SCCM.  Today I had to apply that fix on another of my Secondary Site Servers however I then ended up with a new problem.

I couldn't delete the RemoteInstall folder

Interestingly enough, It was asking me for permission to delete the folder.  I thought, no worries, I'll just take ownership of the folder and sub-folders then try again.  No dice, though this time it was rather amusing since it was now saying that it needed permission from me to delete the folder!

It turns out I was on the right track for resolving this, but just didn't go far enough.

So, if you get "You need permission to perform this action ..." when trying to delete a folder tree, you can try the following:

1) Open an Elevated Command Prompt (Right-click Command -> Run As Administrator)
2) Run: takeown /f path/foldername  /R /D Y
3) Run: icacls path/foldername  /grant accountName:F /t

After running these commands against the RemoteInstall I was able to delete it and continue on to rebuilding WDS/PXE for my Distribution Point.

Enjoy!