Monthly Archives: March 2013

Windows Update Changes Colors In Revit

We just pushed out a whole group of windows updates to our office only to find out that one changes the color of items in Revit. Which happens to be our primary application. Users were less then happy and quick to notify me, especially because we had a presentation that morning to a client.Screenshot 3:8:13 10:51 AM

Screenshot 3:8:13 10:50 AM

Seems to be tied to windows update KN2670838. After uninstalling it on one machine and restarting the colors returned to normal. So we simply marked the update to uninstall for users.

Screenshot 3:8:13 10:47 AM

Can Not Rename Folders On C: Drive

I’ve had this strange issues with both Windows 7 and Windows Server 2008 R2. If I try to create a folder in any directory under C:, I get the error:

“Could not find this item. This is no longer located in C:\(path to where ever I was trying to create/rename folder). Verify the item’s location and try again”

could-not-find-this-item

If I select “Try again” it does actually rename the folder but it’s differently a nuisance and a bit annoying. I’ve searched google looking for a answer. Which seems to be the result of a windows update, which update is up for debate though.

So this has worked for me on both Windows 7 and Windows Server 2008 R2. I recommend backing up the registry first. After deleting the below registry keys. Log off and then back on, the issue for me was instantly gone.

Delete these registry keys:

[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\FolderDescriptions\\{2112AB0A-C86A-4ffe-A368-0DE96E47012E}]

[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\FolderDescriptions\\{2112AB0A-C86A-4ffe-A368-0DE96E47012E}\\PropertyBag] [

HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\FolderDescriptions\\{491E922F-5643-4af4-A7EB-4E7A138D8174}]

[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\FolderDescriptions\\{491E922F-5643-4af4-A7EB-4E7A138D8174}\\PropertyBag]

[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\FolderDescriptions\\{7b0db17d-9cd2-4a93-9733-46cc89022e7c}]

[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\FolderDescriptions\\{7b0db17d-9cd2-4a93-9733-46cc89022e7c}\\PropertyBag]

[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\FolderDescriptions\\{A302545D-DEFF-464b-ABE8-61C8648D939B}]

[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\FolderDescriptions\\{A302545D-DEFF-464b-ABE8-61C8648D939B}\\PropertyBag]

[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\FolderDescriptions\\{A990AE9F-A03B-4e80-94BC-9912D7504104}]

[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\FolderDescriptions\\{A990AE9F-A03B-4e80-94BC-9912D7504104}\\PropertyBag]

Migrating Jobs In Crashplan PROe

I’m in the middle of setting up a new Crashplan PROe server. My old setup included a powerpc Mac running 10.4 and five external drives. Long story short, that setup didn’t work. I’m as updated as I can get with Crashplan because I can’t upgrade the Java any more on the powerpc Mac. I have several bugs/issues with the Crashplan web ui that can not be resolved unless I upgrade and the external drives occasionally don’t mount on restarts … all of which requires me to spend more time then I want administrating backups.

My new setup is a  HP DL380 G8 with 18TB of internal storage. More more worrying about drives not mounting and I will be able to update to the latest version of Crashplan.

My first task though is migrating all those backup archives off the external drives and onto my HP internal Drive. This is a fairly easy process in the web ui. You log in select “Devices”, select the client name, and from the action menu to the right of the job (the folder/arrow icon) select “Migrate Archive.

cp_migrate-01

This works great for same backup jobs. They migrate over pretty quickly. But for very large backups, like my 3TB’s it’s a pain because there is no progress bar to show if the job is actually migrating over, and nothing writing to the log files.This was a feature in 3.8.2010 Why did Crashplan remove this feature? For administrators, we want to know everything going on about our machines.

That got me to looking at the destination folder on my HP server. Once you turn on hidden folders you’ll see a folder named “.balance.moveguidtomount-109”. Instead I find a folder with the same GUID as the job I was migrating over. If you watch the folder size it slowly gets larger leading me to believe the job is migrating over, just very slowly.

cp_migrate-02

cp_migrate-03

The frustration comes from not being able to find this information anywhere in the web ui. And when I opened a ticket I didn’t get a response for 5 days, and when Crashplan responded, they said “Is this still a problem?” REALLY! that’s how you support paying customers. So I replied back and still have not heard back on the officially ticket. Why do I as the customer have to go snooping around hidden folders to find a piece of simple information.

Why not add a progression bar, verbose log out out, or even a simple ETA on migrated jobs ….. “Migration will be done 28 hours”. That why admins came be assured  action is happening.

Installing Munki On A Mountain Lion Server

munki11-surpised-wandering_eye

These are my “cleaned up” & “streamlined” instructions for how to get munki installed on a Mountain Lion Server, for the definitive instructions you should go to the wiki page here or check out the project home page. These guys are doing awesome things with munki.

You don’t have to install munki on a Mac server, I just happen to have it installed on my Deploy Studio server as an extra tool to help me manage and image clients. Ideally you can push out a thin image to new clients with Deploy Studio, boot into that image that is already configured with munki. Run the Managed Software Updates and download the remaining apps to finish the build out.

 Step1: Building a server repository

We need to setup some folders to keep our config files and actually software for munki. Copy and paste these commands into terminal.

 cd /Users/Shared/
 mkdir munki_repo
 mkdir munki_repo/catalogs
 mkdir munki_repo/manifests
 mkdir munki_repo/pkgs
 mkdir munki_repo/pkgsinfo
munki-01

Step1: Building a server repository

_ _ _ _ _

Step 2: Changing Permissions on Directory

Run this command at the command line, For the specifics of what it does you can run “man chmod”. Basically you want to make sure Apache has the right permissions for this folder.

 chmod -vLR a+rX munki_repo
munki-02

Step 2: Changing Permissions on Directory

_ _ _ _ _

Step 3: Redirect Apache2 to serve the munki_repo directory via HTTP

Direct Apache to the right folder in order to display your repo over http.

sudo ln -s /Users/Shared/munki_repo /Library/Server/Web/Data/Sites/Default

_ _ _ _ _

Step 4: Turn on Web Sharing in the Sharing preferences pane

– open server.app
– turn websites on
– select server websites, click edit button (pencil tool)
– elect edit advanced settings, click ‘allow folder listings’

munki-04

Step 4: Turn on Web Sharing in the Sharing preferences pane

_ _ _ _ _

Step 5: Install munki tools

Download and install the munki tools … YOU WILL HAVE TO RESTART IMMEDIATELY.

http://code.google.com/p/munki/downloads/list

Optional: Adding /usr/local/munki to bash search path

– this step simply adds the path to the bash search path so you don’t have to add the path with every terminal command. For example if you do this step you only need to run: munkiimport –configure instead of /usr/local/munki/ munkiimport –configure

PATH=$PATH\:/usr/local/munki ; export PATH

_ _ _ _ _

Step 6: Configure munki import

Here’s where it starts to get good. We need to set up munki first with some basic information like where we want the folders to be where we are going to put software.

Type this at the command line:

usr/local/munki/munkiimport --configure 

or just

munkiimport - -configure

if you add it to the search path in step 5. From here I”ll only list the actually command and not the usr/local/munki

You should see this:

Path to munki repo [None]: /Users/Shared/munki_repo
Repo fileshare URL [None]: <just hit return>
pkginfo extension [None]: <just hit return>
pkginfo editor [None]: TextEdit.app <substitute your favorite text editor>

_ _ _ _ _

Step 7: Import first app into munki

Time to import something. I downloaded Firefox. Run the munkiimport command and then just drag the Firefox dmg on to the terminal window. It will automatically add the path.

munkiimport ~/Downloads/Firefox\ 18.0.1.dmg

You should then see a list of information after just a few seconds. Just follow the prompts. Don’t worry if you get it wrong, this is just a test, you should do this several times to feel comfortable. My responses are in red.

Item name [Firefox]: FIrefox
Display name []: FIrefox
Description []: web browser
Version [18.0.2]: <just hit return>
Catalogs [testing]:test (you can put in whatever you want to name your catalog)

Item name: Firefox
Display name: Mozilla Firefox
Description: Web browser from Mozilla
Version: 18.0.1
Catalogs: test

Import this item? [y/n] y
Upload item to subdirectory path []: <just hit return> (you could say apps/web_browsers if you wanted to create folders and organize your software)
Copying Firefox 18.0.2.dmg to /Users/Shared/munki_repo/pkgs/Firefox 18.0.2.dmg…
Saving pkginfo to /Users/Shared/munki_repo/pkgsinfo/Firefox-18.0.2…

Rebuild catalogs?[y/n]y
Rebuilding catalogs at /Users/Shared/munki_repo ….

After wards you can go to the munki_repo/pkgs folder and see that munki did actually copy the Firefox installer to the right folder.

munki-09

Step 7: Import first app into munki

_ _ _ _ _

Step 8: Creating a client manifest

The manifest is just the file that tells munki what software to offer. So now that we have Firefox in our repo we need to tell munki to offer it to our clients. First I need to create a manifest

run this command:

manifestutil

(again, my responses are in red, for a list of commands with manifestutil type help)

Entering interactive mode… (type “help” for commands)
> new-manifest test_munki
> add-catalog test –manifest test_munki
Added test to catalogs of manifest test_munki

add-pkg Firefox –manifest test_munki
Added Firefox to section managed_installs of manifest test_munki
> exit

munki-10

_ _ _ _ _

Step 9: Munki Client Configuration

In order for clients to see the munki server you need to install the munki tools on each client. Go here and download the munki tools and install them. This will install the Managed Software Updates app in the clients utility folder.

Now we need to tell ManagedInstalls where to find munki. Type this command.

sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL "http://localhost/munki_repo"

This is just a test so I am using “http://localhost/munki_repo” , but if I really installed this on a different client I would have to change localhost to the IP of the Munki Server

sudo defaults write /Library/Preferences/ManagedInstalls ClientIdentifier "test"

“test” would be the name of your catalog you created.

To check your settings run this:

defaults read /Library/Preferences/ManagedInstalls

_ _ _ _ _

Step 10: Managed Software update

Now the moment of truth. Go to the Utility folder and double click Managed Software Updates. If everything was successful You should see the below.

munki-12