http://edmckinzie.spaces.live.com/blog/cns!687C72A5909E4230!232.entry

This problem lies in the fact that Acrobat for some reason has a problem reading or writing to a file on a network share. Since the user’s home drive is connected to the network share, Acrobat will crash every time they try to open a file. Log in with a local user account and everything works great. After figuring out where the problem lay, I found a posting on the Adobe Forums about this exact issue.

What I found there was the following:

1. Log in as a Network User
2. Go to /Users/Shared/
3. If you are on an Intel based Mac create a folder in /Users/Shared/ named 9.0_x86 if you are on a Mac that is a G5/G4 create a folder named 9.0_ppc

At this point you should have created either
/Users/Shared/9.0_x86/
/Users/Shared/9.0_ppc/

4. Go to ~/Library/Application Support/Adobe/Acrobat/ and trash the 9.0_x86 or 9.0_ppc folder contained within
5. Go to Applications/Utilities/ and open Terminal
6. Enter one of the following into the Terminal
If you are on an Intel based Mac enter
ln -s /Users/Shared/9.0_x86 ~/Library/Application\ Support/Adobe/Acrobat/9.0_x86
If you are on a G5/G4 Mac enter
ln -s /Users/Shared/9.0_ppc ~/Library/Application\ Support/Adobe/Acrobat/9.0_ppc
7. Open up Acrobat 9 and it should work!

*bold is my edit*

I found for the link command (ln) I had to actually specify the 9.0 folder. You are basically telling the computer to go to a local directory when it tries to find the user’s files in the home directory which is on the network. I also had to chmod the /Users/Shared/9.0_ppc to 777 because I created the folder with an admin user and the normal user didn’t have rights to make changes. After doing this, it all worked!

As of this posting, it appears the problem still exists and has not been fixed by Adobe even though it has been a known issue for 7 months now.

The link below led me to think of Group Policy and I did an rsop.msc on the server to find it was the workstation policy affecting the server. Created a new OU outside the range of the policy which should have been done a long time ago anyways and the problem has been resolved. No more services getting disabled.

My Hint: http://www.tech-archive.net/Archive/Windows/microsoft.public.windows.server.general/2007-05/msg00216.html

The first thing is that the PIX Firewall (with VPN) was already set up when I got here so I won’t get into that configuration. It used to be configured with local accounts for each person who needed VPN and they had a static password. This was a bit cumbersome and insecure as the password never changed. I had used RADIUS to set up the same sort of thing for wireless authentication so I decided to see if I could get it working for the VPN. It took a little doing but I got it.

On Windows Server 2003, you need to install IAS (Internet Authentication Service). Go to Add/Remove Programs (appwiz.cpl) and then select Add/Remove Windows Components on the left side. Select Networking Services then Details, then put a check next to Internet Authentication Service. Select OK and Next and it will be installed. You will find the program under Administrative Tools in the Start Menu.

Once you open IAS, you will need to right click Internet Authentication Service (Local) and select Register Server in Active Directory. This will add the computer to a security group in Active Directory and register the service. Next, right click on RADIUS Clients and select New Radius Client. Here, you will put in the info about your PIX device. Now, even though there is an option in Client-Vendor for Cisco, we will leave it at the default value of RADIUS Standard. Here, you also choose a shared secret. I strongly recommend using a very long string of numbers, letters and symbols. You will only need to enter this here and in the PIX one time and then you can forget about it so don’t worry about making it something easy to remember. One final important note on this step is to leave the box unchecked for Message Authenticator attribute.

Next go to the Remote Access Policies window. Right click and select New Remote Access Policy. Now, I’m going to suggest you do it a little differently than I did originally but it will save you making a few changes later. Instead of using the wizard, select Set up a custom policy. You can name it something like “Allow VPN Access”. Now, in policy conditions select NAS-IP-Address and then enter the IP address of your PIX. The second attribute we’ll select is Windows-Groups. You will need to have created a group in Active Directory first before you can select it so create one called “VPN Access” or something similar. This is the security group you’ll place all users who you want to have access. If a user that does not have access tries to use it when they are not in the group it will fail. After you have added the group, click next and you will be finished. Note the order of the policies — the server will attempt to match each rule starting with the first and if it matches the default rule that denies connections first then it won’t even evaluate yours.

Now that you have your rule in place, open it up for more details. Click on the Advanced tab then Add. Here, you want to add Ignore-User-Dialin-Properties and set it to True. This tells IAS to ignore the properties of each user in their profile which gives them dial-in privileges. I assume this was a previous way of configuring remote access that is not used much anymore. Having users in the security group you created earlier controls the permission of users connecting. Next, go to the Encryption tab and select every encryption but the no encryption box. Then on to Authentication and choose only Unencrypted authentication (PAP, SPAP). Now, this last one with no encryption — I tried very hard to see if there was another way because I don’t want any credentials floating around in plain text but I didn’t see a way. I’m no security expert but when I analyzed some traffic establishing the connection, it looks like the pre-shared key we set up before encrypts the authentication so it is in plain text but only inside of an already encrypted tunnel so it should be safe. Feel free to correct me because I’m still learning about VPNs. After that setting you should be done with the IAS setup.

Now for the PIX. For this I used the PDM interface. I know the true Cisco experts will prefer the command line and I do for switches usually but for the VPN I’m sticking with the PDM interface for now. Once you are logged in, go to Configuration. Once there, select the System Properties tab and then navigate to the AAA category. Under AAA Server Groups you will see RADIUS among others. The only thing I set was Dead Time to 0. If you have more than one RADIUS server you may want to set this to 10 minutes or so because it is the time it will consider a server dead if it can’t contact it and then it will use another server during this time period. On to AAA Servers. Click Add and select RADIUS for the group, inside for the interface, the IP address and also your key that you created back in IAS. Make sure you are applying these settings as you go. Next, we move to the VPN tab and select the IKE category. Find the XAuth/Mode Config and edit the outside interface. Here you’ll select RADIUS for server group and if you want you can check the box to use LOCAL accounts when the RADIUS fails. If for some reason your RADIUS server goes down, you could connect using a local account (such as administrator). This would mostly benefit the admins who know the password as other users wouldn’t know what to type. However, if you have a weak password I suppose it could be a security risk. After you have that set you can apply then save the changes to the PIX.

There is always troubleshooting of course. In the PIX, you can click the Monitoring icon and then view the PDM Log. This should show you when a RADIUS lookup is attempted or if it is not then what is. In IAS you’ll want to look under your normal event logs in the System setting. You will see IAS as Source and you can see what policy is matched. If your policy is not being matched then you need to find out why. It does give you good information such as the IPs, user-name, the authentication and encryption being used. If any of those do not match you may see it is being matched against another Policy-Name and that will give you some clues.

$ locate vmware

was enough to list quite a few files which was encouraging. I eventually found the vmware-tools in /usr/bin directory. I then ran the vmware-toolbox program and the first option I saw was “Time synchronization”. Exactly what I wanted. Now when i receive alerts about the network, the time will actually be correct. And my OCD is satiated as well.

I definitely appreciated the way everyone made me feel welcome. There were signs saying “Welcome” and “Glad to have you” which was very nice. Of course everyone is nice on the first day but hopefully the general environment will stay about the same.

The other plus is that I get to take the bus to work! I can’t wait til I have my bus pass ’cause coming up with $3 in exact change every day is a pain. When the traffic is low I really get in somewhat early and get home not too late. It’s much less stressful than driving. I will have to drive sometimes when I need to go to support another office but if I don’t know of that ahead of time I will be taking the bus.

One thing I’ve missed is it’s been very hot here the last couple days. 96 and 98 degrees Fahrenheit for highs I believe and I’ve been really looking forward to it but I’ve been stuck inside both days. Oh well, if I do make it outside it should still be nice.

Well, there is more to tell but I’m tired so I’m going to go to bed for my 6:30am crew call.