Tuesday, November 10, 2009
Hacking Story
http://www.wired.com/threatlevel/2009/11/rbs-worldpay/
Wednesday, September 16, 2009
Tuesday, February 24, 2009
Outlook PST File too Large
Symptoms:
My Outlook .pst file was .7 gigs and was taking a while to backup. I felt that Outlook was also running slowly.
Gathering Information:
I used the Tools> Mailbox Cleanup > Mail size. I saw that my deleted folder was almost as large as my inbox.
Hypothesis:
H1. Permanently remove deleted items.
H2. Compress the file.
Results:
H1 was rejected. I right click on my recycle bin and emptied the folder. When I check the .pst file size it was still .7 gigs.
H2 was accepted. I found the steps at this site: http://support.microsoft.com/kb/289987. The steps are:
How to Manually Start PST Compaction
- On the File menu, click Data File Management.
- Click to select your Personal Folder, and then click Settings.
- On the General tab, click Compact Now.
- Click OK, and then click Close.
Reflection:
The .pst file is a database file. Even when you delete items, the empty space is there making the file large. Most databases I work with, Access to SQL 2005, have a compact feature. This is standard maintenance for a databases and should be for outlook also.
Cannot Connect Remotely to SQL Server
Symptoms:
No client could connect to the SQL server. I was getting connection fail error. See Figure 1.
Gathering Information:
Clients were able to connect to the database recently. The database is on Windows Server 2008; the server has two network cards (172.16.x.x and 10.x.x.x). The 172 network card is for the class room and 10 network card connects to the network outside of the classroom. I did a port 1433 scan and the server is not listening on 172 network card.
The error message, see Figure 1, indicated it was remote connection setup but the SQL server had worked.
Hypothesis:
H1 SQL Server only listening on 10.x.x.x network card.
H2. The timeout was too low and should be moved higher.
H3. Name pipes is conflicting with TCPIP.
H4. You need all protocols to connect (turn on Via, Named pipes, shared memory)
H5. Server and client are not up to date with newest service packs, and updating both should allow connection.
H6. The gateway on the compute was changed recently (172.16.X.X). This was to allow for web service to work. Adding the gateway back should allow the SQL to connect.
H7. Configuring Route and Remote access on SQL server should allow for the traffic to find both network cards in server and repair error SQL. This should also keep the web server running.
Results:
H1 is rejected because the SQL server could see other SQL Servers on 10.x.x.x.
H2 is rejected. The timeout on queries was updated to 1000 from 600 and connections still failed.
H3 is rejected. Name pipes were turned off and still no connection.
H4 is rejected. All protocols were turned on and still no connection.
H5 is rejected. The server did not have service pack 3 and that was down loaded an installed. The client had this version: Microsoft SQL Native Client Version 09.00.3042. The new client was Microsoft SQL Native Client Version 09.00.4035. I found a down of the client at this location: http://www.microsoft.com/downloads/details.aspx?FamilyID=536FD7D5-013F-49BC-9FC7-77DEDE4BB075&displaylang=en
H6 is rejected. This fixed the sql connection error but killed the web server again.
H7 is accepted. The routing install allowed all workstations to access the SQL server. The real reason is not certain but a wire snoop would shed light on the topic.
Reflection:
I need a server change log. This is a very common practice among network admins. The change of gateways brought that SQL server down.