Kill Windows Processes In Windows 8

You can gracefully stop Windows processes using the Stop-Process command let. For example, to stop Chrome: Stop-Process -Name Chrome Or to stop it by ID. To locate the ID of a process, use get-process: get-process Chrome You can then use the -ID operator to stop the process: Stop-Process -ID 6969 Kill is a command that all Mac and Unix admins know. It’s similar to Stop-Process, except it’s anything but graceful. And you use the -processname option to stop a process: kill -processname calc

Deploying and Managing Google Chrome: The Rough Guide

The following is a post from the most excellent Nick McSpadden. It is very well written and I am proud that it is the first article published on this site using the new submissions page. Looks like it’s time to change the banner from my Notes from the Underground, er, I mean, Field, to just Notes from the Field!
Greetings! This is a sort of follow-up to my guide on managing Firefox, this time focusing on managing Google Chrome. I’m working on current Chrome version 18 (which just today got updated to 19), and I don’t know for sure how far back this will work, but I think anything higher than v16 properly supports the MCX policies. The good news about Google Chrome is that it supports MCX! Unlike Firefox, which requires specific and somewhat obtuse procedures for managing it (including depending upon an add-on that is independently maintained by a hard working individual), the most important parts of Chrome management can be done with already-existing MCX controls. First let me start off with a link to a very helpful set of information: That link covers just about everything you’ll need to know about Chrome policies and management, though some of it is buried. I discovered (much to my chagrin) that the Chromium site is much more thoroughly documented that Google’s official “Chrome for Administrators” site. Some important notes about Chrome MCX: all Chrome policies are required to be set to “Always.” They’re like Profiles from Profile Managers – there’s no middle ground. Even if you set it to “Once” or “Often,” Chrome will treat the policy as permanent and prevent the user from changing it. Any policy being managed by MCX in Chrome will be grayed out to user interaction (and there will be a message in the “Options” window about how some settings are being managed by the administrator). So you’re going to have to “Always” manage these settings whether you like it or not. The good news is, there’s an alternative, the Master Preferences. The downside is that the Master Preferences is a “once” option, and doesn’t prevent the user from changing it. It’s a good way to provide default settings without restricting the users’ ability to personalize it later on. More on that later. So, following the Mac Quick Start Guide: ( 1. Inside a fresh copy of Google Chrome is a nice fresh copy of the manifest. Access it here: /Applications/Google 2. Load this manifest into WGM 3. Here’s the full description of all policies in the Chrome manifest: 4. There are some particularly important settings that will be relevant to most. Here’s what my plist looks like for a lab computer (no individual users):
  • AutoFillEnabled – False (disables the ability to store autofill information)
  • BookmarkBarEnabled – True (forces the bookmark bar to show up on all tabs, all the time)
  • HideWebStorePromo – True (prevents the web store from trying to sell you things, but does not disable the web store)
  • HomePageIsNewTabPage – False (if you don’t disable this, the homepage will be set to the default Chrome tab page, which opens up the “Most Visited/Apps” switcher)
  • HomepageLocation – URL (even if you set this, if HomePageIsNewTabPage is set to true, this URL gets ignored)
  • PasswordManagerEnabled – False (for lab machines, I don’t want them saving passwords, intentionally or accidentally)
  • RestoreOnStartup – 0 (0 forces it to open the homepage URL on startup)
  • SyncDisabled – True (same reason as Password Manager – I don’t want these personalized at any time).
That gives you a basic setup for most things you’ll need to worry about. If you deploy this, you’ll notice a few problems, though. The first time you launch Chrome, it gives you an undismissable dialogue box asking you if you want to make Chrome the default or submit other info. That’s bad. The above manifest also provides no way to control the auto update mechanism, if that’s something you want to do. This is where the Master Preferences file comes in – By specifying a Master Preferences file, we can load up default preferences for user accounts *when they are created.* Note that the Master Preferences file has absolutely no effect on already existing Chrome profiles – only upon new-user generation does Chrome load this file. It literally copies and pastes the settings in here into the appropriate places in ~/Library/Application Support/Google/Chrome/Default/Preferences. On Mac OS X, the Master Preferences file must be located at: /Library/Google/Google Chrome Master Preferences (yes, really – the file must be named “Google Chrome Master Preferences” with no extension), and must obviously be readable by any user who can launch Chrome (i.e. use 644 permissions). The Master Preferences file is a JSON file that can contain any of the preferences normally used by Chrome. If you want the full list of all possible preferences, load up a default Chrome profile and take a look at the Preferences file I mentioned at the path above. It has everything you’d ever want (and a lot of stuff you probably don’t). To save you some time, here are some important ones you’ll want to use specifically for deploying Chrome: { "homepage_is_newtabpage" : false, "browser" : { "show_home_button" : true, "check_default_browser" : false }, "bookmark_bar" : { "show_on_all_tabs" : true }, "distribution" : { "skip_first_run_ui" : true, "show_welcome_page" : false, "import_bookmarks" : false, "import_bookmarks_from_file" : "/Library/Google/chrome_bookmarks.html", "make_chrome_default" : false }, "sync_promo" : { "user_skipped" : true } } The page I linked above goes into a bit more detail about this, but I want to give a quick note about the interaction between preferences and MCX. MCX always wins. Any policy managed by the MCX and also specified in the Master Prefs will always go the MCX policy. In the example above, if I had set “homepage_is_newtabpage” to true, it would still be false because MCX sets it to false, and that policy is always enforced. The really import part is the “distribution” section. “skip_first_run_ui” will get rid of that annoying dialog box that comes up when you first launch Chrome. The “import_bookmarks” option asks the user through a UI dialog box if the user wishes to import bookmarks from another browser. Obviously, we want to suppress that. There’s an option instead to silently import bookmarks from an HTML file. You can create this bookmarks HTML file by setting up the bookmarks the way you want, and then Exporting them in the Bookmark Manager. I place that bookmarks file in /Library/Google/ because it’s already used, but you can put it anywhere. There is, however, a known bug that has now been assigned a milestone and a solver in Chromium’s bug list – the “import_bookmarks_from_file” is actually ignored if the “skip_first_run_ui” is set to true. So right now, you can’t silently import your bookmarks in. The “sync_promo” item doesn’t seem to be necessary if you disable Sync in the MCX settings above, but since MCX policy always wins over Master Prefs, there’s no penalty or downside to including it. Note that your JSON syntax has to be perfect for this to work. Any incorrect comma placements, and it simply ignores your master prefs file. If you find that your Master Prefs isn’t loading up as expected, run Chrome from the Terminal with the debug log turned on to see what’s happening: /Applications/Google Chrome –enable-logging –v=1 This places a file called “chrome_debug.log” in ~/Library/Application Support/Google/Chrome/Default/ (i.e. default user data directory). The first line will tell you exactly what went wrong with your Master Prefs file. Now, there’s still one more problem here: new tabs open up to the default Chrome “New Apps / Most Visited” switcher page (called the newtab page). Unfortunately for us, there’s no way to change this behavior present in the UI. The good news is, this behavior annoys plenty of other users, and there are a million extensions you can use to get rid of it. More good news, is that you can silently include extensions in your MCX manifest! So simply add this to your MCX settings above (forgive the pseudo XML here, just to indicate type of key): <array> <string>lcncmkcnkcdbbanbjakcencbaoegdjlp;</string> </array> This silently forces the install of an extension called “Empty New Tab Page,” and specifies an update URL for it (required, since Chrome autoupdates its extensions too if they come from the Chrome Web Store / Extensions pages). The extension does what you think it does – you get a blank page. There are other extensions for customizing the new tab pages, or anything else, so as long as you get the extension ID (it’s the long block of letters in the beginning), you can load whatever you want in here. There you go! I’ve tested this using Local MCX on my 10.6 and 10.7 machines, and it works perfectly (deployed through Munki as well). On the whole, Chrome is a bit easier to manage and deploy than Firefox, just because it doesn’t require modifying the app itself to do this. Also, the Master Preferences file works for any instance of Google Chrome – even if the users install a copy somewhere other than /Applications. This also does work for Chromium, the open-source version of Chrome. Hope this helps someone.

Customizing Chrome for Mac

Yesterday I mentioned that Google Chrome is now available for Mac OS X. You can customize the screen that Google Chrome uses for Mac OS X. To do so, open the Here, you’ll see a list of the available themes that you can use. Before Select a theme, and then, once selected, click on the Apply theme button below the theme. Viola, you now have a sexy new interface for Chrome! after_chrome

Safari 4 Beta

The Safari 4 beta has been posted on Apple for awhile and there are people talking about it on the interwebs.  So my turn.  But rather than wax poetically about browser wars, which seems to be what everyone else is doing, I’ll constrain the conversation to the Safari 4 beta, which you can download from here. If you haven’t moved into tabbed browsing yet, then after you install the upgrade you’re likely not going to notice much of a change. When you open Safari it will look a little like it always looked, with some minor enhancements to the GUI – notably the little picture of a bug in the upper right hand corner. This won’t be there when it’s a full release, it’s there to simply do what Apple wants you to do if you find a bug, report it. If you want to remove the item, right-click on it (control-click if you aren’t into the whole 2+ button mouse thing) and click Remove Item. To get it back you can right-click on the toolbar later and readd. Now press Command-T to get a new tab. Woo-hoo, it’s on the top. I actually really like this feature as it gives me an extra line or two with websites I’m reading. The next thing you’ll notice about your new tab is that shiny tiled view of your 12 most favoritest sites. This should be pulled from your history. You can use the Edit button here to tell it to keep certain sites or remove them, in which case Safari will go ahead and replace it with the next most commonly visited item in your History. While in Edit mode, you can also use the Small, Medium, Large buttons to set the view to show 6, 12 and 24 panels respectively. But what about History. Well, click on the History menu bar and then click on Show All History. You will be greeted with the sexy cover flow look that is becoming common in Apple products. Now click up in your search bar and type a letter. You’ll notice quickly that Suggestions and Recent Searches pops up pretty quickly. The smart search is pretty smart (although with a little plug-in whatnot you already had that in 3). There’s also the Web Inspector, the only part of the browser I’m still not sold on. It offers a nice interface for editing Java, HTML, CSS, etc. It can cache databases and do all kinds of other wacky things. Why am I not sold on it? To be honest, I just started playing with it. It’s not in your menu items by default. To see it, go to the Safari Preferences, click on the Advanced tab and then click on the Show Develop Menu in menu bar. Now that you can see the menu item, click on the Show Web Inspector item. Here, you can access and browse through Resources (that’s where you’ll find most of the stuff at first btw). Overall, this is similar to the editor used to build Dashboard widgets. There are better development tools out there (far better), but they’re not bundled into a browser and to be honest, they don’t look nearly as cool… Finally, the big one: Speed. I don’t have any metrics for this, still trying to decide how I would go about that. But, Safari 4 is faster than any other browser I’ve used. That’s not to say it seems faster. Without the status bar to show me it’s loading a page it actually seems a bit slower at first. But when you fire up another computer right by yours and test it out it’s remarkably faster… Especially for JavaScript (likely due to that whole Nitro engine thing).