Archive
NT Konferenca 2010
Samo še nekaj dni nas loči do letošnje NT konference 2010, ki se bo odvijala od 24. do 27. maja v Portorožu.
Kaj bom predaval?
- Prehod na Exchange Server 2010
Europa D, torek 10:15 – 11:30
Sašo Erdeljanov (avtenta.si) - Delavnica: Disaster recovery: Exchange Server 2010 in Data Protection Manager 2010
Aurora 2, sreda 13:30 – 16:00
Sašo Erdeljanov (avtenta.si), Matej Malerič (avtenta.si) - MVP panel
MSTech (Pečina), sreda 16:30 – 17:30
Exchange predavanja
- Tips & Tricks: Exchange Server 2010
Europa B, torek 11:45 – 12:30
Scott Schnoll (Microsoft Corporation) - Exchange Server 2010 High Availability Deep Dive
Europa D, sreda 08:45 – 09:45
Scott Schnoll (Microsoft Corporation)
Letos bomo na @NTkonferenca uporabljali twitter s temo pogovora #NTK10.
Postgre osnove
postgres, from scratch:
1) install postgresql-server
2) joe /var/lib/pgsql/data/pg_hba.conf
odkomentiraš vrstico:
host all all 127.0.0.1 255.255.255.255 trust
3) joe /var/lib/pgsql/data/postgresql.conf
odkomentiraš:
tcpip_socket = true
port = 5432
4) ln -s /usr/share/java/pg74.215.jdbc3.jar /usr/share/java/postgresql.jar
5) service postgresql restart
6) Za kreirat userja na default bazi “template1”
psql -h localhost -d template1 -U postgres
template1=# CREATE USER ibmdirector WITH PASSWORD ‘avtenta’ CREATEDB;
CREATE USER
template1=# q
Postgre osnove
postgres, from scratch:
1) install postgresql-server
2) joe /var/lib/pgsql/data/pg_hba.conf
odkomentiraš vrstico:
host all all 127.0.0.1 255.255.255.255 trust
3) joe /var/lib/pgsql/data/postgresql.conf
odkomentiraš:
tcpip_socket = true
port = 5432
4) ln -s /usr/share/java/pg74.215.jdbc3.jar /usr/share/java/postgresql.jar
5) service postgresql restart
6) Za kreirat userja na default bazi “template1”
psql -h localhost -d template1 -U postgres
template1=# CREATE USER ibmdirector WITH PASSWORD ‘avtenta’ CREATEDB;
CREATE USER
template1=# q
The IPSec Policy storage container could not be opened. The following error occurred: The system cannot find the file specified. (80070002).
» When you attempt to open the IPSec MMC policy on Windows Server 2003, you receive ‘The IPSec Policy storage container could not be opened. The following error occurred: The system cannot find the file specified. (80070002).’?
When you attempt open the IPSec (Internet Protocol Security) MMC (Microsoft Management Console) on Windows Server 2003, you receive:
The IPSec Policy storage container could not be opened. The following error occurred: The system cannot find the file specified. (80070002).
This behavior is caused by a corrupted file in the policy store, possibly caused by an improper shutdown while the policy was being written to disk.
To fix this problem:
1. Copy / Paste the following into Notepad.exe:
@echo off ( @echo REGEDIT4 @echo. @echo [-HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftwindowsIPSecPolicyLocal] @echo. @echo. )>"%TEMP%IPSec.tmp" regedit /s "%TEMP%IPSec.tmp" regsvr32 polstore.dll /s del /q "%TEMP%IPSec.tmp"
2. Save the file as IPSecFix.txt.
3. Rename the file as IPSecFix.bat.
4. Run or double-click the IPSecFix.bat file.
The IPSec Policy storage container could not be opened. The following error occurred: The system cannot find the file specified. (80070002).
» When you attempt to open the IPSec MMC policy on Windows Server 2003, you receive ‘The IPSec Policy storage container could not be opened. The following error occurred: The system cannot find the file specified. (80070002).’?
When you attempt open the IPSec (Internet Protocol Security) MMC (Microsoft Management Console) on Windows Server 2003, you receive:
The IPSec Policy storage container could not be opened. The following error occurred: The system cannot find the file specified. (80070002).
This behavior is caused by a corrupted file in the policy store, possibly caused by an improper shutdown while the policy was being written to disk.
To fix this problem:
1. Copy / Paste the following into Notepad.exe:
@echo off ( @echo REGEDIT4 @echo. @echo [-HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftwindowsIPSecPolicyLocal] @echo. @echo. )>"%TEMP%IPSec.tmp" regedit /s "%TEMP%IPSec.tmp" regsvr32 polstore.dll /s del /q "%TEMP%IPSec.tmp"
2. Save the file as IPSecFix.txt.
3. Rename the file as IPSecFix.bat.
4. Run or double-click the IPSecFix.bat file.
How to configure RPC over HTTP on a single server in Exchange Server 2003
http://support.microsoft.com/?id=833401
http://www.msexchange.org/tutorials/Outlook_2003_Connect_Exchange_2003.html
RPC/HTTP Problems anyone?
If you happen to be one of those people that just can’t make it work, here is an additional tip that I found in the newsgroups this past week. Basically, rpcproxy.dll gets registered as a web service extension in IIS (the actual web extension is RPC Proxy Server Extension). rpcproxy.dll is located in the c:windowssystemrpcproxy directory. If the RPC Proxy Server Extension required files is pointing at the wrong file name/path (in this case, it was pointing to c:windowssystemrpcproxy.dll instead of c:windowssystemrpcproxyrpcproxy.dll), then configuring everything else will still result in RPC/HTTP not working. Fortunately, the fix here is as simple as adding the correct file/path to the required files, then removing the incorrect one.
Old trick, but hard to find
|
|||||
Anyways, I seemed to recall being able to change that list, or perhaps I had actually done it a white ago, but how to do it now had escaped me. So I Googled a bit and found the following information.
Did you ever want to change the Default locations to where you can save things too and open things from?
The default list (in Windows XP PRo) is:
My Recent Documents
Desktop
My Documents
My Computer
My Network Places
These places can be altered from the following location in the Registry.
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionPolicies
First add a new key titled “ComDlg32”. Next, under the ComDlg32 folder, add a new key titled “PlacesBar”
With PlacesBar highlighted, you then add 5 items to the right pane called:
Place0
Place1
Place2
Place3
Place4
The types of entries you can make can be either String values (to denote a custom path name, such as C:Downloads), or you can create a new DWORD value and use the Built-in values that Windows uses (Hexadecimal values). Some examples are:
DWORD value of 0 = Desktop
DWORD value of 2 = Programs
DWORD value of 5 = My Documents
DWORD value of 6 = Favorites
DWORD value of 11 = My Computer
DWORD value of 12 = My Network Places
DWORD value of 27 = My Pictures
There are lots more values, so you can play around and try different values to see what you come up with – I wasn’t able to find a list in my feeble search attempts, but then again, I didn’t feel like wasting a lot of time looking for it.
It’s also worth noting that this change doesn’t affect the Save As menu that Office displays, but there are other methods for changing that menu.
Anyways, it’s the little things that make the computing experience easier. 🙂
Exchange migration tips – changing the outbound delivery mechanism
Remember that with Exchange 5.5, in order to send or receive Internet e-mail, you had to install the Internet Mail Connector (IMC) a.k.a Internet Mail Service. Exchange 2000/2003 no longer require (or use) an IMC to send/receive internet mail, as they use SMTP natively and have the ability to send/receive e-mail from the internet by default. That being said, you might expect that once you introduce an Exchange 200x server into your org, that it would send outbound mail itself. Not so, my friend. Instead, your Exchange 200x server will, you guessed it, still use the 5.5 IMC for outbound e-mail. If you want to change how outbound e-mail routes, then you must make some configuration changes.
There are basically 3 different methods that should allow you to change how outbound e-mail is routed.
1. Rename the address space on the IMC to something invalid (i.e. bogus.local). Install an SMTP Connector on an Exchange 200x server with the address space of “*”. There are a few more steps that need to be done – for that, make sure to reference the KB article I have linked to at the bottom.
2. Remove the address space on the IMC. Obviously, removing something is inherently a “bit” riskier, but in this case, should pose no problems. Once the address space is removed and replicated, you would do the same as above with installing and SMTP connector.
3. Add an SMTP connector with a lower cost that contains the same address space (i.e. “*”). While theoretically the connector with the lowest cost ought to win, I’ve heard reports that it doesn’t necessarily always work that way, and that the IMC “may” still win. The best thing to say about this is YMMV (Your mileage may vary). If it doesn’t work, then revert back to either of the previous methods.
Once you have chosen a method, and verified that outbound e-mail is now routing through the Exchange 200x server’s SMTP connector instead of the IMC, you can safely remove the addres space (if you didn’t already) and then once replicated, you can uninstall the IMC. As I mentioned earlier, there is a terrific MSKB article that references how to do this. That article can be found here.
How to switch outgoing mail connectors when migrating to Exchange 2000 or 2003
PERFORM A SECURE SQL SERVER INSTALLATION
PERFORM A SECURE SQL SERVER INSTALLATION
Collecting and distributing data is part of the responsibilities of
network administration, and you must ensure that this data is
verifiable and secure. Regardless of their operating system, database
servers require special attention to ensure the security of their
operation.
Security begins at installation. Let’s look at how you can secure SQL
Server from the start.
INSTALLATION
Before beginning installation, go to the premise router or firewall,
and specifically block UDP and TCP ports 1433 and 1434 to the IP
address of SQL Server. This will prevent a SQL injection compromise
while you’re installing the system.
Never install SQL Server on a domain controller. An application
vulnerability could lead to the compromise of your entire domain.
Install each SQL Server on a fresh operating system that you’ve fully
patched before installing applications and migrating data.
SQL Server services should run under separate local accounts. If
someone compromises the application, other servers will remain
unaffected.
If the server is going to service a Windows-based network, all
connections to the server should require Windows Authentication. This
alleviates the responsibility of users having to remember another
password, which they would probably write down and post on their
monitors.
SERVICE ACCOUNTS
As always, service accounts require special attention to the privileges
you grant them. SQL Server uses two accounts: SQL Server Engine and SQL
Server Agent. Both accounts should run as a domain user with regular
account privileges.
If you use SQL Server Authentication instead of Windows Authentication,
or if your server will run ActiveX scripts or CmdExec jobs (i.e.,
operating system commands or executable programs ending with .bat,
.cmd, .com, or .exe), the SQL Server Agent account will need local
Windows administrator privileges.
NOTE: If you need to change the account associated with a SQL Server
service, use SQL Server Enterprise Manager. The Enterprise Manager will
set appropriate permissions on the files and registry keys used by SQL
Server. Do not use the Services applet of the MMC in Control Panel to
change these accounts.
AFTER INSTALLATION
Clean up your installation by running Microsoft’s Killpwd.exe utility,
which removes the clear text sysadmin password stored in various setup
files during installation.
http://support.microsoft.com/default.aspx?scid=kb;%5bLN%5d;Q263968
After you’ve cleaned the installation files from your new server, run
the Microsoft Baseline Security Analyzer (MBSA). This tool scans and
tests your installation for several issues. These problems include:
* Too many members of the sysadmin fixed server role
* Granting of rights to create CmdExec jobs to roles other than
sysadmin
* Blank or trivial passwords
* Weak authentication mode
* Excessive rights granted to the Administrators group
* Incorrect access control lists (ACLs) on SQL Server data directories
* Plain-text sysadmin password in setup files
* Excessive rights granted to the guest account
* SQL Server running on a system that’s also a domain controller
* Improper configuration of the Everyone group, providing access to
certain registry keys
* Improper configuration of SQL Server service accounts
* Missing service packs and security updates
Finally, remember to audit failed connections. This is one of the most
overlooked items of installation. You can enable auditing through the
SQL Server Enterprise Manager.
Follow these steps:
1. Right-click the server, and select Properties.
2. On the Security tab, select Failure under Audit Level.
3. Stop and restart the server for auditing to begin.
FINAL THOUGHTS
This is only the beginning to performing a secure SQL Server
installation. If your server will collect data from a public Web
server, you should limit those SQL ports to the IP address of your Web
server. There are many excellent uses for a database server, but they
all begin with a secure installation.
Mike Mullins has served as a database administrator and assistant
network administrator for the U.S. Secret Service. He is a Network
Security Administrator for the Defense Information Systems Agency.
Blog (at) Mreza.Info 