He wants me to create a test server in our Production enviroment, then after a Database / Lotus Script execution to test the speed of NT versus Solaris, he wants to remove the server. I told him this is not the way to do it and that we should create a test domain that has nothing to do with the production enviroment and test from there. He says I am crazy and that no Lotus Admin would do it that way in the real world… Is he right?
Subject: it’s not how we did it
Usually we set up a standalone server or a server in a new domain, put data from the production environment on it (databases, templates, whatever). Do your testing, and after you have successfully completed the tests, you put a new version in production. What your boss says is certainly not usual in our neck of the woods. There’s always the risk that new database designs or testing data will end up in your production environment, so if you have to do what your boss says, ensure in every possible way that this cannot happen.
Subject: Is my Boss right?
I would use a separate domain if only because it’s easier to set up and take down without involving anyone else. In fact, I’ve got a separate domain on my two work computers, that I use to try things out.
There’s a certain peace of mind in knowing that unless I go to great trouble to get my servers cross certified with a production domain, there’s no way anything I mess up on my test servers can replicate through into the production domain. Not that I have enough access there to do a great deal of damage, but still…
Perhaps there’s a larger question you should consider – why are you doing your own Domino timing tests on different OS platforms? See www.notesbench.org.
Subject: Your boss is a jerk… re: Is my Boss right?
…and needs a little management 101 training, but his suggestion is a better way to configure your test environment.
I’ve never understood why people set up separate domains for test environments. Security is a major part of nearly every Notes application, and the operating of security is dependent on the structure of the domain. So if you’re setting up a TEST server, then you can only validly test in a mirror of your production domain, which requires making the test server part of that domain.
Now, if you’re setting up a DEV server, or a SANDBOX server, then it’s a different story.
The simply version of the setup: Create a test server ID with your standard setup, but include an additional OU in the server name indicating that it’s a test. For instance…
NOTESSVR/TESTSVR/ACME
Then add an entry to your primary address book ACL of */TESTSVR/ACME as Reader. That way, domain changes on your test servers will never replicate back to production, regardless of schedules or group memberships.
Personally, I think test servers should be able to route mail just like anything else. How else do you test workflow applications? When you’re setting up an application test that requires new groups, go ahead and create the groups in the primary address book. You can use the Description field (or the new Category in D6) to track that they’re still being used for testing, but there’s no relevant cost to having additional groups.
Replicate to your test servers just like any other server. Again, with read-only access to your NAB, the impact is minimal. If you want to be OCD about it, you can set up unique CertLogs, AdminReq and Catalog databases for the test server, but is it really a problem if your AdminP requests for the test server are visible in production?
Subject: A Boss is always a jerk… 
Regarding “new” or copied applications i second your thoughts, but as another poster already stated: Do NOT use replica’s of your production applications on your test server.People tend to modify data (and/or design) on their test environment, this could easily replicate back when you set up the test server in the same domain (localdomainservers are often manager)
Subject: Is my Boss right?
both are ok. your way is for thorough (creating a whole new domain etc…) his way faster and more efficient.
hes the boss so just do it
ST
Subject: Yes, your boss is right
In fact, in my book, all bosses are right. So, support him and make sure you take every measure to make sure that nothing goes wrong!
I would feel comfortable setting up a test server in a production environment. But, I just happen to know a fair amount of admin stuff.
Subject: Doesn’t matter how much you know …
It all depends what you want to test.
If the slightest change exists that you will fire off Adminp requests, or that you are going to change documents/design in your Domino Directory, go for a different domain.
It’s so much easier to make sure nothing goes wrong, when working in a separate domain, because you don’t have to worry about replication, adminp requests, domino directory.
On the other hand, it may be easier (or even necessary) to set a testserver in the domain, because you may need the exact configuration (which may be too difficult to reproduce etc…)
So choose wisely, my friend 
cheers,
Tom
Subject: Is my Boss right?
Thank you all for the responses… I appriciate the insite. I just really think nothing good comes from a statement starting with: “You’re the only one”, That statement just alienates the person into feeling like their strange i.e. wrong in their position.
Subject: Is my Boss right?
Your boss is wrong based on the statement “no Lotus Admin would do it that way in the real world”.
One of the first things I did after setting up Domino was to create a Test domain. I create servers as needed in this domain, and if they need access to databases in my Production domain I create connection documents and cross-certificates, or just copy the database to the new server.
There are several reasons for this approach. When you register a server the information filters into a lot of different places, and it doesn’t always clean up automatically when you delete the server. Manually tracking it all down is a very time-consuming process.
When you have servers you are testing with you are typically less careful with them than you are with those you know people will be using. Corrupting a critical database on a test server, such as the Domino Directory, and replicating it with a Production server is a really bad thing.
And lastly, your Production environment has to be up at all times. Why mess with a stable environment when you don’t have to?
I hope that helps.
– Charles
Subject: Is my Boss right?
Ok, after 9 years of Notes admin and developing, This setup works for me. Setup a test server and a developer server. Set your connection documents to only do a pull from production to both servers and turn off mail routing. Then by all means force the use of templates and store them on your developer server. Developers can use this server to develop and test without affecting the production and or test server. Setup a test server for users to “play with”. When they are satisfied with the results, update production from the test server. This can all be setup in a production environmentand not affect mailrouting, or the chance of replicating to production accidently. Unless of course, you’ve got some hotshot programmer that wants to replicate manually from his desktop.
Hope this helps
Subject: Is my Boss right?
Chris, I agree totally. Your boss is clearly not handling the situation like a manager should. Does a good manager demean his employees? Absolutely not!
I typically have done this a number of ways. I personally like the seperate domain with cross certs and all. Depending on the nature of the testing I would recommend the seperate domain for the Test box. It is more work, but provides peace of mind. My R6 test server is in its own domain, even though I know I could have brought it up in the prod domain with proper administration.
.02