Monthly Archives: January 2014
How to configure a windows share and how to access it
Configuration documented here
Here is the document
Here is the installation document
Definition from wikipedia page
Network-attached storage (NAS) is file-level computer data storage connected to a computer network providing data access to a heterogeneous group of clients. NAS not only operates as a file server, but is specialized for this task either by its hardware, software, or configuration of those elements. NAS is often manufactured as a computer appliance – a specialized computer built from the ground up for storing and serving files – rather than simply a general purpose computer being used for the role.
NAS devices are gaining popularity, as a convenient method of sharing files among multiple computers. Potential benefits of network-attached storage, compared to file servers, include faster data access, easier administration, and simple configuration.
NAS systems are networked appliances which contain one or more hard drives, often arranged into logical, redundant storage containers or RAID. Network-attached storage removes the responsibility of file serving from other servers on the network. They typically provide access to files using network file sharing protocols such as NFS, SMB/CIFS, or AFP.
NAS is useful for more than just general centralized storage provided to client computers in environments with large amounts of data. NAS can enable simpler and lower cost systems such as load-balancing and fault-tolerant email and web server systems by providing storage services. The potential emerging market for NAS is the consumer market where there is a large amount of multi-media data. Such consumer market appliances are now commonly available. Unlike their rackmounted counterparts, they are generally packaged in smaller form factors. The price of NAS appliances has plummeted in recent years, offering flexible network-based storage to the home consumer market for little more than the cost of a regular USB or FireWire external hard disk. Many of these home consumer devices are built around ARM, PowerPC or MIPS processors running an embedded Linux operating system.
List of network protocols used to serve NAS
Read my other posts for building and using
Microsoft supports booting from a Storage Area Network (SAN) if the SAN vendor supports their particular hardware platform booting a Windows server. The SAN and host bus adapter (HBA) must be configured according to the SAN vendor’s guidelines and the SAN vendor must act as the main point of contact for boot-related issues. This requirement exists because booting from a SAN is extremely complex, and the vendor needs to support the particular configuration because the SAN vendor provides the SAN boot supportability statement. It is important to note that the information that is included in this article is not intended to be an all-inclusive list of the items that are required to boot from a SAN. The SAN vendor must provide specific steps, drivers, firmware revisions and resources about how to make their hardware (storage systems, switches, Host Bus Adapters, and so on) work properly together.
The following issues must be addressed so multiple computers can successfully boot from a SAN:
To boot multiple computers from a SAN, the SAN must either be configured in a switched environment, or it must be directly attached from each host to one of the storage sub-system’s Fibre Channel ports. The use of Fiber Channel – Arbitrated Loop (FC-AL) is not supported when booting multipe servers from the SAN because it does not allow the hosts that are attached to the SAN to be properly segregated from each other. A switched environment allows the hosts to be separate from each other. Booting to a SAN with a Fiber Channel-Arbitrated Loop topology is only supported when booting a single server from the SAN.
The host must have exclusive access to the disk that it is booting from. No other host on the SAN should be able to detect or have access to the same logical disk. This can be accomplished by using a type of Logical Unit Number (LUN) management such as LUN masking, zoning or some combination of these methods. LUN management is normally configured at the switch, storage subsystem and/or Host Bus Adapter (HBA) level and not within Windows. Windows provide no capabilities for mapping LUNs.
Multi-path software and multiple HBAs improve your chances of recovery from a path failure. The purpose of having multiple HBAs in a single host is to have redundancy and (possibly) increased throughput. However, if a failure occurs and a path to the SAN is lost, there may be a period of time where the drives on the SAN are not accessible. This path failure may cause problems with the Windows server. Behavior of multi-path software varies greatly between vendors. Check the Windows Catalog (formerly Hardware Compatibility List or HCL) for Storage/RAID systems to make sure that the multi-path driver is in the Windows Catalog with the storage system. If you cannot find the multi-path software, contact your SAN vendor.
To see the Storage/RAID Catalog, please view the following Microsoft Web site:
If the hosts that are attached are part of a Windows 2000 cluster solution, you must use one HBA for the boot process and a separate HBA for shared storage.
If the hosts that are attached are part of a Windows 2000 cluster solution and are using the Microsoft multipath I/O (MPIO) feature, you need four HBAs.
There is a Microsoft document shows how it is
Here a document how windows XP can boot from SAN
Both Storage Area Networks (SANs) and Network Attached Storage (NAS) provide networked storage solutions.
A NAS is a single storage device that operate on data files, while a SAN is a local network of multiple devices that operate on disk blocks.
A SAN commonly utilizes Fibre Channel interconnects. A NAS typically makes Ethernet and TCP/IP connections.
A DAS system is made of a data storage device (for example enclosures holding a number of hard disk drives) connected directly to a computer through a host bus adapter (HBA). Between those two points there is no network device (like hub, switch, or router), and this is the main characteristic of DAS.
The main protocols used for DAS connections are ATA, SATA, eSATA, SCSI, SAS, and Fibre Channel.
Most storage networks use the SCSI protocol for communication between servers and disk drive devices. A mapping layer to other protocols is used to form a network:
ATA over Ethernet (AoE), mapping of ATA over Ethernet
Fibre Channel Protocol (FCP), the most prominent one, is a mapping of SCSI over Fibre Channel
Fibre Channel over Ethernet (FCoE)
ESCON over Fibre Channel (FICON), used by mainframe computers
HyperSCSI, mapping of SCSI over Ethernet
iFCP or SANoIP mapping of FCP over IP
iSCSI, mapping of SCSI over TCP/IP
iSCSI Extensions for RDMA (iSER), mapping of iSCSI over InfiniBand
Windows Remote Management (WinRM) is the Microsoft implementation of WS-Management firewall-friendly Protocol based on SOAP (Simple Object Access Protocol)over HTTP and HTTPS.
This used to obtain hardware and system data from an operating systems other than Windows. WinRM establishes a session with a remote computer through the SOAP-based WS-Management protocol rather than a connection through DCOM, as WMI does. Data returned to WS-Management protocol are formatted in XML rather than in objects.
Apart from WMI, WinRM utilizes the Intelligent Platform Management Interface (IPMI) driver for hardware management. The IPMI provider and driver enable you to control and diagnose remote server hardware through BMCs [Baseboard Management Controllers] even when the OS is not running or deployed. Effectively BMC is a chip connected to the processor board of a server; it has its own network adapter and hence can monitor the server in situations even when the server is malfunctioning.
Supported authentication mechanisms
Digest [Client Only]
command to run : winrm quickconfig -q
using this command service will start and set auto start and create a listener to accept requests on any IP address
To list all the WinRM listeners, run this command:
Winrm enumerate winrm/config/listener
You can also get the configuration information of the Service, Client and WinRS by running the following command:
Winrm get winrm/config
supported operations are
winrm OPERATION RESOURCE_URI [-SWITCH:VALUE [-SWITCH:VALUE] …]
For help on a specific operation:
winrm g[et] -? Retrieving management information.
winrm s[et] -? Modifying management information.
winrm c[reate] -? Creating new instances of management resources.
winrm d[elete] -? Remove an instance of a management resource.
winrm e[numerate] -? List all instances of a management resource.
winrm i[nvoke] -? Executes a method on a management resource.
winrm id[entify] -? Determines if a WS-Management implementation is
running on the remote machine.
winrm quickconfig -? Configures this machine to accept WS-Management
requests from other machines.
winrm configSDDL -? Modify an existing security descriptor for a URI.
winrm helpmsg -? Displays error message for the error code.
For help on related topics:
winrm help uris How to construct resource URIs.
winrm help aliases Abbreviations for URIs.
winrm help config Configuring WinRM client and service settings.
winrm help certmapping Configuring client certificate access.
winrm help remoting How to access remote machines.
winrm help auth Providing credentials for remote access.
winrm help input Providing input to create, set, and invoke.
winrm help switches Other switches such as formatting, options, etc.
winrm help proxy Providing proxy information.
winrm get wmicimv2/Win32_Service?Name=spooler
>winrm get wmicimv2/Win32_Service?Name=spooler
AcceptPause = false
AcceptStop = true
Caption = Print Spooler
CheckPoint = 0
CreationClassName = Win32_Service
Description = Loads files to memory for later printing
DesktopInteract = true
DisplayName = Print Spooler
ErrorControl = Normal
ExitCode = 0
InstallDate = null
Name = spooler
PathName = C:\windows\System32\spoolsv.exe
ProcessId = 1348
ServiceSpecificExitCode = 0
ServiceType = Own Process
Started = true
StartMode = Auto
StartName = LocalSystem
State = Running
Status = OK
SystemCreationClassName = Win32_ComputerSystem
SystemName = xyz
TagId = 0
WaitHint = 0
You can also use the WinRm get command to query the remote computer:
“Winrm get Winrm/config –r:remotemachinename”
Run this to query the service of remote computer:
“Winrm get wmicimv2/Win32_Service?Name=spooler –r:remotemachinename”
To reboot a remote machine:
“winrm invoke reboot wmicimv2/Win32_OperatingSystem -r:<some computer>”
Start a service on a remote machine
“winrm invoke startservice wmicimv2/Win32_Service?name=w32time -r:<some computer>”
Find below for few Good Vista WS-Man (WinRM) Commands
Using in powershell
winrm set winrm/config/client @ allowunencrypted= true
winrm set winrm/config/client @ trustedhosts= local
winrm set winrm/config/service @ allowunencrypted= true
In computer systems and networks a run book is a set of defined procedures developed by the administrator or IT professional for maintaining the everyday routine, as well as the exceptional operations of the computer system or network. The run book should contain all the information a staff would need to perform daily operations as information on dealing with any problems that arise during usage from the operational system or network. Some procedures defined in an organization’s run book would include procedures for starting and stopping the system, instructions for handling special devices, such as mounting optical disks or tapes, and procedures for how to perform backups, and so on.
Contents of a Run Book
The run book should contain the following types of detailed resource information to help your staff perform routine operational tasks and respond quickly and efficiently to data center emergencies:
- Contact information â€” Detailed information about each database administrator (DBA), the building facilities staff, utility companies, and all hardware and software vendors
- Hardware components â€” Detailed information about hardware components of the data center
- Software components â€” Detailed information about software components of the data center
Keeping this critical resource information current and readily available to your staff reduces downtime when disaster strikes.
Record detailed information regarding each individual or company that you or your staff may need to contact in an emergency. This detailed contact information should include the following:
- Contact information for each DBA at the primary site, including his or her role in the operational and disaster recovery process
- Contact information for the building facilities staff, the power company, the phone company, and other applicable utilities companies
- Contact information for your remote site, if you have one, and for all DBAs at that site
- Hardware, software, and service vendor support phone numbers, e-mail addresses, account numbers, and login and password information for related Web sites
- Contact information for other server applications on the server, including developers, analysts, testers, and managers affected by a change to the application, related systems, or processes
In addition, record any additional contact information that might be useful in troubleshooting and repairing the data center, such as useful e-mail discussion lists and Web sites.
Record detailed information regarding each hardware component in the data center, including the following:
- Server hardware
- Model and serial number
- Brand and speed of the processor
- Amount and configuration of memory
- Version of the BIOS
- Dates and version numbers of firmware
- NIC cards, including their vendors and model numbers
- SCSI host adapter or fiber channel cards, including their vendors and model numbers
- Local storage hardware
- Type, size, and number of drives, including cache if any
- Logical disk configuration
- RAID levels
- Disk controller information (including write cache settings)
- Dates and versions of firmware for drives and controllers
- Special options used, such as allocation units
- Disk arrays and storage area networks
- Vendor and model
- Type, size, and number of drives, including cache if any, and controller to which the disk is connected
- Logical disk configuration
- RAID level
- Number of controllers and number of channels
- Disk controller information (including write cache settings)
- Dates and versions of firmware for drives and controllers
- Special options used, such as allocation units
In addition, record all additional information about the data center hardware that might be useful in troubleshooting and repairing the data center. For example, record a map of the physical wiring of specific drives to specific array controllers.
Record detailed information about each software component in the data center:
- All software
- Serial numbers and/or license keys
- The network share location for all software installed on the server, including all service packs, hardware drivers, and hot fixes
- The onsite and offsite location of all software CDs, including license keys and serial numbers
- The location of the written documentation for all software
- Windows 2000
- Operating system version, with service pack level and hot fixes
- Server name, IP address, and role in the domain
- Customized settings, including terminal server and registry settings
- Information on related systems, including contacts, configuration information, and documentation of data interfaces
- Local administrator account name and password
- Cluster configuration, including all cluster IP addresses, cluster name, cluster nodes, and cluster resource groups
- User accounts authorized to administer the cluster
- Microsoft SQL Server
- Installation information, including service pack levels, hot fixes, instance names, server collation, ports, pipes, configuration options, virtual IP name and address, database file locations, file groups, service logins and passwords, e-mail account, and enabled network protocols
- Information about file shares used by the SQL Server and SQL Server Agent service accounts and the associated permissions on those shares
- Database collations if different from the server collation
- Server roles, database schemas, user accounts, permissions, database roles, custom error messages, and the location of scripts to recreate these objects
- List of all automated SQL Server Agent jobs (specifically including all backup jobs), what they do, who is notified, their corresponding code for each job step, the time or times they run, and the location of scripts to recreate the jobs
- List of all alerts, what they do, the associated error number or performance condition, who is notified, and the location of scripts to recreate the alerts
- Linked server, remote server, replication, and log-shipping configuration information
- Distributed database and distributed partition information, including information such as Data Dependent Routing Tables and distributed transaction marks
- List and location of all DTS Packages, including associated login and password information
- List, location, and purpose of all custom code that runs on the server, and the location of a backup copy of this code
- Names and locations of client tools installed to connect to remote database connections (for example, to heterogeneous data sources), and necessary configuration and connection information
- List of additional features in use and relevant configuration information, such as Extensible Markup Language (XML) support for Internet Information Services (IIS), Active Directory service support, and Data Source Names (DSNs)
- Analysis Services
- Data source and transfer information, including all associated jobs
- Location and storage format of the Analysis Services repository
- Analysis Services repository backup job information and storage location
- Location of data files
- Security architecture, including logins, database roles, and cube roles
In addition, record all additional information about the software that might be useful in troubleshooting and repairing the data center. For example, record the staff members who are most familiar with custom applications.
Develop and document procedures for each operational and emergency task that you and your staff perform. Whenever possible, develop Transact-SQL scripts for each of these tasks and automate the execution of these scripts by using SQL Server jobs or DTS packages. The procedural information should include the detailed steps and scripts for performing the following tasks utilizing both SQL Server Enterprise Manager and Transact-SQL scripts:
The DBA staff performs many routine operational tasks. To avoid problems, your staff should perform these tasks by using the same procedures each time. Record step-by-step procedures for performing each of the following types of routine operational tasks:
- Security tasks
- Changing the domain user account and password used by SQL Server and SQL Server Agent
- Creating new logins and database user accounts
- Changing SQL Server user passwords
- Performing standard and C2 security audits
- Scripting login information
- Scripting application roles and recording passwords
- Scripting linked or remote servers
- Restoring logins and database users to another SQL Server instance
- System administration tasks
- Starting and stopping the operating system
- Starting and stopping SQL Server services
- Changing SQL Server configuration settings
- Setting database options
- Applying SQL Server service packs
- Changing the server name
- Manually backing up a database
- Manually backing up a transaction log
- Monitoring tasks
- Monitoring CPU usage
- Monitoring disk activity
- Monitoring memory usage
- Viewing current locks
- Viewing current activity
- Viewing the last command batch for a specified connection
- Viewing the data and log space information for a database
- Viewing the oldest active transaction in the database
- Viewing the procedure cache usage
- Viewing general statistics about SQL Server activity and usage
- Identifying and analyzing bottlenecks
- Data collection tasks
- Archiving system and application logs in the event viewer
- Archiving SQL Server error logs and SQL Server Agent logs
- Archiving SQL Server setup logs
- Archiving the cluster log file
- Archiving sqldiag.exe output
- Capturing output from sysperfinfo and sysprocesses
- Capturing output from MPS Report tool if available
- Troubleshooting tasks
- Testing TCP/IP sockets client connections
- Testing named pipes connections
- Troubleshooting deadlocks
- Troubleshooting failover clustering
- Troubleshooting replication
- Troubleshooting log shipping
- Troubleshooting MS DTC transactions
- Troubleshooting orphan users
In addition to the foregoing, add step-by-step instructions for other tasks that you and your staff perform regularly.
Record the appropriate response to each type of emergency that may affect the data center. Although the precise tasks vary depending upon the high availability solutions implemented, have a planned and tested response to each of the following types of emergencies:
- Natural disasters
- Power outages
- Server failures
- Hardware component failures
- User database corruption
- System database corruption
- Application failures
- Network failures
- Web server or other necessary server failures
Depending upon the high availability solutions implemented for the data center, the detailed steps will include MSCS failover and failback steps, log-shipping role change steps, transactional replication role change steps, and database restoration steps. These procedures should document the process of determining when to initiate a failover or a role change and how affected users are notified. These procedures must include steps to verify the system’s state before bringing a restored system or database online. They should also include escalation steps in case the first attempt to restore availability fails.
Download free softwares from
Another priced software and automation tools
A quick guide of ayehu is here
Rootkit is a malicious, designed to hide the existence of certain processes or programs from normal methods of detection and enable continued privileged access to a computer. The term rootkit is a concatenation of “root” a privileged account on Unix and becomes hide the intrusion as well as to maintain privileged access.This means Obtaining this access is a result of direct attack on a system.
chkrootkit (Check Rootkit) is a common Unix-based program intended to help system administrators check their system for known rootkits. It is a shell script using common UNIX/Linux tools like the strings and grep commands to search core system programs for signatures and for comparing a traversal of the /proc filesystem with the output of the ps (process status) command to look for discrepancies.
download it from http://sourceforge.net/projects/zeppoo or from
#tar xvfz chkrootkit.tar.gz
Warning: Possible Showtee Rootkit installed
You have 9 process hidden for readdir command
You have 11 process hidden for ps command
chkproc: Warning: Possible LKM Trojan installed
ROOTDIR is `/’
Checking `amd’… not found
Checking `basename’… not infected
Checking `biff’… not infected
Checking `chfn’… not infected
Checking `chsh’… not infected
Checking `cron’… not infected
Checking `crontab’… not infected
Checking `date’… not infected
Checking `du’… not infected
Checking `dirname’… not infected
Checking `echo’… not infected
Checking `egrep’… not infected
Checking `env’… not infected
Checking `find’… not infected
Checking `fingerd’… not found
Checking `gpm’… not found
Checking `grep’… not infected
Checking `hdparm’… not infected
Checking `su’… not infected
Checking `ifconfig’… not infected
Checking `inetd’… not infected
Checking `inetdconf’… not infected
Checking `identd’… not found
Checking `init’… not infected
Checking `killall’… not infected
Checking `ldsopreload’… not infected
Checking `login’… not infected
Checking `ls’… not infected
Checking `lsof’… not infected
Checking `mail’… not infected
Checking `mingetty’… not found
Checking `netstat’… not infected
Checking `named’… not found
Checking `passwd’… not infected
Checking `pidof’… not infected
Checking `pop2’… not found
Checking `pop3’… not found
Checking `ps’… not infected
Checking `pstree’… not infected
Checking `rpcinfo’… not infected
Checking `rlogind’… not found
Checking `rshd’… not found
Checking `slogin’… not infected
Checking `sendmail’… not infected
Checking `sshd’… not infected
Checking `syslogd’… not infected
Checking `tar’… not infected
Checking `tcpd’… not infected
Checking `tcpdump’… not infected
Checking `top’… not infected
Checking `telnetd’… not infected
Checking `timed’… not found
Checking `traceroute’… not infected
Checking `vdir’… not infected
Checking `w’… not infected
Checking `write’… not infected
Checking `aliens’… no suspect files
Searching for sniffer’s logs, it may take a while… nothing found
Searching for HiDrootkit’s default dir… nothing found
Searching for t0rn’s default files and dirs… nothing found
Searching for t0rn’s v8 defaults… nothing found
Searching for Lion Worm default files and dirs… nothing found
Searching for RSHA’s default files and dir… nothing found
Searching for RH-Sharpe’s default files… nothing found
Searching for Ambient’s rootkit (ark) default files and dirs… nothing found
Searching for suspicious files and dirs, it may take a while…
/usr/lib/php/.registry /usr/lib/php/.registry/.channel.pecl.php.net /usr/lib/php
/usr/lib/php/.lock /usr/lib/php/.filemap /usr/lib/php/
pdb /usr/lib/iceape/.autoreg /lib/init/rw/.ramfs
/usr/lib/php/.registry /usr/lib/php/.registry/.channel.pecl.php.net /usr/lib/php
Searching for LPD Worm files and dirs… nothing found
Searching for Ramen Worm files and dirs… nothing found
Searching for Maniac files and dirs… nothing found
Searching for RK17 files and dirs… nothing found
Searching for Ducoci rootkit… nothing found
Searching for Adore Worm… nothing found
Searching for ShitC Worm… nothing found
Searching for Omega Worm… nothing found
Searching for Sadmind/IIS Worm… nothing found
Searching for MonKit… nothing found
Searching for Showtee… nothing found
Searching for OpticKit… nothing found
Searching for T.R.K… nothing found
Searching for Mithra… nothing found
Searching for LOC rootkit… nothing found
Searching for Romanian rootkit… nothing found
Searching for Suckit rootkit… nothing found
Searching for Volc rootkit… nothing found
Searching for Gold2 rootkit… nothing found
Searching for TC2 Worm default files and dirs… nothing found
Searching for Anonoying rootkit default files and dirs… nothing found
Searching for ZK rootkit default files and dirs… nothing found
Searching for ShKit rootkit default files and dirs… nothing found
Searching for AjaKit rootkit default files and dirs… nothing found
Searching for zaRwT rootkit default files and dirs… nothing found
Searching for Madalin rootkit default files… nothing found
Searching for Fu rootkit default files… nothing found
Searching for ESRK rootkit default files… nothing found
Searching for rootedoor… nothing found
Searching for ENYELKM rootkit default files… nothing found
Searching for common ssh-scanners default files… nothing found
Searching for suspect PHP files… nothing found
Searching for anomalies in shell history files… nothing found
Checking `asp’… not infected
Checking `bindshell’… not infected
Checking `lkm’… chkproc: nothing detected
chkdirs: nothing detected
Checking `rexedcs’… not found
Checking `sniffer’… eth0: not promisc and no PF_PACKET sockets
eth0:1: not promisc and no PF_PACKET sockets
eth0:2: not promisc and no PF_PACKET sockets
Checking `w55808’… not infected
Checking `wted’… chkwtmp: nothing deleted
Checking `scalper’… not infected
Checking `slapper’… not infected
Checking `z2’… chklastlog: nothing deleted
Checking `chkutmp’… chkutmp: nothing deleted
Checking `OSX_RSPLUG’… not infected
Now how to automate
30 5 * * * (cd /opt/chkrootkit-0.49; ./chkrootkit 2>&1 | mail -s “chkrootkit output”
That will run the command at 5:30am every day and, providing you have ‘mail’ installed and configured, email the results to the specified address.