McAfee ePO 4.0 won't update repository or allow manual package check-in

I was running into an issue with our ePO 4.0 server, where it wasn't updating the master repository like it should, and if I tried to manually check-in a package I would get an error that said "Unknown failure processing package". Trying to manually pull updates would also give a -1 error and say nothing was found. This turned out to be caused by the SQL Server install and the ePO server instance trying to communicate on different ports, which is fairly easy to fix and is documented in the McAfee knowledgebase under KB51620.

Instructions are for SQL 2005. If you're using a different version, check KB51620 for other instructions.

1. Identify which port SQL Server is using. To do this, go to Start->All Programs->Microsoft SQL Server 2005->Configuration Tools->SQL Server Configuration Manager

2. Go to SQL Server 2005 Network Configuration->Protocols for mySQLServer->TCP/IP

3. Right-click TCP/IP and choose Properties

4. Go to the IP Addresses tab, then scroll to the bottom where it says IPAll. Make note of the value in the TCP Dynamic Ports box, as this needs to match what your ePO server is set to use.

5. Close the SQL Configuration tool

6. Login to your ePO server

7. Change the URL to https://locahost:8443/core/config in order to access the ePO 4.0 Database Configuration Page

8. Scroll down to the Database Server Port. This value should match what your SQL Server had in the TCP Dynamic Ports box. If not, change it here so it matches your SQL Server and click Save at the bottom.

9. Close your browser

10. Now you have to restart your ePO services. To do this, right-click on My Computer and select Manage

11. Go to Services and Applications->Services

12. Stop the following services in this order: McAfee ePolicy Orchestrator 4.0.0 Server, McAfee ePolicy Orchestrator 4.0.0 Event Parser, McAfee ePolicy Orchestrator 4.0.0 Application Server

13. Start the services in the reverse order, so: McAfee ePolicy Orchestrator 4.0.0 Application Server, McAfee ePolicy Orchestrator 4.0.0 Event Parser, McAfee ePolicy Orchestrator 4.0.0 Server

14. Close the Services window

The KB article notes that doing this may lead to the Event Parser and Tomcat services to have high CPU utilization for a while until it catches up with processing, but then it will go back to normal. This is ok and you should let them finish.

After doing this you should be able to update your Master Repository, run a Pull Now, and also manually check-in packages.

Shared folders on iSCSI drive disappear after restart

I was finally given approval to purchase an iSCSI SAN a few months ago and have been enjoying the benefits of having a large amount of storage space with a RAID6 disk array. However, one problem I had with the iSCSI disk is that if I shared a folder in Windows Server 2003 from any of the logical iSCSI drives on the computer, after a restart the share would disappear and I would have to recreate it. Any shares from the hard drives of the server were fine, it was just affecting shares from the iSCSI disks. The problem is that the iSCSI software doesn't always start running before the Server service does, and since the Server service can't see the iSCSI drives, it doesn't share the folders. Luckily, MS KB870964 gives you the answer to fix this problem.

1. First, make the Server service independent of the iSCSI initiatior. To do this, use the command: sc config LanManServer depend= MSiSCSI

And yes, there is a space after the = and that is supposed to be there

2. Configure persistent logons to the iSCSI disk. To do this, open iSCSI initiator and go to the Persistent Targets tab. If your iSCSI disk is already listed there, then skip this step. If not, go to the Available Targets tab, select your disk from the list, and click on Log On. Check the box named "Automatically restore this connection when the system boots" and click OK.

3. Set the BindPersistentVolumes option for the iSCSI Initiator service. To do this, open iSCSI Initiator, go to the Bound Volumes/Devices tab, then click on Bind All. This should make your iSCSI disks available to the system before it attempts to load the iSCSI service.

There are some alternative methods listed in MS KB870964, so feel free to check that out if the above instructions are not clear or you can't seem to get it to work.

If you're simply looking to find a download location for Microsoft's iSCSI Initator software, you can get that from http://www.microsoft.com/downloads/details.aspx?familyid=12cb3c1a-15d6-4585-b385-befd1319f825&displaylang=en

Group policy assigned software not being installed

I wanted to setup Office 2007 to be deployed through group policy. However, I could get it to work on the machine I was using to test the policy on, even though the rest of the GPO settings set on that OU were being applied correctly. Well, it turned out that it was the gigabit NIC installed in the laptop (IBM Thinkpad T42). Apparently there are some known issues (that I didn't know about) that are more prevalent on gigabit interfaces which cause the policy processing to timeout. Luckily there's a registry hack to fix it.

1. Open the Registry Editor (Start->Run, then regedit and click OK)

2. Go to HKEY_LOCAL_MACHINE->SOFTWARE->Microsoft->Windows NT->CurrentVersion->Winlogon

3. Add a new DWORD named "GpNetworkStartTimeoutPolicyValue" to the Winlogon folder

4. Change the "GpNetworkStartTimeoutPolicyValue" to decimal and give it a value of 60

5. Close the Registry Editor and restart the computer

What this does is extend the timeout for group policy processing from the default of 30 seconds to 60 seconds. As soon as I did this on my test machine the software installed on the reboot. One way you'll notice this may be needed is if you start seeing event 1054 in you Application event log.

I found the answer on experts-exchange.com, which just links to Microsoft KB 840669

Update: 11-19-09

Ran into this again on a Dell Dimension 4550 I was working on. The common denominator appears to be certain older Intel NICs, or at least it has been in all the machines I've had the problem with. Adding the registry key fixed it in this case as well. If you're running into event ID 1054 in your Application event log, try the registry key addition and see if it'll fix your problem. This can also be related to other items within group policy not being applied as well, not just software deployment to computers.

OS X 10.5 Leopard includes better VPN support

We have a simple PPTP VPN setup using a Fortigate firewall, but the Mac OS X 10.4 users had a hard time with it. The problem was that there was no way to set the DNS servers for the PPTP connection within OS X 10.4, so everything had to use IP addresses. It appears that they've fixed this in OS X 10.5 Leopard, and I'm going to guess it is also fixed in Snow Leopard (OS X 10.6). You also do not use the Internet Connect application to configure VPN connections anymore either, but rather the Network section of System Preferences. For a nice guide on where to find this, and how to setup the VPN connection in OS X 10.5, check out this page over at www.publicvpn.com

Take screenshot of iPhone screen

Sometimes it would be nice to take a quick screenshot of my iPhone screen to be able to use to show someone something. Little did I know that Apple thought of that and it's really easy to do. All you have to do is press the home and power buttons quickly at the same time. The screen should flash as if you had just taken a picture, and then you can find the screenshot within your pictures on the phone. From there you can hook the phone to a computer and get your picture files. This also works as a free way to export andget your text messages off your phone into a printable format, rather than having to buy any software to do it.

This is found right in the manual, on page 80.

http://manuals.info.apple.com/en_US/iPhone_User_Guide.pdf