Security::VPN::Alphabet Soup

Integrity: AH = Authentication Header or ESP = Encapsulating Security Payload

Encryption: DES = Data Encryption Standard, 3DES = 3 DES keys used, AES = newer standard

Hash: SHA = Secure Hash Algorithm, MD5 = Message-Digest. SHA is newer/more secure. Vista uses SHA

Protocol Analysis::TCP::TCP State Descriptions

Thanks to: http://www.tcpipguide.com

Table 151: TCP Finite State Machine (FSM) States, Events and Transitions

State	State Description	Event and Transition
CLOSED	This is the default state that each connection starts in before the process of establishing it begins. The state is called “fictional” in the standard. The reason is that this state represents the situation where there is no connection between devices—it either hasn't been created yet, or has just been destroyed. If that makes sense. J	Passive Open: A server begins the process of connection setup by doing a passive open on a TCP port. At the same time, it sets up the data structure (transmission control block or TCB) needed to manage the connection. It then transitions to the LISTEN state.
		Active Open, Send SYN: A client begins connection setup by sending a SYN message, and also sets up a TCB for this connection. It then transitions to the SYN-SENT state.
LISTEN	A device (normally a server) is waiting to receive a synchronize (SYN) message from a client. It has not yet sent its own SYN message.	Receive Client SYN,Send SYN+ACK: The server device receives a SYN from a client. It sends back a message that contains its own SYN and also acknowledges the one it received. The server moves to the SYN-RECEIVED state.
SYN-SENT	The device (normally a client) has sent a synchronize (SYN) message and is waiting for a matching SYN from the other device (usually a server).	Receive SYN, Send ACK: If the device that has sent its SYN message receives a SYN from the other device but not an ACK for its own SYN, it acknowledges the SYN it receives and then transitions to SYN-RECEIVED to wait for the acknowledgment to its SYN.
		Receive SYN+ACK, Send ACK: If the device that sent the SYN receives both an acknowledgment to its SYN and also a SYN from the other device, it acknowledges the SYN received and then moves straight to the ESTABLISHED state.
SYN-RECEIVED	The device has both received a SYN (connection request) from its partner and sent its own SYN. It is now waiting for an ACK to its SYN to finish connection setup.	Receive ACK: When the device receives the ACK to the SYN it sent, it transitions to the ESTABLISHED state.
ESTABLISHED	The “steady state” of an open TCP connection. Data can be exchanged freely once both devices in the connection enter this state. This will continue until the connection is closed for one reason or another.	Close, Send FIN: A device can close the connection by sending a message with the FIN(finish) bit sent and transition to the FIN-WAIT-1 state.
		Receive FIN: A device may receive a FIN message from its connection partner asking that the connection be closed. It will acknowledge this message and transition to the CLOSE-WAIT state.
CLOSE-WAIT	The device has received a close request (FIN) from the other device. It must now wait for the application on the local device to acknowledge this request and generate a matching request.	Close, Send FIN:The application using TCP, having been informed the other process wants to shut down, sends a close request to the TCP layer on the machine upon which it is running. TCP then sends a FIN to the remote device that already asked to terminate the connection. This device now transitions to LAST-ACK.
LAST-ACK	A device that has already received a close request and acknowledged it, has sent its own FIN and is waiting for an ACK to this request.	Receive ACK for FIN: The device receives an acknowledgment for its close request. We have now sent our FIN and had it acknowledged, and received the other device's FIN and acknowledged it, so we go straight to the CLOSED state.
FIN-WAIT-1	A device in this state is waiting for an ACK for a FIN it has sent, or is waiting for a connection termination request from the other device.	Receive ACK for FIN:The device receives an acknowledgment for its close request. It transitions to the FIN-WAIT-2 state.
		Receive FIN, Send ACK: The device does not receive an ACKfor its own FIN, but receives a FIN from the other device. It acknowledges it, and moves to the CLOSING state.
FIN-WAIT-2	A device in this state has received an ACK for its request to terminate the connection and is now waiting for a matching FIN from the other device.	Receive FIN, Send ACK: The device receives a FIN from the other device. It acknowledges it and moves to the TIME-WAIT state.
CLOSING	The device has received a FIN from the other device and sent an ACK for it, but not yet received an ACK for its own FIN message.	ReceiveACK for FIN: The device receives an acknowledgment for its close request. It transitions to the TIME-WAIT state.
TIME-WAIT	The device has now received aFIN from the other device and acknowledged it, and sent its ownFIN and received an ACK for it. We are done, except for waiting to ensure the ACK is received and prevent potential overlap with new connections.	Timer Expiration: After a designated wait period, device transitions to the CLOSED state.

Exchange::IIS::Redirect HTTP to HTTPS page for Outlook Web Access

The following KB article details customizing the error message for the 403.3 error (SSL required.)
MS KB 839357
I'm not an ASP programmer, but I couldn't get their sample code to work. Instead I used the more elegant HTML below:

<HTML>
<HEAD>
<TITLE>WebMail</TITLE>
<meta HTTP-EQUIV="REFRESH" content="0; url=https://email.COMPANY.com/exchange">
</HEAD>
<p>
Redirecting to: <a href="https://email.COMPANY.com/exchange" target="_blank">https://email.COMPANY.com</a>
</p>
</BODY>
</HTML>


Exchange::Mailbox Cleanup Agent

Thanks to: MS Exchange Team Blog

Exchange 2000/2003 Mailbox Manager and msExchMailboxManagerAgeLimit.
In Exchange 2000/2003 mailbox manager policies may not process items as some administrators might expect. For example, if you set up a mailbox manager policy to delete messages from the inbox after 30 days, you may find that some of the messages are not deleted after the 30 day window has passed.

In Exchange 2000/2003, in order for a message to be processed by a policy, the age of the message must pass 3 criteria:

Delivery: (PR_MESSAGE_DELIVERY_TIME),

Sent: (PR_CLIENT_SUBMIT_TIME),

and Last Modified: (PR_LAST_MODIFICATION_TIME).

If any of these flags are less than the age specified on the mailbox manager policy settings, that message will not be processed. In other words, if you have a policy set to 30 days and at 29 days a user reads a message that falls under this policy (and hence sets the last modified flag back to 0 days) the message will not be processed after the 30th day because it will fail on 1 of the 3 criteria. It will not be processed until all the criteria are met (in this scenario after 30 more days)

This behavior is different than in Exchange 5.5. In Exchange 5.5, if the delivery time flag is present on a message then no other criteria will be checked. So in the above scenario, 30 days after receiving the message it would be purged.

The design was changed in Exchange 2000/2003 to better accommodate certain workflow programs, journaling and non-ipm.note message classes that would look at different message properties for cleanup.

However, in certain environments you might want to have Exchange 2000/2003 behave the same as Exchange 5.5. This can be done in Exchange 2000 with the post SP3 roll-up or with Exchange 2003 RTM by setting the msExchMailboxManagerAgeLimit attribute on the mailbox manager policy to a hex value of "0x3".

There are three values you can set this to depending on your needs:

0x1: The Last modification time will not prevent the deletion of a message. If the last modified modified date is greater than the limit, the item may be deleted.

0x2: The time that the message was submitted will not prevent the deletion of a message. If the submission time is greater than the limit, the item may be deleted.

0x3: This value sets both bits 0x1 and 0x2, and mimics the behavior from Exchange 5.5.

Note that Mailbox Manager does not ever delete recurring appointments or tasks, regardless of age. You cannot turn off evaluation of delivery time.

More information on setting this is in the following article: KB 326397

HP Servers::iLo

Reset iLo Administrator Password

Thanks NetNerds !

1. Installed SNMP because it was a preprequesite
2. Download and Install the HP Insight Management Agents.
3. Download HP Lights-Out Online Configuration Utility.
4. Download HP Lights-Out XML Scripting Sample for Windows


reset.xml
<ribcl VERSION="2.0">
<login USER_LOGIN="Administrator" PASSWORD="boguspassword">
  <user_INFO MODE="write">
   <mod_USER USER_LOGIN="Administrator">
    <password value="newpass"/>
   </mod_USER>
  </user_INFO>
</login>
</ribcl>

hponfig.exe /f reset.xml

HTML::Style Sheet::Page Breaks

This is a wonderful thing:

<STYLE TYPE="text/css">
HR {page-break-before: always}
</STYLE>