July 2006

You are currently browsing the monthly archive for July 2006.

Listing Services Running as a User Account

Monday, July 17, 2006 in Microsoft by slowe | 4 comments

You might want to identify services running as a user account for any number of reasons, including any of the following:

  • You are preparing for a migration and need to know what services and/or what computers will be affected when you migrate a particular user account.
  • The password for a particular service account needs to be changed, and you need to know which computers will be affected by that change.
  • You want to check to make sure that there aren’t services running as user accounts out there that you didn’t know about.

I’m sure that you can think of more reasons, but that’s enough for now.  To accomplish this feat, we’re going to reach once more into the toolkit of WMIC, this time using the “wmic service” alias to query the service status and configuration of remote systems.

Our base WMIC command is something like this:

wmic service get Caption,StartName

This command lists all services, with the caption (friendly name) and security context (local system, local service, network service, or user account).  That’s all well and good, but we only need those services that are running as user accounts.  To do that, we’ll modify the command to look like this:

wmic service where (StartName!=“LocalSystem” and
StartName!=“NT AUTHORITY\LocalService” and
StartName!=“NT AUTHORITY\NetworkService”)
get Caption,StartName

Now the results include only those services running as user accounts, or (if none match), the message “No instances available.”  Note the double backslashes when checking for services running as LocalService or NetworkService; these are necessary on the command line.

Reusing the “for /f” trick shown here, we can build a more complex command to do the same thing for all computers in an OU:

for /f “tokens=1” %1 in ('dsquery computer
“ou=Workstations,dc=example,dc=net” -o rdn -limit 0') do
@wmic /node:%1 /failfast:on service where (StartName!=“LocalSystem”
and StartName!=“NT AUTHORITY\LocalService” and
StartName!=“NT AUTHORITY\NetworkService”)
get Caption,StartName > c:\temp\svc-list-%1.txt

This command will create a list of files, one for each computer returned by the query, each of which contains a list of services running as user accounts.  One new technique shown here is the creation of a text files that have the computer names returned from the Active Directory query embedded in the filename.  Note that we’ve also incorporated the “/failfast:on” switch, to avoid delays due to computers that are turned off, out of the office, or otherwise unreachable.

With these text files, you then have the information you need to know what computers and/or services will be affected by password or account changes, and you can stay on top of new services being added to the network without your knowledge.

UPDATE:  This weblog entry shows another way to get this information, this time without using WMIC (this may be useful for dealing with older computers that may not support WMIC).

Tags: , ,

Trying Quicksilver

Sunday, July 16, 2006 in Macintosh by slowe

This makes the third or fourth time I’ve tried to get into using Quicksilver.  I’m OK with the whole pop-up bezel interface, since that’s the interface that VirtueDesktops, my virtual desktop application, uses.  (The author of VirtueDesktops freely admits that he was inspired to create his interface based on Quicksilver’s interface.)  Don’t get me wrong—Quicksilver (just “QS” from now on) is a great application, and it has loads of very useful functionality.

For example, here are a couple of the things that I love about QS:

  • With QS, you can access Address Book information without having to launch Address Book.  You can type a few characters of a contact’s name and there it is, and there are actions accompanying it that allow you to send an e-mail to that contact.  You can’t do that with Spotlight.
  • QS is extensible, allowing you to attach user-written AppleScripts to add functionality to the application.  In addition, QS supports an system of plug-ins to add features or to add new interfaces, such as their Flashlight interface (based on the Spotlight interface).
  • The bezel interface is pretty cool.

Somehow, though, even given the nifty and pretty handy things that you can do with QS, I just can’t get with it.  I can’t integrate it into my workflow.  I can’t get into the handy of invoking QS to do what I’m trying to do.  I suppose I need to give it much more time than I am giving it; I’ve heard it said that you need to give it a week or more of using it before you get used to it.

Any QS users out there?  If you’ve got any tips on getting “used” to QS, on how to integrate QS into your workflow and your modes of operation, I’d really appreciate it.  I believe that QS could be a powerful tool to help make me more productive, but I’m just having a really hard time getting the hang of it.

Tags: ,

Tags, RSS, and Other Site Changes

Saturday, July 15, 2006 in General by slowe

I’ve been wrestling with Technorati not indexing my weblog for quite a while now.  It appears that ever since I added Ultimate Tag Warrior to my weblog and moved the tags into the keywords portion of the weblog (instead of the posting body), Technorati stopped indexing the site.  It appears that the tags aren’t being added to the RSS and Atom feeds in the content, and therefore Technorati won’t properly index the site.

I could go back to putting the tags in the body of the posting, but I really don’t feel like it, and I like having them in the keywords portion of the posting.  Since the Technorati links weren’t returning any posts on my weblog, I’ve just removed the Technorati search links on the category and tag pages.  Perhaps that’s childish, or selfish, or whatever, but the links just don’t seem useful any more.

In addition, I’ve added links to search del.icio.us for related bookmarks when browsing the category pages, and I’ve added a link for subscribing to a category’s RSS feed.  Visitors now use the exact same links for both tags and categories to find related bookmarks and subscribe to the RSS feed.

Just for easy reference, each category’s RSS feed is available at the following URL:

http://blog.scottlowe.org/<category name>/feed

In addition, each tag’s RSS feed is available at the following URL:

http://blog.scottlowe.org/<tag name>/feed

By default, these URLs will return an RSS 2.0 feed.  To access an RSS 0.92 feed, add “/rss” to the end of each of these URLs.  There is no Atom feed for categories and tags just yet.  There is an Atom 1.0 feed for the overall weblog, though.

Since each category’s RSS feed is available from the category page, I’ve removed the links to the RSS feeds in the sidebar.

UPDATE:  I also added the plugin Tags in the Head to add tags as meta keywords in the header of each page.  This is a pretty handy plugin that also ties in nicely with Ultimate Tag Warrior.

Tags: , , , ,

Resetting DNS and WINS on DHCP Clients

Friday, July 14, 2006 in Microsoft by slowe | 1 comment

As you probably know, Windows-based systems can be DHCP clients (and obtain their IP address, subnet mask, and gateway from DHCP) but use hard-coded DNS servers or WINS servers.  Right off the top of my head, I can’t really think of any reasons why this is useful, or when it may be necessary, but the point remains that it is possible, and invariably this situation crops up during standardization or migration projects.  The problem with this situation is that changes made to the DHCP server (such as handing out new DNS server or new WINS server addresses) won’t be properly reflected on those workstations that have hard-coded values for these configuration settings.

So, we need to find a way to reset these DHCP clients to revert back to DHCP for these values instead of using the hard-coded entries.

Resetting the DNS server search order on a DHCP client to use the DNS servers passed down via DHCP is pretty easy.  In this sitaution, we’ll modify the technique described earlier to remotely set DNS and WINS server addresses.  However, instead of setting a specific DNS server, we’ll essentially set the value to nothing:

wmic nicconfig where (IPEnabled=TRUE and DHCPEnabled=TRUE)
call SetDNSServerSearchOrder ()

As described in earlier posts, this command uses WMIC to set an empty DNS server search order for all NICs that are both IP-enabled and DHCP-enabled.`  As with all other WMIC examples that have been presented here, this command is remotely executable (using the “/node:<PC name>” switch), and it can be made to work with multiple machines using either the “/node:@<filename>” syntax or using “for /f” to pipe results into the /node switch.  All of these examples have been demonstrated already, so we won’t delve into them again here.  Refer to back to any of these articles for more information:

All of these articles discuss the use of WMIC and provide examples of how to execute the WMIC commands against multiple remote systems.

Resetting the WINS servers remotely, however, is a very different story.  In this case, the WMIC command for setting the WINS servers won’t allow you to specify an empty value, or any other value that does not appear to be a valid IP address.  In addition, as mentioned when discussing how to remotely set the DNS and WINS server addresses, the WMIC command always wants both the primary and secondary WINS server addresses; it does not appear to be possible to set only one or the other.

Netsh (network shell, available in Windows 2000, Windows XP, and Windows Server 2003), on the other hand, does provide a way to set both the DNS servers and the WINS servers back to DHCP-supplied via a command line, and netsh does offer a remote option (-r), as well as the ability to supply alternate credentials (via the -u and -p switches to provide username and password, respectively).  It would seem like that’s exactly the tool to use, and it is—sort of.

The problem with Netsh when being used remotely, however, is that it won’t allow changes to DNS or WINS servers.  Specifically, the command that would be used to reset WINS servers to DHCP is this one:

netsh interface ip set wins
name=“Local Area Connection” source=dhcp

(Be sure to type this all on a single line.)  This works just fine when executed locally (tested on both Windows Server 2003 and Windows XP), but refuses to work when executed remotely using the “-r” switch.

The trick here, then, is to find a way to spawn this command on a remote system so that it is executed locally, i.e., to be able to issue a command on a central server that reaches out to a workstation and spawns this command as a local process.  That’s where WMIC comes back into the picture.

This WMIC command will spawn a process remotely:

wmic /node:pc01 process call create “cmd.exe”

Using some switches for the Windows command shell (cmd.exe), we can build a command to launch cmd.exe and then issue the netsh command we need.  This is the final result:

wmic /node:<PC name> process call create
'cmd.exe /c “netsh interface ip set wins name=”Local Area Connection“
source=dhcp”'

Pay close attention to the quotes—those are single quotes around the entire command line, then double quotes around the Netsh command and the name of the network adapter.  As it turns out, the default behavior of cmd.exe is to strip off the first double quote (in this case, the one just before netsh) and the last double quote (just after the source=dhcp parameter) and leave the remaining.  The single quotes are used to bind the entire command line together, so that when it is parsed first by cmd.exe on the local system where the command is being typed it will work correctly.  I tried several different combinations of single and double quotes and this worked; you may be able to find other combinations (if so, please let me know by posting a comment to this article).

By extension, of course, you could also use the same technique to reset the DNS servers:

wmic /node:<PC name> process call create
'cmd.exe /c “netsh interface ip set dns name=”Local Area Connection“
source=dhcp”'

It should go without saying, but I’ll say it anyway:  we can easily modify this command to act upon multiple remote computers by using an input file or by piping command results to this command.  Refer to any of the linked articles above for more information and examples.

UPDATE:  It has come to my attention that you could also use the PsExec tool, from SysInternals, to replace the “wmic process call create” command.  This should achieve the same effect, but I haven’t yet had the time to check that myself and fully document the command line.

Tags: , ,

Remotely Enabling Remote Desktop

Thursday, July 13, 2006 in Microsoft by slowe | 8 comments

Other than exploring a new WMIC alias here, you won’t see any startling new tricks or techniques here.  We’ll be reusing tools that are already well-worn but still useful.

In Windows Server 2003, Microsoft added the RDTOGGLE WMIC alias.  In Windows XP, you had to use the Win32_TerminalServiceSetting path.  In either case, this alias or path allows you to toggle the value of the Remote Desktop setting.  The syntax is a bit wierd, if you ask me, but this is how it looks (the lines are wrapped here for readability, but be sure to type it all on one line):

wmic rdtoggle where AllowTSConnections=“0”
call SetAllowTSConnections “1”

Of course, this being WMIC, we can easily add the “remote” functionality to this command with a simple switch:

wmic /node:remotepc1 rdtoggle where AllowTSConnections=“0”
call SetAllowTSConnections “1”

If you’re running this command from a Windows Server 2003-based computer, you can use the RDTOGGLE alias even when executing the command remotely against a Windows XP-based system.  In the event you need to run this on Windows XP, use this command instead:

wmic /node:remotepc1 path Win32_TerminalServiceSetting
where AllowTSConnections=“0” call SetAllowTSConnections “1”

Note that this syntax (using the path instead of the alias) works equally well on either Windows Server 2003 or Windows XP.

We can automate this process by combining this command with “for /f” to either a) perform this command on a predetermined list of computers whose names are stored in a file, like this technique for adding entries to a WINS server; or b) embed a command, such as a Dsquery command, that will dynamically return a list of computers on which the command will be performed.  We demonstrated this idea in remotely setting the DNS suffix search order.  Refer back to these articles and other recent articles for more examples of using “for /f” to script command-line utilities that don’t normally accept piped input.

Putting all this into practice, it now becomes possible to use Dsquery to return a list of all the computers in an OU, and for each computer in the OU that does not have Remote Desktop enabled we can enable it.  Pretty handy, eh?

UPDATE:  It appears that a simple Registry change may also have the same result, although the jury is out on whether a reboot is required for the change to take effect.  Preliminary testing with a Windows XP-based system that already had Remote Desktop enabled showed that changing the Registry value was immediate; however, I still need to test this on a system that has never had Remote Desktop enabled previously.  (Update:  See new information below!)

The Registry key to change is:

HKLM\System\CurrentControlSet\Control\Terminal Server

A REG_DWORD value named fDenyTsConnection controls Remote Desktop; a value of 1 means that connections are denied (thus, Remote Desktop is disabled); a value of 0 means that connections are not denied (thus, Remote Desktop is enabled).

Credit to Daniel Petri for this information (there were lots of sites with this information, but his was first in the Google search).

UPDATE 2:  I had the opportunity to test the Registry change on computers that did not have Remote Desktop enabled previously.  Changing the referenced Registry key immediately enables Remote Desktop; no reboot is required.

Tags: ,

iSCSI and ESX Server 3

Monday, July 10, 2006 in Interoperability, Storage by slowe | 13 comments

A few weeks ago I wrote about trying to use NetApp’s ONTAP Simulator as a VM under ESX Server so that I could do some testing with the new NAS and iSCSI functionality in ESX Server 3.0.  I finally got that working, but later had to shut it down when I started working with ESX Server 3.  As it turns out, the ProLiant 6400R servers I was using for my VMware lab (running ESX 2.5.x) were not supported for the final release of ESX 3 because the cpqarray.o driver was dropped from the final release, and the cpqarray.o driver is what supported the Smart Array 3200 and Smart Array 4250 RAID controllers in these two boxes.  No ESX 3 on these boxes.

Thankfully, I was able to locate an unused ProLiant ML350 G4p on which I could run ESX Server 3.  Instead of trying to use the ONTAP Simulator as a VM, then, I rebuilt one of the 6400R servers with Red Hat Linux 9.0 and installed the NetApp ONTAP Simulator directly from there.  After a fair amount of work, I finally had everything setup, and the simulated Filer was running with about 20GB of available storage to serve up via iSCSI, CIFS, NFS, or HTTP.

iSCSI was what I was really interested in, so the available storage from the ONTAP Simulator got carved into a couple of LUNS to be presented via iSCSI, along with the requisite initiator groups.  Once everything looked to be in place on the Simulator, I moved to the configuration of ESX Server.  Had I been lucky, I might have been trying to do this after Mike Laverick released his Service Console Guide, but I was a few days too early, and used the VI Client GUI instead to configure the VM Kernel NIC and the software iSCSI client.  The configuration looked correct, but there was no connectivity.

Not sure if the problem was ESX Server or the ONTAP Simulator, I mapped another LUN and created another initiator group and tested iSCSI connectivity from a Windows Server 2003 VM using Microsoft’s iSCSI initiator.  That worked perfectly—not even the first problem.  Clearly, the problem was not with the ONTAP Simulator, but with ESX Server instead.

Reviewing the configuration, I did find a couple of problems:

  • The iSCSI node name I had specified in the igroup configuration on the Simulator was incorrect, so I fixed that.  (Or thought I had; more on that in a moment.)
  • The iSCSI security configuration was incorrect, so I fixed that as well.

ESX Server should see the storage now, but there was still no connectivity.  Finally, I came across a blurb somewhere about the new firewall in ESX Server 3.0, and how it controlled not only inbound traffic, but also outbound traffic.  A quick trip to the service console and this command:

esxcfg-firewall -e swISCSIClient

You would expect that using the VI Client to enable the software iSCSI client would also enable outbound iSCSI traffic support on the ESX firewall, but it didn’t.  As soon as I entered that command, the Simulator’s console (where I was logged in) started showing iSCSI connection requests.  This, in turn, revealed another problem—ESX Server insisted on using its own iSCSI node name instead of the node name I had assigned.  That was easily and quickly corrected, and I was finally able to mount the iSCSI LUN and create a VMFS datastore.

Key points to remember:

  • Apparently, the iSCSI node name you specify in configuring ESX Server will be ignored, so don’t bother.  Just use whatever ESX is already configured with.
  • Be sure to either configure iSCSI from the command line (where outbound iSCSI traffic is allowed through the firewall automatically) or go back and allow outbound iSCSI traffic through the ESX firewall.

Having iSCSI-based storage eliminates one potential block to testing and demonstrating VMotion to customers—shared storage—but now I need to work on getting Gigabit Ethernet into the test lab as well.  Too bad there’s not a software workaround for that, too…

UPDATE:  I corrected the command-line above to reflect that the first “I” should be uppercase, not lowercase as was previously noted.  Thanks to Chauncey for catching the error!

Tags: , , , , , , , , , , ,

Setting DNS and WINS Server Addresses Remotely

Friday, July 7, 2006 in Microsoft by slowe

As a follow-up to yesterday’s posting about using WMIC to set the DNS suffix search order remotely, here’s additional information on using WMIC to remotely set the DNS server and WINS server addresses.  This technique can be particularly useful for servers, where the IP addresses are statically assigned (as opposed to configured via DHCP).

WARNING:  There are some limitations to this technique, so don’t unleash it on your network without first taking the time to understand what it is doing and what the effects will be.  Don’t come crying to me if you mass configure all your servers and your network breaks—you’ve been warned.

The trick to this technique is understanding that WMIC has to work on a specific NIC instance in order to make this change.  The DNS suffix search order, on the other hand, does not need to be applied to a specific NIC instance.

This command assumes that all IP-enabled, statically assigned interfaces should have their DNS and/or WINS server addresses changed.  In this case, we’re leveraging the power of WMIC’s SQL-like “WHERE” clause to limit our activity to only specific NIC instances.

Here’s the command to set the WINS server addresses:

wmic nicconfig where (IPEnabled=TRUE and DHCPEnabled=FALSE)
call SetWINSServer “192.168.254.100”,“192.168.254.101”

To perform this command remotely, add the “/node:<PC name>” switch (this goes before nicconfig).  To specify alternate user credentials, add “/user:<Username>” and “/password:<Password>” switches (again, before nicconfig).  Note the “WHERE” clause that limits the action to only those NICs that are IP-enabled and not using DHCP.

Here’s the command to set the DNS server addresses:

wmic nicconfig where (IPEnabled=TRUE and DHCPEnabled=FALSE)
call SetDNSServerSearchOrder (“192.168.254.101”,“192.168.254.100”)

The syntax is slightly different here for DNS servers than above for WINS server, so don’t get tripped up.  Same things apply again for working against a remote node or for specifying alternate user credentials.

Refer back to the entry on setting the DNS suffix search order for techniques on how to provide WMIC with a list of computers to act against (either embedding in a “for /f” command or using the “/node:@filename” trick).  Using either of these techniques would let you apply these changes to a number of computers all at once.

WARNING:  It should go without saying that setting either or both of these configuration values can, if done incorrectly, have a negative impact on the operation of your network.  Specifically, it may not work at all.  Exercise caution and make sure you know exactly which computers are going to be affected by this command.  For this reason I would recommend against using the output of a Dsquery command with this WMIC command.

There are some important things to note about this command:

  • First, the command works against all IP-enabled, statically assigned NICs on the computer.  If the computer has multiple NICs (i.e., is multihomed), this command will affect all of them—at least, all of them that match the criteria.  This may not be the desired effect.
  • Second, both the primary and secondary WINS servers have to be specified.  I haven’t figured out how to set only the primary WINS server or only the secondary WINS server yet.

With those limitations in mind, I hope that someone finds this information helpful.  I don’t think I can describe how many times I’ve had to go back and reconfigure servers with new DNS IP addresses or new WINS IP addresses, and when the number of servers gets up there that process gets real tedious real fast.

Tags: , ,

Remotely Setting the DNS Suffix Search Order

Thursday, July 6, 2006 in Microsoft by slowe

Invariably, larger organizations end up with a fragmented DNS namespace that has grown over the years due to name changes and acquisitions.  As resources move between domains (DNS domains and Active Directory domains), it soon becomes necessary to have clients resolve hostnames even when the fully qualified domain name (FQDN) isn’t provided by the user.  The DNS suffix search order provides that functionality, and is very often a key part of maintaining connectivity in these separate namespaces.

Because the DNS suffix search order can’t be set via DHCP (for Windows clients, at least), it has to be set some other way.  Windows Server 2003 adds this functionality into Group Policy, so that a GPO can enforce the DNS suffix search order that way.  Windows XP or higher is required to support that GPO functionality on the client side.

If it can’t be done via GPO, though, there aren’t a lot of options—unless you are using Windows XP and/or Windows Server 2003 and can use WMIC (WMI Command-line).  The full power of WMIC is outside the scope of this article (it’s quite likely you’ll see more from me about WMIC as time progresses), but we can at least look at using WMIC to set the DNS suffix search order on client systems.

First, let’s look at the full command, then we’ll break it down.  Here’s the full command:

wmic /node:@input.txt nicconfig call SetDNSSuffixSearchOrder
(legacydomain.com,newdomain.net,some.other.domain.org)

OK, so what does this command do, exactly?  Here’s the breakdown.

  • The “wmic /node:” invokes WMIC, targeted at a remote computer.  This allows us to run the command centrally, on one system, yet affect remote computers.
  • The “@input.txt” parameter tells WMIC to use the contents of the file input.txt to specify the names of the remote computers that will be configured with this command.  This makes it easy for us to export a list of computer names into a text file and then plug that text file into this WMIC command.
  • The “nicconfig” is the WMIC alias that allows us to configure NIC properties.  A full set of aliases can be viewed by typing “wmic /?”.
  • The “call” parameter is the verb, followed by the action being called.  In this particular case, we’re using the “SetDNSSuffixSearchOrder”; this is, in turn, followed by the list of DNS domains to be included in the DNS suffix search list.

By combining WMIC with the handy “for /f” batch command, we can do even more.  For example, let’s say we wanted to use Dsquery.exe to produce a list of all the computers in a particular OU.  That’s pretty straightforward:

dsquery computer “ou=Workstations,dc=example,dc=net” -o rdn

The “-o rdn” switch is used here to output the relative distinguished name (RDN) instead of the full DN.

Embed that command into a for loop like so:

for /f “tokens=1” %1 in ('dsquery computer
“ou=Workstations,dc=example,dc=net” -o rdn') do
@wmic /node:%1 nicconfig call SetDNSSuffixSearchOrder
(example.net,subdomain.example.net,otherdomain.org)

And just like that, we’ve taken the dynamic output of the Dsquery.exe tool and plugged into WMIC to set the DNS suffix search order for all the systems in a particular OU in Active Directory.

As a side note, it’s possible to use this WMIC command across domains (even without a trust relationship) by adding “/user:<username>” and “/password:<password>” switches to the WMIC command.  This will allow WMIC to authenticate to the remote system as the specified user with the specified password.

It’s also possible to use WMIC to set other parameters, such as DNS server search order and WINS servers.  However, setting these parameters via WMIC also requires that we identify the name of the specific network interface card, and that may vary from system to system.  I’ll try to work on some examples and post those here as soon as I have them working reliably.

UPDATE:  I failed to mention another important switch for WMIC; namely, the “/FAILFAST:ON” switch.  This switch causes WMIC to ping the remote node first as a connectivity test, and proceed with the operation only if the remote node is reachable.  This will eliminate delays waiting for timeouts for remote systems that are shut down or otherwise unreachable.

UPDATE 2:  Dsquery.exe has a “-limit” switch that can control how many objects will be returned by the query.  That switch is not included in the command line above; be sure to add “-limit 0” or “-limit X” to either bypass the limit or limit the query to X objects, respectively.

Tags: , ,

Mass Renaming Computers

Thursday, July 6, 2006 in Microsoft by slowe | 2 comments

I hate to continue beating the “for /f” stick, but it sure is a handy command.  This time we’re going to use it to rename large numbers of computers at a time, such as when your company changes the standard naming convention and then asks you to go back and rename all the computers that don’t match the new convention.  This is a big deal because not only must the computers be renamed, but the matching computer accounts in Active Directory must also be renamed at the same time.  Renaming the computer manually (from the Network Identification tab of the properties of My Computer) renames the Active Directory account, but who wants to do it all by hand?

First, you’ll need to prepare a comma-separated list of the old computer name (the current computer name) and the matching new computer name.  We’re using CSV (comma separated values) here because a number of the directory service command-line utilities, as well as other tools, produce CSV in their output.  Building our solution here to accept CSV means that you can later chain pieces together for an even more automated solution.

Once the CSV file is in place, the command looks something like this:

for /f “tokens=1,2 delims=,” %1 in (file.csv) do
@echo %1 >> results.txt &&
@netdom renamecomputer %1 /newname:%2 /ud:DomainAdmin /pd:AdminPass
/uo:LocalAdmin /po:AdminPass /force /reboot >> results.txt

Please note that you can run this command across domains with a trust relationship in place; the “/ud” switch assumes the computer’s current domain unless told otherwise, and the “/uo” parameter assumes a local account unless specified otherwise.

You’ll note we’re doing a couple of new things here.  First, we’re echoing the old name of the computer to a text file; this is for troubleshooting purposes.  Then, we run the Netdom command, substituting the appropriate parameters from the text file, and redirecting its output to the same text file as well.  The two commands are concatenated together on the same line using the double ampersands.

The resulting output (results.txt in the example above) looks like this:

pcname1
The command completed successfully.

pcname2
The command completed successfully.

This makes it very easy to go back and double-check to see which computers were successfully renamed and which computers had problems.

There are a couple of important caveats to this solution, however:

  1. You must either embed the passwords for the domain administrator and local administrator accounts in the command line, or you must enter the passwords for each computer to be renamed.  When renaming hundreds of computers, typing in the passwords is obviously not an option.
  2. Every computer must have the same local account and password as specified in the command line.  One could work around this by embedding the local username and password into the source text file, but this would most likely be more complicated than just standardizing usernames and passwords across workstations.
  3. This command is not intelligent enough to stop trying if the remote computer is unavailable, so lengthy delays will be introduced for those remote computers that are, for whatever reason, unreachable.

Even with these limitations and drawbacks, however, the process can be very useful when there are significant numbers of computers that must be renamed.

Tags: , , ,

It’s a Matter of Privacy, Not Security

Wednesday, July 5, 2006 in Macintosh by slowe

Daniel Jalkut, in his Red Sweater Blog, recently posted that he had detected (via Little Snitch) some network activity from Dashboard back to Apple’s web site.  Upon further investigation, he found that the activity was apparently tied to this one-line entry in the release notes for 10.4.7:

You can now verify whether or not a Dashboard widget you downloaded is the same version as a widget featured on (www.apple.com) before installing it.

To me, that doesn’t do an adequate job of informing the end user that the computer will be contacting Apple on a regular basis to verify the installed widgets.  What it says is that the OS can (i.e., has the ability to), upon the user’s request, verify a widget before installing it.  Those are two different things.

A lot of the comments on Daniel’s entry are blasting him for posting this information, stating that it’s a matter of security, that Apple is providing functionality to help protect Mac users against malicious code.  OK, I’ll grant that the ability to verify the authenticity of a downloaded widget is a good idea.  I’ll even grant that the ability to manually, whenever I feel like it, ask my computer to verify the authenticity of the currently installed widgets is a good idea.  I’ll even go so far as to grant that having a checkbox somewhere that says, “Periodically check my installed widgets for authenticity” or something similar would be a good idea.

What’s not a good idea is adding a “phone home” feature that users (apparently) can’t disable and that can’t be configured, controlled, or adjusted.  What’s further not a good idea is misrepresenting this functionality in the release notes.  Finally, what’s not a good idea is for Mac users to confuse security with privacy.

This isn’t a matter of security.  Most everyone agrees that having the ability to check widgets to make sure they are safe is a good idea.  The problem here is that our computers are now communicating with Apple in a way that we did not authorize, were not informed about, and can not control.  That makes it a matter of privacy, not security.  And yes, while the communication right now is benign, will it always be so?  What will the Mac users do when it is not benign?

I posted a comment to the article to see what methods, if any, are available to disable this functionality.  As soon as I get some additional information, I’ll post it here.

UPDATE:  This safety check can be disabled by using the command:

sudo launchctl unload -w /System/Library/LaunchDaemons/
com.apple.dashboard.advisory.fetch.plist

This should all be typed on a single line.  In addition, it’s important to note that the dashboardadvisoryd process does not send any information to Apple currently; it only fetches information from Apple and compares it to the list of currently installed widgets.  Also, in the light of the extensive information shared with Apple as a result of using Software Update (an aspect I did not consider originally), I retract most of my concerns regarding privacy.  I do, however, stand by the statement that Apple should have been more informative and forthcoming with information on exactly how this work, as well as given users a means whereby to control it.

Tags: , , ,

« Older entries § Newer entries »