Are you using PPTP to connect to a Microsoft ISA server for VPN? Do your internal machines on the VPN side of the connection no longer resolve except when you use a fully qualified domain name?

The PPTP VPN settings under 10.5 provide some additional options, which you can reach via the Network System Preferences panel. Go to VPN, and click on Advanced, then view the Options tab. The setting is "Send all traffic over VPN connection." If this is unchecked, you will be unable to resolve internal hostnames without typing the fully qualified domain name. If you check it, you will be able to refer to your internal hostnames by the short name. This occurs no matter whether you have your VPN local DNS search domain typed in there or not.

I think this may in fact be a bug in 10.5, since it presumably should work without have to force all the traffic over the VPN.

One thing that I really miss from Tiger is having a shortcut on my Desktop to my network shared volumes, so I don't have to open a Finder window, click on share, and then select the machine or AirPort Extreme entry, and then the volume I want to access.

Leopard won't let you make an alias of a network shared volume, or create one by dragging it to your desktop. What I found out, however, is that you can drag a shared volume to the dock as a Stack folder, and there it is, a direct link to your shared volume. You have to drag it to the area next to the trash; it won't work in the applications zone of the dock.

It also helps when the Shared option won't even appear, and you don't remember the direct link to get to the volume through finder's Go » Connect to Server option. This happens quite often with AirPort Extreme, and now I just have to click the shortcut on the dock and it will come right up.

[robg adds: As noted in this hint, there seems to be either a bug or a feature in the new Finder: using Column view, you can make aliases from networked volumes via a drag to the desktop (or to the sidebar, as in the previous hint). Using other views, though, you cannot. I can only hope that this is a bug is in the 'other' views, and it's not something that's "fixed" in a future update by breaking the column view behavior! Regardless, putting the network share into the Dock as a Stack is an interesting trick.]

After upgrading to Leopard, I found I was unable to mount any of the shares on my Linux file server, getting the following error: At first I thought this was because of the security configuration I was using on the file server, or perhaps because Leopard had changed the type of authentication method it was expecing from an SMB file server (NTLMv2 for example). It turns out it was a lot simpler -- it was because all of the shares on the file server were set as non-browseable (Browseable = No in /etc/smb.conf. Changing at least one share to be browseable corrected the issue and let me connect to the file server and mount the shares available, regardless of if they were set as Browseable or not.

It should be noted that if you connect to any windows servers, then you will not notice this issue as the default shares for drives (c$, d$, etc) are browseable, but most SMB client implementations will 'hide' them from the end user.

I had been having some problems dealing with Leopard's Screen Sharing feature -- I wasn't able to remotely connect, no matter which ports I opened or prefs I turned on, using a machine from my job running 10.4.

I was attempting to connect with Chicken of the VNC (CotVNC), and according to a few articles across the web, it should have worked flawlessly. It certainly did on my network at home, so I wasn't sure what I was doing wrong. I even DMZ'd my machine at home -- still, nada.

Then I was playing around with the Profiles options in CotVNC, and there's a setting where you can change the resolution of the window on the client's end. The choices are 256 colors, Thousands, Millions, and Let Server Decide. I always had it set to 256 at work, because I was more interested in speed than how pretty my desktop looked from afar. However, I checked out my settings at home and I had the Let Server Decide option selected.

Aha -- I was on to something. I got to work this morning, changed the resolution in the profile settings to Thousands, and sure enough, CotVNC works like a charm again. It also worked fine with Let Server Decide. 256 colors worked perfectly with Tiger, but I'm guessing there's something with Leopard's built-in screen sharing that's not allowing a VNC client to connect at that low of a resolution. Just thought I'd share my findings for anyone possibly having the same difficulties.

For .mac users, the iDisk is fantastic for keeping a folder synchronized between multiple computers. One can turn on local syncing of the iDisk to have hard drive speed access to this folder shared between multiple machines, which is great. I do almost all my document editing on the iDisk and it is the same everywhere I go. For those who do a lot of document editing, doing some form of version control would be great. Time Machine is perfect for this, as subversion is kind of overkill for documents and small projects.

However, there is a problem with using Time Machine on the iDisk in Leopard: the iDisk in Leopard is not locally synchronized on a file to file basis. The local copy exists as a .sparsebundle file in ~/Library/FileSync. This is done so that the local copy only occupies the same amount of space as the files you currently have in your iDisk. Tiger on the other hand would just take up the full 10GB on your hard drive if that is how much space was allocated for your iDisk. This .sparsebundle looks like one giant file, but it is actually a package which contains a whole bunch of 8MB bands.

Time machine does not let you look at your iDisk back in time, but this sparsebundle is backed up, so in principal one could go back in time and recover a previous iDisk. But one could only recover the entire previous contents of the iDisk rather than individual files on the iDisk. (Note here that if you change an individual file on the iDisk, Time Machine will only backup the bands which have changed, which are at most 8MB, rather than the entire iDisk).

However, this does not help with recovering a single file from the past from the iDisk. There is a hack to do this however.

My iMac G4 800 MHz Flatpanel does not have an original (and now practically unobtainable) AirPort card. Even if you find one for 100 euro or more, and it turtns out not to be a scam, you still only have 802.11b, not g, wireless. That is a problem! Here's the fix. I purchased a Belkin Wireless G Gaming adapter (F5D7330). The adapter is hooked up to the UTP ethernet port and it draws power from a USB cable (of which it has two, but one is enough). So you do not need the power adapter, and there are no net cables involved.

This has allowed me to connect to my AirPort Express router. It feels great making an 802.11g connection with a machine that is deemed not AirPort Extreme Ready.

Of course, I want to secure my network. I can set up my Base Station using the AirPort Assistant, but how do I setup the adapter correspondingly? AirPort software only works with the original unobtainable AirPort card. After I tried everything else, I read the manual. Go to System Preferences » Network » Configure and switch to manual IPv4 (or set it up as a new location). Type 192.168.2.220 for the IP address, etc. Follow the instructions in the manual which are intended for Windows. Use the reset buttons on your Base Station and adapter in case things do not work out; even unplugging the USB may be required. Success!

[robg adds: Note that this is not really a portable solution in terms of size; it's more like a typical wireless router, not a cardbus solution.]

OS X 10.5's screen sharing feature works nicely on local networks. But to control your computer over an internet connection is easy, too. If the tunnel is established and you click the generated link, the screen sharing app will start and show your remote computer.

[robg adds: A comment on the queue site notes "To ensure this is secure, you should ssh to the target host and forward to localhost. e.g: ssh -L 1202:localhost:5900."]

There have been several hints in the past about the contents of ARD and the networksetup command line utility. It is a very nice tool, and in OS X 10.4, it was found in /System » Library » CoreServices » Remotemanagement » ARDAgent » Contents » Support » networksetup. It is no longer there, but now instead, it is stored in /usr/sbin/networksetup.

So, if any of you were using scripts to push out network settings via ARD or a third party app like Casper, you should adjust your scripts accordingly. This change is only in Leopard, so all previoius versions of OS X can use the contents of the ARDAgent package.

So I updated our little network to 10.5, and the ability to share volumes and foelders is just great. However, I had a problem with how to enable a given group's read - write - delete - execute access to a given shared volumes: for all files that exist in that folder today, and for all files that might be created in the future. There are some hints on this problem, including cron jobs and default permission flags (umask), but none of them really worked out, especially in 10.5.

The answer lies in the advanced Access Control Entries (ACE) handling of file permissions. This involves Terminal, but Michael Watson has coded a front end for this. I asked him, and he will update the code for Leopard as soon as he finds a minute. Thus, we have to use the Terminal for now.

I've just upgraded my son's Mac Mini to 10.5, and turned on the Screen Sharing and ssh server after the initial install. In 10.4, I had long ago configured the "hidden" ARD VNC server, though alas I now find I've forgotten the password I set at that time. My son's gone to bed, but I want to play on his Mac -- what to do?

It seems that the "new" screen sharing feature is basically the same as 10.4's, and the VNC password is in the same place: /Library » Preferences » com.apple.VNCSettings.txt. The password is obfuscated by XORing it with a fixed key, so you need a little perl magic to view / set it.

[robg adds: Read on for the how-to. Please note that this isn't a security concern, as it assumes you've got ssh access to the machine in question, as well as the ability to execute root privileges on that meachine -- and if you've got both of those things, well, you've pretty much got the machine anyway.]